架构师训练营 - 命题作业 第 10 周

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



时序图如下：



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

1、中台架构：

个人理解，不是简单的业务聚合，而是要自顶向下，从组织架构上就要进行调整和变更，

从公司战略层面上，就要考虑整体产品的未来方向，规划出不同的基础产品服务，上层产品包装。

比如对于商城系统：

要有活动服务，提供各种票券的基本逻辑实现，

要有交易中心，提供所有的货契交易服务（包括0元支付、储值、线上支付等等），

当然也要有基本的用户服务、权限服务、认证服务、推送服务、BI中心等等，

在此之上，提供产品服务，提供不同的基础服务的组合和灵活的前台展现，

这样，在基础服务达到一定能力时，不需要底层开发，就可以组合出各种不同的产品，比如乞丐版、豪华版等等，我认为这就是产品中台。



2、领域驱动设计：

最关键的是要有业务专家，划分不同的子域和边界（限界上下文？）。

举例：消息控制中心设计：

一个餐饮系统，有排队服务、支付服务、票券服务、消息推送服务(含微信、短信等)。

排队要给用户推消息、支付要给用户推消息、送券要给用户推消息。

但是消息有推送限制，比如排队快到了要推消息、不能半夜推消息、支付成功消息，

还有一些其它消息要求，比如希望支付成功还要发短信，有些商户为了成本不希望发短信。

那么这些消息推送本身，都不应该是业务的范围，比如支付成功要不要发短信，放在支付系统，会引起支付系统的频繁变化，但是放在推送服务那边明显也不合理，推送为什么要关注支付业务？

所以，比较合理的是新建一个消息控制中心的子域，把所有消息推送的配置，都控制在这里，

什么排队、支付、票券，都只负责自己的业务，把事件扔给消息控制中心去处理，由消息控制中心去调用相应的通道，发消息。



3、组件设计原则：

从大型系统的角度，一个个微服务，就是这个大型系统的一个个组件，各个组件都应该内聚在自己的业务范围，依赖同层或下层组件的业务，被上层组件所依赖。