关于微服务架构思考和认识

本文为架构师训练营第 10 周课后作业,作业题为:

  • 根据微服务框架 Dubbo 的架构图,画出 Dubbo 进行一次微服务调用的时序图
  • 关于微服务架构(中台架构、领域驱动设计、组件设计原则),你有什么样的思考和认识

Dubbo  架构图及时序图

以下分别为 Dubbo 架构图和 Dubbo 微服务调用时序图:

Dubbo 架构图
Dubbo 架构图
Dubbo 微服务调用时序图
Dubbo 微服务调用时序图

微服务、领域驱动设计(DDD)和中台

微服务和 DDD 来源于西方,而中台诞生于中国的阿里巴巴。中台是抽象出来的业务模型,微服务是业务模型的系统实现,DDD 作为方法论可以同时指导中台业务建模和微服务建设,三者相辅相成。

DDD 有两把利器——战略设计和战术设计方法 。

中台在企业架构上更多偏向业务模型,形成中台的过程实际上也是业务领域不断细分的过程。在这个过程中将同类通用的业务能力进行聚合和业务重构,再根据限界上下文和业务内聚的原则建立领域模型。而 DDD 的战略设计最擅长的就是领域建模。

在中台完成领域建模后,就需要通过微服务来完成系统建设。此时,DDD 的战术设计又恰好可以与微服务的设计完美结合。可以说,中台和微服务正是 DDD 实战的最佳场景。

在研究和解决业务问题时,DDD 会按照一定的规则将业务领域进行细分,领域细分到一定的程度后,DDD 会将问题范围限定在特定的边界内,并在这个边界内建立领域模型,进而用代码实现该领域模型,解决相应的业务问题。领域可分解为子域,子域可继续分为子子域,一直到你认为适合建立领域模型为止。 子域还会根据自身重要性和功能属性划分为三类子域,分别是核心域、支撑域和通用域。

中台的本质其实就是提炼各个业务板块的共同需求,进行业务和系统抽象,形成通用的可复用的业务模型,打造成组件化产品,供前台部门使用。前台要做什么业务,需要什么资源,可以直接找中台,不需要每次去改动自己的底层。

对于传统企业,可以将需要共享的公共能力进行领域建模,建设可共享的通用中台。除此之外,还可将核心能力进行领域建模,建设面向不同渠道的可复用的核心中台。

如果将企业内整个业务域作为一个问题域的话,企业内的所有业务就是一个领域。在进行领域细分时,从 DDD 视角来看,子域可分为核心域、通用域和支撑域。从中台建设的视角来看,业务域细分后的业务中台,可分为核心中台和通用中台。

从领域功能属性和重要性对照来看,通用中台对应 DDD 的通用域和支撑域,核心中台对应 DDD 的核心域。从领域的功能范围来看,子域与中台是一致的。领域模型所在的限界上下文对应微服务。建立了这个映射关系,可以用 DDD 来进行中台业务建模了。更多关注领域驱动设计,可参考:关于 DDD 的那些事儿

组件设计原则

组件设计原则通常包括六个原则,可以分为组件聚合和组件耦合两类。

组件聚合

组件聚合用于指导应该将哪些类组合成一个组件,要考虑三个原则:复用/发布等同原则(The Reuse/Release Equivalence Principle, REP)、共同闭包原则(The Common Closure Principle, CCP)和共同复用原则(The Common Reuse Principle, CRP)。

复用/发布等同原则(REP),即软件复用的最小粒度等同于其发布的最小粒度。REP 用于指导代码复用在组件这一级,可复用的组件中必须包含可复用的类,这些可复用的类以组件的方式发布给用户使用。从另外一个角度去考虑一个组件的内容,一个组件中的类要么都可以重用,要么都不是可重用的。

同时,该原则要求保持组件的重用粒度和组件的发布粒度一致。例如,两个组件A、B,如果其他组件总是一起使用组件A、B,而且这两个组件总是一起发布,那么这两个组件应该合为一个组件。组件中的类与模块必须彼此紧密相关。

共同闭包原则(CCP),即应该将那些会同时修改、相同目的修改的类放在同一个组件中。另一方面,应该将不会同时修改,不会为了相同的目的而修改的类放在不同的组件中。

CCP 旨在说明如果一个应用中的代码需要同时、为统一目的发生修改,尽量让这种修改都集中在一个组件中,而不是分散在多个组件中。如果将这些更改分散在多个组件中,将增加软件发布、验证和维护工作量。

CCP 不重视代码的复用性,例如,如果A和B组件共同依赖于C组件,而且A组件的变化经常伴随着C变更,按照CCP原则的要求,C组件应该要放入A组件中,同样C组件应该放入B组件中,这将会导致代码复用性降低。而对于大部分应用程序来说,可维护性的重要性要远远高于可复用性!

共同复用原则(CRP),即不要强迫一个组件依赖他们不需要的东西。 CRP 是面向对象设计原则中接口分离原则的普适版本。CRP 要求经常共同复用的类和模块放在同一个组件中,而不是紧密相连的类不应该放在同一个组件中。

一个组件中的类应该一起被复用,相反,如果你只用一个组件中的一部分类,那么应该把不用的类从组件中移除出去。从另一个方面讲,在一个组件中不应该包含太多不同类型的类,不要把一些完全不相干的类放在一个组件中,这样会导致组件的职责过重,从而增加修改和发布的频率。

组件耦合

组件耦合用于确定组件之间的相互依赖关系,也要考虑三个原则:无依赖环原则 (Acyclic Dependencies Principle,ADP)、稳定依赖原则(The Stable Dependencies Principle,SDP)、稳定抽象原则(The Stable Abstractions Principle,SAP)。

详细参考:组件设计原则

《关于微服务架构思考和认识》的相关评论

发表评论

必填项已用 * 标记,邮箱地址不会被公开。