LMD 置顶2018-01-26关于《微服务架构核心20讲》课程讲义（PDF 文件），学员可复制下面链接到浏览器下载获取。 http://t.cn/RQs9iTw 11
2018-03-18业务初期要快速迭代产品验证市场接受度，所以前期应以业务驱动，提高开发效率为主，单体应用在这个时期是适合的。如果一开始应用微服务会为整个技术解决方案带来更高的复杂性，拖慢了产品的开发效率作者回复: 单块优先，解决业务问题优先
4
2018-03-16假设我需要重新设计系统共用模组架构，其中如IAM，audit日志，缓存，批处理作业，repoting，异常处理，数据访问适合使用微服务来规划吗？
还是根据单块先行的概念，先设计单块共用模组？谢谢。作者回复: 可以设计开发成微服务，这样职责更单一结构更清晰，多人并行开发效率高。但要不要这样做还需综合考虑，微服务也引入复杂性，需基础设施支撑，投入大。主要考量因素是业务和团队规模，系统耦合度是否影响到多团队并行开发效率。如果业务不复杂人也少，单块能搞定最好，没必要为了微服务而微服务。
2- 2018-03-16假设我需要重新设计系统共用模组架构，其中如IAM，audit日志，缓存，批处理作业，repoting，异常处理，数据访问适合使用微服务来规划吗？
还是根据单块先行的概念，先设计单块共用模组？谢谢。作者回复: 要看你的业务复杂性和团队规模，规模越大服务会分得越细，否则会有效率问题。如果规模小，建议做好基本的模块化就好了。
2 
2018-08-28请教您一个问题，聚合服务层通常作用是聚合和裁剪，那么如果业务只是一个简单的功能，是否可以不调用聚合服务层而直接调用基础服务层，换句话说就是如果基础服务层基本已经提供了某个业务需求，还需要调用聚合服务层吗，如果需要，那不是需要在聚合服务层又写一遍同样的功能，然后转发给基础服务层，这样的场景如果比较多，会有很多冗余，而且会增加一次网络开销。如果老师看到这个问题，请解答我的疑惑，多谢！ 1
2018-08-13基础层得各个微服务之间会互相调用吗？还是都不互相理解，都走聚合服务？作者回复: 原则：上层可调下层，同层也可相互调用，但禁止下层调用上层
1
2019-08-23老师的白板写的很好作者回复: 谢谢夸赞！
2019-07-30网关层，如内部GW、H5GW、无线GW、开放平台GW，套用到SpringCloud的话，是要为其一一单独设置zuul服务么作者回复: 具体看你企业的规模，小规模1～2套网关就可以了，中大规模一般分场景部署多套网关 。例如携程网(ctrip)规模较大，2015年我在携程工作的时候，它们大致有6～7套面向不同场景的网关(配置也会有差别)，目前应该远不止这么多套了。
2019-05-11老师，为什么网关层需要区分内部gw，h5网关，无线网关等? 网关不是应该重点关注跨横切面的功能而不应该涉及具体业务么？作者回复: 随着企业业务和团队规模的扩展，会出现需要多套网关部署的场景，例如针对无线应用的无线网关，针对H5应用的H5网关，针对第三方开放平台的开放API网关，针对合作联盟商的联盟商API网关，当然如果企业内部部门和服务多了，也会出现内部API网关。
这些网关的职能大体类似，但是针对的业务场景不同，一些具体的功能和配置会有不同，有时还需要不同团队进行管理运维，这是分网关部署的一个主要原因，是一种按业务场景分开治理的策略。
当然，如果企业业务和团队规模小，则可能一套网关就可以搞定，规模大了业务场景复杂了自然会分治。
2019-03-03老师请教一个问题，我们当前的微服务中，由于数据库只有一个，用的是mybatis，然后专门做了一个微服务来进行接数据操作，里面大部分都是对单表的操作，其他服务需要调用这个数据库服务，用的是feign来调用。这个时候其他服务同时对多张表进行增删改，就没有事务去控制，这种情况怎么处理？除了用三方中间件处理，本身这种设计是否有问题？能否有其他的方案替代？作者回复: 你好，这种做法我没有直接实践过，但我觉得可行，没有看到有明显的问题。事务控制你需要在这个数据服务中封装掉，最好有独立团队集中开发和维护这个数据服务，这样可以根据使用方的不同需求进行封装，集中进行事务处理，也集中进行治理。你需要做好监控，同时考虑扩展性，等量起来了可以考虑sharding，例如根据不同的领域进行拆分和隔离部署，后面按需扩容。
2019-02-19老师，您说的资源治理举了什么个栗子，没听清。作者回复: 资源治理例如配额治理，一个微服务应用使用多少核CPU，内存多少，多少个容器或虚拟机，一个部门或者团队允许使用多少物理资源等，这些需要治理(规划管理和监控)，不治理会被滥用。
2019-01-04波波老师，架构图里的业务层的聚合层可以挪到网关层zuul里实现吗？ 就是两个在一个zuul工程里面。作者回复: zuul一般只处理和业务无关的跨横切面(cross-cutting)逻辑，建议BFF单独一层，关注分离和职责单一原则，当然特殊情况(业务和团队规模很小)zuul上也可以承担BFF职责。
2018-11-13相比于单体应用，实施微服务需要更大的技术队伍和更多的硬件资源。初创团队资金有限，没有必要。
2018-10-12没学过架构的我。越来越听不懂了作者回复: 需要一些后端研发和架构经验积累，加油💪
- 2018-08-28不好意思，我已经在后面的章节评论里看到了答案，之前没有仔细看评论，所以老师您可以忽略我的问题了