架构师训练营第 1 期 -week10

问题 1

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

• Provider

• - 暴露接口层 jar 包供消费者使用

- 通过服务管理容器，向 Register 注册服务信息

- 收到 Consumer 请求后，将结果通过远程模块返回给 Consumer

• Register

• - 维护服务列表，主要是服务的 ip 和端口信息

- 通知 Consumer 更新服务提供者列表

• Consumer

• - 引入 Provider 暴露的接口层 jar 包，通过服务接口调用服务，不依赖具体的实现

- 服务接口通过接口代理访问服务框架客户端

- 客户端先访问本地的服务提供列表，如果没有再访问远程的服务注册中心

- 通过自己的负载均衡模块确定要连接的具体 ip 和端口

- 服务框架客户端打包请求，通过远程通讯模块发送给 Provider

问题 2

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

传统的开发模型，如经典的 Spring 分层模式 ——Controller/Service/Dao，就是所谓的贫血模型。我们绝大多数人在使用 Spring，只是使用 OO 语言开发，而不是 OO 开发；对象只是数据的载体，并没有行为。简单的业务系统采用这种贫血模型和过程化设计是没有问题的，但在业务逻辑复杂了，业务逻辑、状态会散落到在不同 Service 的不同方法中，原本的代码意图会渐渐不明确，我们将这种情况称为由贫血症引起的失忆症。相比之下，比较优异的抽象手段是采用领域模型的开发方式，将数据和行为封装在一起，并与现实世界中的业务对象相映射。各类具备明确的职责划分，将领域逻辑分散到领域对象中。

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

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

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

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

我们创建微服务时，事实上就是一个抽象 + 分治的手段；从复杂系统之中，抽象出一系列高内聚、低耦合的业务，以服务的形式分别运行。怎么提取？一般有两种方式：技术维度和业务维度。技术维度类似 MVC 的横向分层结构，业务维度则是按业务领域的纵向划分系统。微服务架构更强调从业务维度去分治复杂系统，以追求业务层面的复用；DDD 正巧也是以同样的视角去看待业务与技术的关系，在响应业务变化调整业务架构时，也随之变化系统架构。因此，DDD 与当今的微服务架构设计是有天然的契合点的。

但是，现实中我们往往被幸存者偏差所误导，以为微服务就是大路货了；其实不然，微服务很难落地。我自己所在的厂便实践过微服务，结果产品胎死腹中，连老板都被炒掉了。后来我读到康威定律，悟到了某些必然失败的原因：

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

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

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

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

反过来，如果你的团队结构混乱、职责不清，那么你将会设计出一个混乱的系统。每个设计混乱、故障不断的系统背后都有一个混乱、没有战斗力的团队。重构这样的系统，首先要重构开发团队。