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

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



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



首先，在分布式架构下，单体应用被拆分为多个微服务，为了保证微服务的单一职责和合理拆分，“高内聚、松耦合”是最宝贵的设计原则。

为了做到“高内聚、低耦合”，有以下几种典型的微服务架构模型。

1）整洁架构

在整洁架构里，同心圆代表应用软件的不同部分，从里到外依次是领域模型、领域服务、应用服务、最外围是容易变化的内容，如界面和基础设施等。

整洁架构是以领域模型为中心，不是以数据为中心。最主要原则是依赖原则，它定义了各层的依赖关系，越往里，依赖越低，代码级别越高。

2） 六边形架构

应用是通过端口与外部进行交互的，这也是微服务架构下 API 网关盛行的主要原因。在六边形架构中，内部业务逻辑（应用层和领域模型）与外部资源（APP，WEB 应用以及数据库等基础设施资源等）完全隔离，仅通过适配器进行交互。应用它解决了业务逻辑与用户界面的代码交错的主要问题，从而可以很好的实现前后端分离。

3）CQRS

CQRS 就是命令与查询职责分离，主要目的是为了读、写解耦，方便分别地提高查询和写入的性能。

查询模型是一种非规范化数据模型，它不反映领域行为，只用于数据查询和显示；命令模型执行领域行为，在领域行为执行完成后通知查询模型。

如果查询模型和领域模型共享数据源，则可以省却通知步骤；如果没有共享数据源，命令模型可以借助于发布订阅的消息模式通知到查询模型，从而达到数据最终一致性。

CQRS 适用于极少数复杂的业务领域，如果不是很适合反而会增加复杂度；另一个适用场景是为了获取高性能的查询服务。对于写少读多的共享类通用数据服务（如主数据类应用）可以采用读写分离架构模式，例如商品详情页的查询服务。

4）领域驱动设计（DDD）分层架构

DDD 分层架构各层定义与职能：

展现层：它负责向用户显示信息和解释用户命令，完成前端界面逻辑。

应用层：它是很薄的一层，负责展现层与领域层之间的协调，也是与其它系统应用层进行交互的必要渠道。

领域层：它是业务软件的核心所在，包含了业务所涉及的领域对象（实体、值对象）、领域服务以及它们之间的关系。领域驱动设计提倡富领域模型，即尽量将业务逻辑归属到领域对象上，实在无法归属的部分则以领域服务的形式进行定义。

基础设施层：它向其他层提供通用的技术能力，为应用层传递消息（API网关等），为领域层提供持久化机制（如数据库资源）等。

总之，上述的分层架构模型正是通过分层方式来控制需求变化对系统的影响，确保从外向里受需求影响逐步减小。面向用户的展现层可以快速响应外部需求进行调整和发布，灵活多变；应用层通过服务组合和编排实现业务流程的快速适配上线；领域层基本就不需要太多的变化了。



中台和微服务设计的关键在于合理的分层和领域模型的设计：

聚焦领域模型；合理的架构分层；服务的管理；资源的适配和解耦；前台应用的灵活性。



领域驱动设计（DDD）：

是一种处理高度复杂域的设计思想，试图分离技术实现的复杂性，围绕业务概念构建领域模型来控制业

务的复杂性，以解决软件难以理解，难以演化等问题。团队利用它可以成功的开发复杂业务软件系统，在系统变大时仍能保持敏捷性。领域驱动设计的核心诉求是让业务架构和系统架构形成绑定关系，当我们去响应业务变化调整业务架构时，系统架构的改变也会随之发生。



领域驱动设计分为两个阶段：

以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，在交流的过程中发现领域概念，然后将这些概念设计成一个领域模型；

由领域模型驱动软件设计，用代码来实现该领域模型。



领域驱动设计主要优势：

1. 业务导向。2. 业务逻辑内聚，应用边界清晰。3. 建立领域模型优先。4. 分析、设计、代码和数据有机

结合。5. 代码即设计。6. 扩展性好。



中台、DDD 与微服务的概念和关系：

中台的本质是提炼各个业务条线的共同需求，并将这些功能打造成组件化产品，然后以 API 接口的形式

提供给前台各业务部门使用。前台要做什么业务，需要什么资源可以直接找中台，不需要每次去改动自己的底层，而是在底层不变动的情况下，在更丰富灵活的“大中台”基础上获取支持，让“小前台”更加灵活敏捷。中台战略的主要目标是实现公共需求和功能的中台化共享，减少重复建设和投入，为前台提供统一的一致服务。

领域的本质是问题域，问题域可能根据需要逐层细分，因此领域可分解为子域，子域或可继续分为子子

域。在领域驱动设计中根据重要性与功能属性将领域分为三类子域，分别是：核心子域、支撑子域和通用子域。

1）决定产品和企业独特竞争力的子域是核心子域，它是业务成功的主要因素和企业的核心竞争力。

2）没有个性化的诉求，属于通用功能的子域是通用子域，如登陆认证。

3）还有一种所提供的功能是必须的，但不是通用也不是企业核心竞争力的子域是支撑子域。



中台、领域以及微服务属于不同层面的内容。

不同领域可根据领域大小进一步细分多个子域，多个子域可对应到一个业务中台，一个业务中台也可能会分解成多个子域。

微服务是技术实现和部署的范畴，实现领域或中台的业务逻辑，为前台应用提供服务。领域根据限界上下文可以设计为多个微服务，而如果限界上下文过大，一个微服务也可能会包含多个子领域。

中台是由多个业务条线的共同需求所构成，是需要共享的业务功能和服务单元的集合，一个中台可由一个微服务来实现，也可根据领域驱动设计和微服务拆分原则细分为多个微服务，多个微服务功能集合共同组成一个中台。



DDD 设计包括战略设计和战术设计两个部分。

战略设计主要关注按领域定义，在限界上下文内形成统一语言，提升业务和技术的沟通效率； 战术设计主要关注领域设计在落地时与设计模型及实现模型的差异性，减小业务和技术之间的鸿沟。

在战略设计阶段，完成领域建模和服务地图。

在战术设计阶段，通过聚合、实体、值对象以及不同层级的服务，完成微服务的建设和实施。

DDD 领域设计过程包括产品愿景、场景分析、领域建模和服务地图阶段，也可根据需要裁剪不必要的阶段和参与角色。通过 DDD 战略和战术全流程设计可建立业务架构与系统架构的一一映射，保证业务和代码模型的一致性。



微服务的边界设计：

限界上下文与限界上下文之间以及聚合与聚合之间的边界是逻辑边界，微服务与微服务的边界是物理边界。逻辑边界强调业务领域逻辑或代码分层的隔离，物理边界强调部署和运行的隔离。

领域和代码分层的逻辑边界的细分是必要的，但是考虑到更高的研发技能要求和软件维护成本，物理边界不宜过细，保证系统演进过程中方便拆分物理边界即可。

评判微服务设计合理的一个简单标准就是：微服务在随着业务发展而不断拆分或者重新组合过程中不会过度增加软件维护成本，并且这个过程是非常轻松且简单的。