架构师训练营 -week10- 作业

本周作业：

• 根据微服务框架 Dubbo 的架构图，画出 Dubbo 进行一次微服务调用的时序图。

• 关于微服务架构（中台架构、领域驱动设计、组件设计原则），你有什么样的思考和认识？

作业 1：Dubbo 微服务调用时序图

作业 2：关于微服务架构的思考

2017 年，我有幸主导了一个项目建设，也是部门第一次采用了基于 SpringCloud 的微服务框架搭建，在建设的过程中踩了不少坑，最后还算是勉勉强强的上线了。回过头再听了智慧老师的讲课，确实命中了不少坑点。采用微服务架构的初衷并非完成出于业务上的需要，一方面原因也是为团队做技术预研，所以并没有在服务拆分、领域设计方面做出太大的精力。前期先从粗粒度把拆成了几个服务，重点实现了服务的注册发现、配置中心、网关，在上线以后逐步加上了调用链监控，metrics 监控。后续考虑进一步实现日志统一监控处理、结合容器化发布等功能。

在项目过程中，也加深了对微服务的理解，印象深刻的有几点：

1. 关于要不要采用微服务的话题，一直都是有争议的话题。一部分人认为微服务一定是演化出来的，而不是设计出来的，随着业务发展的越来越快，单一架构的系统已经不能支持业务的快速变化，每一次的升级、开发都要伴随巨大的代价，所以服务化是这种情景下的演进之路。另外一种观点，是在目前云原生技术已经成为了业界主流，微服务周边的支持和生态圈越来越成熟，对应的技术体系也越来越完善，利用云原生技术，可以以很低的成本构建出一套微服务的体系架构。

2. 上线后对监控功能一定要重视，尽量完善。监控主要包括：调用链跟踪、日志监控、metrics 业务监控。出现问题后，运维人员可以通过工具快速的定位问题。

3. 采用微服务后的组织架构该如何变化。微服务最被广泛遵循的就是“康威定律”，即设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。针对于微服务架构下的业务开发，组成一个“2 个披萨”的团队，负责需求、开发、测试、运维全套流程。吃自己的狗粮，自己的代码自己维护，这样更利于代码的良性运作。另外，还需要组织框架团队，负责进行微服务基础组件的开发，主要包括：监控、配置中心、日志等框架性的工作。