我非常赞同老师的观点: 单块优先,逐步演进. 我个人更倾向于好的架构是逐步演化出来的. 微服务的拆分依赖领域模型,但刚开始,领域模型可能并不是特别的清晰.

讲的好，基本微服务涉及的知识都有讲解

挺好，老师做到了压缩知识高效传输的目的，希望我们能正确的解压缩。 感谢分享！

微服务调用链监控工具，CAT/ZIPKIN/PINPOINT，这个确实重要，对于排查问题，特别是定位性能瓶颈很有帮助。 原理： 1：记录调用链的关系，主要通过TRACE ID和SPAN ID 2：记录每个子调用过程的方法执行情况

看过那个采访，那个公司创新能比较强的原因国内的是很难模仿的，我觉得核心原因如下： 1：严进宽出，这个公司招人非常的严格，流程也巨长，所以，招进去的都是高水准的人——这个可以模仿 2：这个公司是做游戏的，积累了许多可复用的基础组件，这是他们快速产出的密码 3：公司员工单兵能力强，并且文化是自驱动的，提高的福利的薪资都具有吸引人，或者说解决了员工的后顾之忧能充分的调用员工的积极性——这个很难做到 4：基于上面的原因产出的效率高，并且会尽早的投入市场，根据用户的反馈来决定是砍掉项目还是继续 中台的核心在于赋能，提高服务的复用性，提高研发效能。 按照另一位老师的定义是，企业级服务复用平台。

阅过留痕 什么是微服务架构？ 微服务架构，拆开就是微＋服务＋架构 微——表示小，首先，是服务的粒度小，然后是开发团队小，再者就是通信轻量化。 服务——本质就是一个接口的方法，用于处理信息，早就有之，本质不变。 架构——系统的主题结构，类似人体骨架的意思，系统中有类似MVC架构、分层架构、主从架构等分类。 新技术三连击 微服务解决了什么问题？ 微服务是怎么解决这些问题的？ 微服务引入了那些新问题？ 没有微服务系统会是怎样的，痛点在哪里？ 新技术的出现基本是为了解决原有技术解决不了的问题的，这个希望老师也讲一下？

如何看待将传统单体系统 直接重构为微服务架构的系统呢？有什么好的建议么

半年后来看，发现讲得真好，半年前看不懂

老师有一个问题，假如一个微服务部署了多个实例，那网关必然要从多个服务实例中选择一个来进行服务调用，也就是必须要具备一点负载均衡的功能，这个是不能省掉的吧？

如何在自己的公司中实践“大中台，小前台”的架构。 阿里云这样的云平台提供了IaaS层、PaaS层的服务。 如果我们做的是一个电商系统，“有赞”这样的企业提供了比较完善的核心业务层的接口。 作为架构师，首先可以使用市场上的各类“大中台”资源，较低成本的构建自己的“小前台”应用。 当公司的业务成熟，可以根据团队已经积累的领域知识，思考每一个服务维护的核心资源是什么。一方面，根据其他服务的需要，暴露相应的资源访问接口；另一方面，可以更进一步，设计出更多外部暂时还未用到，但确实符合业务逻辑的资源访问接口。 这里有两点需要注意。一是，业务逻辑要尽量全部放在核心业务层内，不要蔓延到应用层。二是，对外暴露的资源访问接口的粒度不宜太大或太小。太大了会降低安全性，太小了会增加复杂性，也会不足以体现业务逻辑。