第十周课后练习

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

dubbo 微服务调用时序如上图：

（1）服务管理端容器获取服务提供者程序；

（2）服务管理容器向服务注册中心注册服务；

（3）服务注册中心向服务框架客户端返回服务提供者列表；

（4）消费者程序调用远程服务接口；

（5）接口访问代理访问服务框架客户端；

（6）服务框架客户端根据服务提供者列表和负载均衡策略获取到服务提供者；

（7）服务框架客户端调用客户端远程通讯模块；

（8）客户端远程通讯模块调用服务端远程通讯模块；

（9）服务端远程通讯模块找到对应的服务提供者线程；

（10）调用服务提供者程序

Dubbo 官网有很好的图。

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

介绍微服务架构好处的文章比较多，但使用不慎，研发成本，交付成本和运维成本都可能会大幅度上升。

不能简单通过技术角度看待微服务化，为了微服务而微服务潜在风险很大，不好的微服务切分会带来不必要的沟通路径，而沟通路径增加会带来更大的复杂度，这违背了微服务设计的初衷。微服务“入门容易，掌握难，出门难”。

我们需要遵循以下原则：

• 业务先行，先理顺业务边界和依赖，技术是手段而不是目的。

业务驱动，设计保障，演进式迭代，保守治疗的方式。搞不清楚，有争议的地方先尽量不要拆，如果确实要拆，要经过业务分析后慎重设计，把真正相对独立的部分拆分出来，可以借鉴 DDD 的方式。拆了以后要观察微服务的接口是否稳定，针对业务需求的变更微服务的模块是否可以保持相对稳定，是否可以独立演进。

• 先有独立的模块，后有分布式的服务。

• 业务耦合严重，逻辑复杂多变的系统进行微服务重构要谨慎。

架构演进应该还是需要业务驱动和演进式迭代的，需要考虑微服务的几个潜在问题：

1. 显著的运营开销

2. 大量的开发运营(DevOps)技术要求

3. 隐式接口

4. 重复努力

5. 分布式系统的复杂性

6. 异步性的困难性

7. 可测试挑战