作业一

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





作业二

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

中台架构

中台业务抽象的过程就是业务建模的过程，对应 DDD 的战略设计。系统抽象的过程就是微服务的建设过程，对应 DDD 的战术设计。

第一步：按照业务流程（通常适用于核心域）或者功能属性、集合（通常适用于通用域或支撑域），将业务域细分为多个中台，再根据功能属性或重要性归类到核心中台或通用中台。核心中台设计时要考虑核心竞争力，通用中台要站在企业高度考虑共享和复用能力。

第二步：选取中台，根据用例、业务场景或用户旅程完成事件风暴，找出实体、聚合和限界上下文。依次进行领域分解，建立领域模型。由于不同中台独立建模，某些领域对象或功能可能会重复出现在其它领域模型中，也有可能本该是同一个聚合的领域对象或功能，却分散在其它的中台里，这样会导致领域模型不完整或者业务不内聚。这里先不要着急，这一步我们只需要初步确定主领域模型就可以了，在第三步中我们还会提炼并重组这些领域对象。

第三步：以主领域模型为基础，扫描其它中台领域模型，检查并确定是否存在重复或者需要重组的领域对象、功能，提炼并重构主领域模型，完成最终的领域模型设计。

第四步：选择其它主领域模型重复第三步，直到所有主领域模型完成比对和重构。

第五步：基于领域模型完成微服务设计，完成系统落地。



领域驱动设计

简单的业务领域，一个领域就是一个小的子域。在这个小的问题域内，领域建模过程相对简单，直接采用事件风暴的方法构建领域模型就可以了。

对于复杂的业务领域，领域可能需要多级拆分后才能开始领域建模。领域拆分为子域，甚至子域还需要进一步拆分。比如：保险它需要拆分为承保、理赔、收付费和再保等子域，承保子域再拆分为投保、保单管理等子子域。复杂领域如果不做进一步细分，由于问题域太大，领域建模的工程量会非常浩大。你不太容易通过事件风暴，完成一个很大的领域建模，即使勉强完成，效果也不一定好。

对于复杂领域，我们可以分三步来完成领域建模和微服务设计。

第一步，拆分子域建立领域模型根据业务领域的特点，参考流程节点边界或功能聚合模块等边界因素。结合领域专家和项目团队的讨论，将领域逐级分解为大小合适的子域，针对子域采用事件风暴，划分聚合和限界上下文，初步确定子域内的领域模型。

第二步，领域模型微调梳理领域内所有子域的领域模型，对各子域领域模型进行微调。微调的过程重点考虑不同领域模型中聚合的重组。同步考虑领域模型和聚合的边界，服务以及事件之间的依赖关系，确定最终的领域模型。

第三步，微服务的设计和拆分根据领域模型和微服务拆分原则，完成微服务的拆分和设计。

组件设计原则

1、组件内聚原则

组件内聚原则主要讨论哪些类应该聚合在同一个组件，以便组件既能够提供相对完成的功能，又不至于太过庞大；

2、复用发布等同原则

软件复用的最小粒度应该等同于其发布的最小粒度。也就是说，如果希望别人以怎样的粒度复用你的软件，你就应该怎么样的粒度发布你的软件。组件是软件复用和发布的最小粒度软件单元。这个粒度即是复用的粒度，也是发布的粒度。

版本号约定建议：

• 版本号格式：主版本号.此版本号.修订号。比如2.5.1，这个版本中，主版本号是2，次版本号是5，修订号是1；

• 主版本号升级，表示组件发生了不向前兼容的重大修订；

• 此版本号升级，表示组件进行了重要的功能修订或者bug修复，但是组件是向前兼容的；

• 修订号升级，表示组件进行了不重要的功能修订或者bug修复。

3、共同封闭原则

应该将同时修改，并且为了相同目的而修改的类放到同一个组件中。而将不会同时修改，并且不会为了相同的而修改的类放到不同的组件中。

组件的目的虽然是为了复用，然而开发中常常引发问的，恰恰在于组件本身的可维护性。如果组件在自己的生命周期中必须经历各种变更，那么最好不要设计其它组件，相关的变更都在同一组件总。这样，发生变更的时候，只需要重新发布这个组件就可以了，而不是一大堆组件都受到牵连。

4、共同复用原则

这个原则是说，不要强迫一个组件的用户依赖他们不需要的东西。

一方面，我们应该将相互依赖、公共复用的类放在一个组件中。另一方面，这个原则也说明，如果不是被公共依赖的类，就不应该放在同一个组件中。如果不被依赖的类发生变更，就会引起组件变更，进而引起使用组件发生变更。这样就会导致组件的使用产生不必要的困扰，甚至讨厌使用这样的组件，也造成了复用的困难。

5、无循环依赖原则

组件依赖关系中不应该出现环。如果组件A依赖组件B，组件B依赖组件C，组件C又依赖组件A，就形成了循环依赖。

很多时候，循环依赖时在组件的变更中逐渐形成的，组件A版本1.0依赖组件B版本1.0，后来组件B升级到1.1，升级的某个功能依赖组件A的1.0版本，于是形成了循环依赖。如果组件的设计边界不清晰，组件开发的设计缺乏评审，开发者只关注自己开发的组件，整个项目对组件依赖管理没有统一的规则，很有可能出现循环依赖。

6、稳定依赖原则

组件依赖关系必须向更稳定的方向。很少有变更的组件是稳定的，也就是说，经常变更的组件是不稳定的。根据稳定的依赖原则，不稳定的组件应该依赖稳定的组件，而不是反过来。

反过来说，如果一个组件被更多的组件依赖，那么它需要相对稳定的，因为想要变更一个被很多组件依赖的组件，本身就是一件困难的事。相对应的，如果一个组件依赖了很多的组件，那么它相对也是不稳定的，因为它依赖的任何组件变更，都可能导致自己的变更。

7、稳定抽象原则

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

这个原则对具体开发的指导意义就是：如果你设计的组件是具体的、不稳定的，那么可以为这个组件对外提供服务的类设计一个接口，并把这组接口封装在一个专门的组件中，那么这个组件就相对比较抽象、稳定。