作业一

1. Dubbo 进行一次微服务调用的时序图

（至少完成一个）

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





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

作业一：

1. 首先自然是需要provider服务提供者向注册中心注册自己，然后注册中心通知消费者consumer客户端更新服务列表

2. 发起访问时，consumer消费者通过服务接口访问接口代理

3. 接口代理再调用dubbo客户端框架

4. 客户端框架通过特定负载均衡策略在服务列表里选择服务提供者provider的服务，然后通知远程通信模块发起RPC调用

5. RPC调用达到服务提供端

6. dubbo服务端框架调用provider程序

7. 最后provider的计算结果再依照上述链路一路返回到consumer消费者程序中





Dubbo 进行一次微服务调用的时序图

2. 微服务架构思考题

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



开篇讲个题外话：本周4、5做了年度工作总结，我们都在尽量吹嘘自己的工作成果，做了多少项目、改了多少bug、完成了多少系统。领导很满意。但是领导发问了：

1. 你在运维方面有什么思考和认识没有？

2. 你在运维开发领域有没有找到一点感觉？

3. 对于运维开发的的抽象、创新有没有做过思考？

4. 运营分析这边你有什么想法没？



看得出，领导是很重视员工的思考、是不是一个码农思想、只想着实现功能，还是说有真正的架构思维、高屋建瓴的想法、抽象化的想法、这给了我一丝的启发？看到作业，我感觉智慧老师的题目和我们领导的想法一致，至少高度上是统一的？不止局限于码农、实现代码功能、这是普通开发都能做？真正的高手是需要提高到思想建设的高度的：高度抽象化、方法论、标准化、规范化、创新上下文章。



中台架构、DDD、设计原则有专门的理论支撑、自己没有去看过，不敢妄自发言，就随便模仿一些。



传统的开发模型，如经典的三层架构模式：controller、service、dao，就是所谓的贫血模型。我们绝大多数人在使用java、spring框架进行开发，但只是使用OO这种面向对象语言进行开发，并不是OO开发，就像：深入一门语言开发而不是使用一门语言开发。（代码大全2类似话语）



对象只是数据的载体，并没有行为。简单的业务系统采用这种贫血模型和过程化设计是没有问题的，但是业务逻辑一旦复杂了，逻辑代码、对象状态就会散落到不同的service的不同方法中，原本的代码意图、对象设计就会不明确、变得臃肿，我们将这种情况称为由贫血引起的失忆症。



相比之下，比较优异的手段是采用领域驱动设计DDD，将数据和行为封装在一起，并与现实世界中的业务对象相映射。不同的类具备明确的职责划分，将领域逻辑分散到领域对象中。



其实我们公司的云产品苍穹也是使用领域驱动设计，非常的典型，现在发展也是非常好，可惜了，我对其低层架构、源码、设计思想不甚了解，所以此处不能以具体的例子来进行讲述。甚是遗憾。



下面贴个图就等于介绍：





解决复杂和大规模软件的方法论可以被粗略的归为三类：分治、抽象和知识。

• 分治：把问题空间分割为规模更小且易于处理的若干子问题

• 抽象：使用抽象能够精简问题空间，而且问题越小越容易理解

• 知识：顾名思义：DDD、组件设计原则、软件工程等可以认为是知识的一种，让我们知道如何抽象出限界上下文以及如何去分治



我们创建微服务时，事实上就是一个抽象+分治的手段：从复杂系统之中，抽象出一系列高内聚、低耦合的业务，以服务的形式分别运行。怎么提取？一般有两种方式：技术维度和业务维度。



技术维度类似MVC的横向分层结构，业务维度则是按业务领域纵向划分系统。微服务架构更强调从业务维度去分治复杂系统，以追求业务层面的复用。DDD正巧也是以同样的视角去看待业务与技术的关系，在响应业务变化调整业务架构时，也随之变化系统架构。因此：DDD与当今的微服务架构设计是有天然的契合点的。



但是，现实中我们往往被幸存者带偏、误导。以为微服务满大街都是，别人上，我们也要上。然而，见过了太多的失败、打着微服务的旗号招人，觉得学了点皮毛就开始吹嘘自己是淘宝、微信。动辄向大厂看齐，不曾想大厂走过了多少弯路。



康威定律：任务组织在设计一套系统时，所交付的设计方案在结构上都与该组织的沟通架构保存一致。



它告诉我们：系统结构应尽量与组织结构保持一致，限界上下文和团队结构应该保持一致。其实很好理解，梳理清楚上下文之间的关系，从团队内部的关系来看，好处显而易见：

• 任务更好拆分：一个开发人员可以全身心投入到一个相关的单独上下文中

• 沟通更加顺畅：一个上下文可以明确自己对其它上下文的依赖关系，从而使得团队内开发对接更顺畅



反之：如果团队本身混乱不堪、职责不清，那么你将设计出一个混乱的系统。每个混乱的背后都有一个混乱的团队、混乱的老板。这样的团队、这样的老板能成功，在中国很多，但是你却要注意。



重构系统，其实是重构思维、重构团队开始的。或者重构你自己。