第 10 周 作业 1

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

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

微服务架构是用来解决单一服务问题的，单一服务是将所有的业务都放在一个大的项目仓库中进行开发、部署、维护、对外提供服务。

单一服务存在下面的问题：

• 编译、部署困难。项目大后，存在的依赖和问题就都在一个项目中，只要有一个问题，就会导致整个项目启动不了。如果是 java 全部服务放在一个 jar 包，编译会耗费很长的时间。

• 代码分支管理困难。不同业务同时进行开发，不同业务的复用代码更是可能被同时修改，代码合并冲突太多。

• 数据库连接耗尽。服务部署集群扩展时，每个服务实例上都需要创建数据库的全部连接，集群的规模一大，数据库连接将耗尽。

• 新增业务困难。老业务耦和严重、复杂，开发新业务容易掉坑。



微服务通过横向、纵向拆分，将模块独立部署，降低了系统耦合性和复杂性。

• 纵向拆分：将大的应用按业务独立拆分，不同的业务单独项目、单独部署，依赖的项目通过 RPC 调用。

• 横向拆分：将复用的业务独立出来部署成微服务，新增业务只需要调用这些微服务既可以快速搭建一个系统。



微服务技术的核心是服务注册、服务发现、服务远程调用。一般还需要微服务框架支持：

• 失效转移：服务都需要集群部署，当某一实例有问题的时候，提供失效转移机制，实现服务的高可用。

• 负载均衡：框架本身需要提供复杂均衡功能，一般有加权轮询、随机等方式。

• 高效的远程通信：高效序列化方式、定制服务调用协议。

• 对应用最少侵入：微服务也需要渐进的演化，不是一蹴而就的，可以从单一服务转换为微服务，也可以从微服务转移微单一服务。

• 版本管理：服务提供者和服务消费者不可能同时升级，所以需要提供版本管理的功能，不同版本的服务同时提供。



中台架构是在微服务的基础上，将一些能复用的模块独立、抽象出来，为其他的业务提供基础服务。比如订单服务，它的订单流程、业务结构一般比较固定，如果每个业务订单都来做一遍订单的流程，不同模块是有大量的重复代码，也不利于业务的快速开发。中台将订单服务独立、抽象后，比如一般线上购物订单、拼团订单、电影票订单，它们都直接通过订单服务完成基础订单的逻辑，然后不同业务再完成自己个性化的部分，这样就可以快速完成业务的开发，复用已有的模块功能，而不是不同订单业务将订单流程又全做一遍。

但是中台架构也是需要业务的沉淀，一开始的时候就一个单一业务也就没有中台的概念了。



领域驱动设计更像是一种开发的具体方法。和大多数的通过功能界面来按功能进行开发，和通过数据库为原点开发不同，首先需要大量的业务分析、领域建模，定义好不同的子域，然后设计不同子域中的方法，所有的功能通过对象之间组合调用方式实现，而不是通过 service 方式调用一个个 curd 完成（贫血模型）。

领域驱动设计更适合用在业务稳定、复杂、清晰的系统，需要前期大量的设计，而一般业务本身不负责，简单 curd 也可以快速实现，维护也不困难。所以大多数时候都没用采用领域驱动设计的开发方式。



组件通常是一个完整的功能，单独部署和发布，不同业务需要时可以直接拿来用，而不在需要对接、开发。组件的开发需要遵循下面组件内聚原则、组件耦合：

1. 组件内聚原则。组件是不同业务需要时直接拿来用的，是一个完整的功能，所以组件内部尽量不要有不必要的依赖。

• 复用发布等同原则：如果你希望别人以怎样的粒度复用你的软件，你就应该以怎样的粒度发布你的软件。组件是软件复用和发布的最小粒度软件单元。

• 共同封闭原则：应该将那些会同时修改，为了相同目的而修改的类放到同一个组件中。组件的目的是复用，然而开发中常常引发问题的是组件本身的维护。最好是当组件发生变更时，只需要发布改动的组件。

• 共同复用原则：不要强迫一个组件的用户依赖他们不需要的东西。

1. 组件耦合原则。组件之间的的关系设计原则。

• 无循环依赖：避免在组件变更时出现循环依赖。

• 稳定依赖：组件必须依赖比自己还要稳定的依赖，不稳定的需要依赖稳定的，而不是稳定的依赖不稳定的。

• 稳定抽象原则。一个稳定的组件应该是抽象的，而不稳定的组件是具体的。一个组件的抽象化程度与其稳定性程度一致。