首页  思维导图  详情

微服务 vs DDD vs 中台

2020-10-18 20:42:26   0  举报





仅支持查看

AI智能生成

微服务，中台，领域驱动设计三者比较

微服务

中台

领域驱动设计

DDD

作者其他创作

大纲/内容

总结

怎么划分子域，限界上下文等？

对一个问题不断地划分，直到划分为我们熟悉的、能够快速处理的小问题。然后再对小问题的处理排列一个优先级。
领域细分到一定的范围后，我们就可以对这个子域进行事件风暴，为这个子域划分限界上下文，建立领域模型，然后就可以基于领域模型进行微服务设计了。

DDD 没有明确说明子域和限界上下文的关系。

每个企业由于商业模式或者战略方向不一样，核心域会有一些差异，不要用固定的眼光看待不同企业的核心域。

仓储模式

关于聚合设计过程中的一些原则问题。大部分的业务场景我们都可以通过事件风暴，找到聚
合根，建立聚合，划分限界上下文，建立领域模型。但也有部分场景，比如数据计算、统计
以及批处理业务场景，所有的实体都是独立无关联的，找不到聚合根，也无法建立领域模
型。但是它们之间的业务关系是非常紧密的，在业务上是高内聚的。我们也可以将这类场景
作为一个聚合处理，除了不考虑聚合根的设计方法外，其它诸如 DDD 分层架构相关的设计
方法都是可以采用的。

一切为了解决问题，不能为了DDD，而DDD

什么是微服务

软件架构模式演进

第一阶段是单机架构

采用面向过程的设计方法，系统包括客户端 UI 层和数据库两层，采用 C/S 架构模式，整个系统围绕数据库驱动设计和开发，并且总是从设计数据库和字段开始。

单体

JEE+Web容器

SSH框架

第二阶段是集中式架构

采用面向对象的设计方法，系统包括业务接入层、业务逻辑层和数据库层，采用经典的三层架构，也有部分应用采用传统的 SOA 架构。这种架构容易使系统变得臃肿，可扩展性和弹性伸缩性差。

SOA

1. Web Service

2. ESB

第三阶段是分布式微服务架构

随着微服务架构理念的提出，集中式架构正向分布式微服务架构演进。微服务架构可以很好地实现应用之间的解耦，解决单体应用扩展性和弹性伸缩能力不足的问题。

在系统建设过程中，我们经常会看到这样的情形：A 负责提出需求，B 负责需求分析，C 负责系统设计，D 负责代码实现，这样的流程很长，经手的人也很多，很容易导致信息丢失。最后，就很容易导致需求、设计与代码实现的不一致，往往到了软件上线后，我们才发现很多功能并不是自己想要的，或者做出来的功能跟自己提出的需求偏差太大。

微服务

微服务的准则

1. 单一职责

2. 每个服务运行在独立的进程中

3. 集群，每个实例运行在容器化的平台内，达到平滑伸缩的效果，根据性能需求，水平伸缩

4. 服务可以独享自己的数据储存，比如数据库，缓存，消息队列

去数据共享模式，就是不要使用同一个数据库，不要使用同一个缓存数据key，同一个消息队列topic

5. 每个服务有独立的产品，开发，运维，运营人员。职能划分明确，高度自治，便于管理。

根据康威定律，团队的交流机制应该与架构设计机制相对应。

康威定律

康威定律是马尔文·康威1967提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。
跨部门沟通是非常难的，系统各个模块的接口也反映了它们之间的信息流动和合作方式。
康威定律可谓软件架构设计中的第一定律，起初只是在杂志上的发表，后经过《人月神话》这本软件界圣经的引用，并命名为康威定律（Conway’s law），因此得以推广。

只通过简单的描述可能无法理解康威定律的精髓所在，原文中康威定律可总结为四个定律：

第一定律组织沟通方式会通过系统设计表达出来。

第二定律时间再多一件事情也不可能做的完美，但总有时间做完一件事情。

第三定律线型系统和线型组织架构间有潜在的异质同态特性。

直白的说就是想要什么的系统就搭建什么样的团队，有什么样的团队就搭建什么样的系统。需要前后端分离的系统就搭建前后端分离的团队，反之，拥有前后端分离的团队，可以设计前后端分离的系统。当然，如果能统筹管理，拥有重组团队或设计系统架构的权利，那就再好不过了。通常情况下让两者形成1：1的映射关系，更加高效。

第四定律大的系统组织总是比小系统更倾向于分解。

在微服务架构中，提出运维也是服务项目团队的一员，倡导谁开发，谁维护，实行终身维护制度。

6. 去中心化治理

API网关是一个反微服务化的例子

单体架构的劣势

1. 耦合，互相依赖

2. 所有功能混合在一个JVM进程里面，工程大，打包，上线等等都有问题。

微服务拆分的困境

我认为微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方。

DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。

微服务的设计模式

1. 服务组合模式

1. 服务代理模式

运用

微服务系统平滑迁移经常需要使用这种模式

微服务系统平滑迁移步骤

1. 新老系统双写

比如有用户来注册，那么这个用户就是新用户就写到新系统。
有老用户来修改个人信息，那么这个用户就是老用户写老系统。

2. 迁移双写前的遗留数据

这里代码需要做出容错，在迁移的过程中比如读老用户信息没有，需要在新系统再查一次，因为是逐步迁移的。

3. 将读请求切换到新系统

用到代理模式的开关，其实nginx也是微服务中的服务代理模式

4. 下单双写的逻辑，只写新系统

也就是说这里要准备好2个代码版本。一个是新老系统双写，一个是单写新系统。

服务代理模式，常常在第三步，做一个读请求切换开关。将读的请求切换到了的系统。

2. 服务聚合模式

3. 服务串联模式

不推荐

这种模式层次一多，容易互相依赖

底层加一层，对上面一层也是无感知的

4. 服务分支模式

服务分支模式就是代理模式，聚合模式，串联模式三者结合起来使用。

不建议使用，增加架构的复杂度。保持服务依赖关系清晰明了，减少运维工作。

5. 服务异步消息模式

6. 服务共享数据模式

其实这个是反微服务设计模式，
在下面两种情况需要设计共享模式

单元化架构

穷，没那么多机器

遗留的整体服务

2. 服务容错模式

1）服务隔离模式

DDD

概念

DDD 是一种处理高度复杂领域的设计思想，它试图分离技术实现的复杂性，并围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演进的问题。DDD 不是架构，而是一种架构设计方法论，它通过边界划分将复杂业务领域简单化，帮我们设计出清晰的领域和应用边界，可以很容易地实现架构演进。

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

战略设计

DDD 战略设计会建立领域模型，领域模型可以用于指导微服务的设计和拆分。

事件风暴是建立领域模型的主要方法，它是一个从发散到收敛的过程。

发散

通常采用用例分析、场景分析和用户旅程分析，尽可能全面不遗漏地分解业务领域，并梳理领域对象之间的关系，这是一个发散的过程。

收敛

事件风暴过程会产生很多的实体、命令、事件等领域对象，我们将这些领域对象从不同的维度进行聚类，形成如聚合、限界上下文等边界，建立领域模型，这就是一个收敛的过程。

事件风暴需要准备些什么？

1. 事件风暴的参与者

2. 事件风暴要准备的材料

3. 事件风暴的场地

4. 事件风暴分析的关注点

1. 产品愿景

2. 业务场景分析

3. 领域建模

输入：用户操作、事件以及外部依赖关系

输出：通用语言，限界上下文，领域模型（包括领域中的领域对象）

案例

战术设计

将领域模型中的领域对象与代码模型中的代码对象建立映射关系，将业务架构和系统架构进行绑定。当我们去响应业务变化调整业务架构和领域模型时，系统架构也会同时发生调整，并同步建立新的映射关系。

输入：领域模型

输出：代码

落地

DDD的名词/领域模型

领域

DDD 的领域就是特定的边界内要解决的业务问题域。

领域可以拆分为多个子领域。

一个领域相当于一个问题域，领域拆分为子域的过程就是大问题拆分为小问题的过程。

子领域

如何划分子域

核心思想就是将问题域逐步分解，降低业务理解和系统实现的复杂度。

子域可以根据自身重要性和功能属性划分为三类子域

核心域

决定产品和公司核心竞争力的子域是核心域，它是业务成功的主要因素和公司的核心竞争力。

通用域

没有太多个性化的诉求，同时被多个子域使用的通用功能子域是通用域。

支撑域

既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，它就是支撑域。

包含

实体

值对象

聚合

聚合根

限界上下文 & 通用语言

通用语言

在事件风暴过程中，通过团队交流达成共识的，能够简单、清晰、准确描述业务涵义和规则的语言就是通用语言。

通用语言包含术语和用例场景，并且能够直接反映在代码中。

通用语言中的名词

给领域对象命名，如商品、订单等，对应实体对象

通用语言中的动词

表示一个动作或事件，如商品已下单、订单已付款等，对应领域事件或者命令。

通用语言落地

设计过程中我们可以用一些表格，来记录事件风暴和微服务设计过程中产生的领域对象及其属性。

为什么要有限界上下文？

语言都有它的语义环境，同样，通用语言也有它的上下文环境。为了避免同样的概念或语义在不同的上下文环境中产生歧义，DDD 在战略设计上提出了“限界上下文”这个概念，用来确定语义所在的领域边界。

限界上下文的定义：用来封装通用语言和领域对象，提供上下文环境，保证在领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。

领域边界就是通过限界上下文来定义的。

理论上限界上下文就是微服务的边界。我们将限界上下文内的领域模型映射到微服务，就完成了从问题域到软件的解决方案。

实体

一种对象，它拥有唯一标识符，且标识符在历经各种状态变更后仍能保持一致。对它而言，重要的不是其属性，而是其延续性和标识，对象的延续性和标识会跨越甚至超出软件的生命周期。

实体是看得到、摸得着的实实在在的业务对象，实体具有业务属性、业务行为和业务逻辑。

实体的四种形态

1. 实体的业务形态

2. 实体的代码形态

这些实体类可以采用充血模型/贫血模型

充血模型

充血模型层次结构和上面的差不多，不过大多业务逻辑和持久化放在领域对象里面，领域层只是简单封装部分业务逻辑以及控制事务

贫血模型

贫血模型是指领域对象里只有get和set方法（POJO），所有的业务逻辑都不包含在内而是放在领域层。

该模型的缺点是不够面向对象，领域对象只是作为保存状态或者传递状态使用，它是没有生命的，只有数据没有行为的对象不是真正的对象

贫血模型实施的最大难度在于如何梳理好BusinessLogic层内部的划分关系

3. 实体的运行形态

4. 实体的数据库形态

业务实体，代码实体，数据库实体对应关系

特点

有 ID 标识，通过 ID 判断相等性，ID 在聚合内唯一即可。状态可变，它依附于聚合根，其生命周期由聚合根管理。实体一般会持久化，但与数据库持久化对象不一定是一对一的关系。实体可以引用聚合内的聚合根、实体和值对象。

值对象

通过对象属性值来识别的对象，它将多个相关属性组合为一个概念整体。

简单来说，值对象本质上就是一个集。

比如

值对象只是若干个属性的集合，只有数据初始化操作和有限的不涉及修改数据的行为，基本不包含业务逻辑。

值对象的四种形态

1. 值对象的业务形态

2. 值对象的代码形态

3. 值对象的运行形态

值对象嵌入到实体

两种方式

属性嵌入的方式

序列化大对象

4. 值对象的数据库形态

在领域建模时，我们可以将部分对象设计为值对象，保留对象的业务涵义，同时又减少了实体的数量；
在数据建模时，我们可以将值对象嵌入实体，减少实体表的数量，简化数据库设计。

值对象采用序列化大对象的方法简化了数据库设计，减少了实体表的数量，可以简单、清晰地表达业务概念。

这种设计方式虽然降低了数据库设计的复杂度，但却无法满足基于值对象的快速查询，会导致搜索值对象属性值变得异常困难。

值对象采用属性嵌入的方法提升了数据库的性能

但如果实体引用的值对象过多，则会导致实体堆积一堆缺乏概念完整性的属性，这样值对象就会失去业务涵义，操作起来也不方便。

特点

无 ID，不可变，无生命周期，用完即扔。值对象之间通过属性值判断相等性。它的核心本质是值，是一组概念完整的属性组成的集合，用于描述实体的状态和特征。值对象尽量只引用值对象。

聚合

领域模型内的实体和值对象就好比个体，而能让实体和值对象协同工作的组织就是聚合，它用来确保这些领域对象在实现共同的业务逻辑时，能保证数据的一致性。

聚合有两部分

聚合根

上下文边界

这个边界根据业务单一职责和高内聚原则，定义了聚合内部应该包含哪些实体和值对象，而聚合之间的边界是松耦合的。

聚合设计的5项原则

1. 在一致性边界内建模真正的不变条件。

聚合用来封装真正的不变性，而不是简单地将对象组合在一起。聚合内有一套不变的业务规则，各实体和值对象按照统一的业务规则运行，实现对象数据的一致性，边界之外的任何东西都与该聚合无关，这就是聚合能实现业务高内聚的原因。

2. 设计小聚合。

如果聚合设计得过大，聚合会因为包含过多的实体，导致实体之间的管理过于复杂，高频操作时会出现并发冲突或者数据库锁，最终导致系统可用性变差。而小聚合设计则可以降低由于业务过大导致聚合重构的可能性，让领域模型更能适应业务的变化。

3. 通过唯一标识引用其它聚合。

聚合之间是通过关联外部聚合根 ID 的方式引用，而不是直接对象引用的方式。外部聚合的对象放在聚合边界内管理，容易导致聚合的边界不清晰，也会增加聚合之间的耦合度。

4. 在边界之外使用最终一致性。

聚合内数据强一致性，而聚合之间数据最终一致性。在一次事务中，最多只能更改一个聚合的状态。如果一次业务操作涉及多个聚合状态的更改，应采用领域事件的方式异步修改相关的聚合，实现聚合之间的解耦（相关内容我会在领域事件部分详解）。

5. 通过应用层实现跨聚合的服务调用。

为实现微服务内聚合之间的解耦，以及未来以聚合为单位的微服务组合和拆分，应避免跨聚合的领域服务调用和跨聚合的数据库表关联。

特点

高内聚、低耦合，它是领域模型中最底层的边界，可以作为拆分微服务的最小单位，但我不建议你对微服务过度拆分。但在对性能有极致要求的场景中，聚合可以独立作为一个微服务，以满足版本的高频发布和极致的弹性伸缩能力。

聚合根

聚合根的主要目的是为了避免由于复杂数据模型缺少统一的业务规则控制，而导致聚合、实体之间数据不一致性的问题。

特点

聚合根是实体，有实体的特点，具有全局唯一标识，有独立的生命周期。一个聚合只有一个聚合根，聚合根在聚合内对实体和值对象采用直接对象引用的方式进行组织和协调，聚合根与聚合根之间通过 ID 关联的方式实现聚合之间的协同。

比如会员卡的卡号

如果把聚合比作组织，那聚合根就是这个组织的负责人。聚合根也称为根实体，它不仅是实体，还是聚合的管理者。

领域事件（Domain Event）

领域事件表示领域中发生的事件。

一个领域事件将导致进一步的业务操作

如何识别领域事件

在做用户旅程或者场景分析时，我们要捕捉业务、需
求人员或领域专家口中的关键词：“如果发生……，则……”“当做完……的时候，请通
知……”“发生……时，则……”等。在这些场景中，如果发生某种事件后，会触发进一步的
操作，那么这个事件很可能就是领域事件。

比如微服务的消息队列

分情况

1. 微服务内的领域事件

2. 微服务之间的领域事件

通过领域事件驱动的异步化机制，可以推动业务流程和数据在各个不同微服务之间的
流转，实现微服务的解耦，减轻微服务之间服务调用的压力，提升用户体验。

领域事件总体架构

图

1. 事件构建和发布

2. 事件数据持久化

3. 事件总线 (EventBus)

发送消息到MQ，如果发送失败就保存到事件表

4. 消息中间件

5. 事件接收和处理

进阶

如何通过领域事件实现微服务解耦？

怎样进行微服务分层设计？

如何实现层与层之间的服务协作？

通过几种微服务架构模型的对比分析，让你了解领域模型和微服务分层的作用和价值。

DDD 分层架构

用户接口层负责向用户显示信息和解释用户指令。这里的用户可能是：用户、程序、自动化
测试和批处理脚本等等。

应用层是很薄的一层，理论上不应该有业务规则或逻辑，主要面向用例和流程相关的操作。
但应用层又位于领域层之上，因为领域层包含多个聚合，所以它可以协调多个聚合的服务和
领域对象完成服务编排和组合，协作完成业务操作。

领域层的作用是实现企业核心业务逻辑，通过各种校验手段保证业务的正确性。领域层主要

体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。

基础层

DDD 分层架构最重要的原则

DDD 分层架构有一个重要的原则：每层只能与位于其下方的层发生耦合。

架构根据耦合的紧密程度又可以分为两种

严格分层架构

严格分层架构中，领域服务只能被应用服务调用，而应用服务只能被用户接口层调用，服
务是逐层对外封装或组合的，依赖关系清晰。

松散分层架构

在松散分层架构中，领域服务可以同时被应用层或用户接口层调用，服务的依赖关系比较复杂且难管理，甚至容易使核心业务逻辑外泄。

DDD 分层架构如何推动架构演进？

微服务架构的演进

微服务内服务的演进

DDD四层架构 vs 传统三层架构

DDD架构 vs 整洁架构 vs 六边形架构

整洁架构

六边形架构

六边形架构又名“端口适配器架构”。追溯微服务架构的渊源，一般都会涉及到六边形架构。

六边形架构的核心理念是：应用是通过端口与外部进行交互的。

三者比较

在老系统中想升级成DDD，可以引入防腐层

不要把与领域无关的逻辑放在领域层实现，保证领域层的纯洁和领域逻辑的稳定，避免污染
领域模型。也不要把领域模型的业务逻辑放在应用层，这样会导致应用层过于庞大，最终领
域模型会失焦。如果实在无法避免，我们可以引入防腐层，进行新老系统的适配和转换，过
渡期完成后，可以直接将防腐层代码抛弃。

DDD分层架构如何落地在微服务中

分两种情况

1. 项目级微服务

2. 企业级中台微服务

中台

概念

中台到底是什么？

中台是企业级能力复用平台

背景故事

中台 vs 平台

中台来源于平台，但中台和平台相比，它更多体现的是一种理念的转变，它主要体现在这三个关键能力上：
对前台业务的快速响应能力；
企业级复用能力；
从前台、中台到后台的设计、研发、页面操作、流程服务和数据的无缝联通、融合能力。

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

传统企业可以将需要共享的公共能力进行领域建模，建设可共享的通用中台。

传统企业还会将核心能力进行领域建模，建设面向不同渠道的可复用的核心中台。

业务中台

业务中台更多的是支持在线业务

业务中台的建设可采用领域驱动设计方法，通过领域建模，将可复用的公共能力从各个单体剥离，沉淀并组合，采用微服务架构模式，建设成为可共享的通用能力中台。

数据中台

数据中台提供了基础数据处理能力和很多的数据产品给所有业务方去用

数据中台主要完成数据的融合和加工，萃取数据业务价值，支持业务创新，对外提供数据共享服务。

数据中台的主要目标是打通数据孤岛，实现业务融合和创新，包括三大主要职能：

一是完成企业全域数据的采集与存储，实现各不同业务类别中台数据的汇总和集中管
理。

二是按照标准的数据规范或数据模型，将数据按照不同主题域或场景进行加工和处理，
形成面向不同主题和场景的数据应用，比如客户视图、代理人视图、渠道视图、机构视
图等不同数据体系。

三是建立业务需求驱动的数据体系，基于各个维度的数据，深度萃取数据价值，支持业
务和商业模式的创新。

数据中台的建设就可分为三步走：

第一步实现各中台业务数据的汇集，解决数据孤岛和初级数据共享问题。

第二步实现企业级实时或非实时全维度数据的深度融合、加工和共享。

第三步萃取数据价值，支持业务创新，加速从数据转换为业务价值的过程。

其它类型的中台

技术中台

研发中台

移动中台

管理中台

组织中台

中台建设前必须想清楚的四个问题

中台建设的愿景是什么？

愿景帮助我们了解自己中台建设的目标，帮助我们判断哪些事情是符合中台建设愿景的，作为中台团队我们需要去考虑。在这之外，更重要的是帮我们判断哪些事情不是中台要去做的，为中台做减法，这点在中台的建设过程中其实更加重要。

中台的用户和客户是谁？

中台建设虽然需要兼顾各方的利益，但更多主要还是解决企业管理层对于公司长期生存与可持续发展的恐惧与焦虑问题。

中台的钱由谁出？

众筹模式

众筹模式就是用户预付款，生产方承诺一定时间后提供某一类型的产品。

投融资模式

一个产品的建设前期先由投资方出资，按照产品的建设目标经过一段时间的建设期，相对成熟之后，再逐渐地让用户使用，最终通过对于用户的服务，让用户满意，实现收入并收回企业投资且盈利的模式。

中台的目标怎么验证？

通过提前考虑这个问题，让我们可以在建设的中后期规避一些扯皮和风险。

目前业界有一些中台的考核标准我们可以作为参考，例如阿里巴巴的中台考核就是设计成：40% 稳定性 +25% 业务创新 +20% 服务接入量 +15% 客户满意度。

中台建模

DDD 中台设计的过程。DDD 战略设计包括上述的第
一步到第四步，主要为：业务域分解为中台，对中台归类，完成领域建模，建立中台业务模
型。DDD 战术设计是第五步，领域模型映射为微服务，完成中台建设。

DDD vs 微服务 vs 中台

中台本质是平台，需要站在很高的高度来看，分为业务中台和数据中台两种。业务中台是一种业务模型，这个模型是站的角度往往是平台去设计的，是抽象出来的业务模型，数据中台是一个数据平台。
微服务是业务模型的系统落地，
DDD 是一种业务模型设计思想，
它可以同时指导中台业务建模和微服务设计，它们之间就是这样的一个铁三角关系。

“适合自己的才是最好的。”，一切以解决实际问题为出发点。

微服务拆分

理论上DDD的限界上下文就是微服务的边界。我们将限界上下文内的领域模型映射到微服务，就完成了从问题域到软件的解决方案。

DDD vs 中台

根据 DDD 首先要建立通用语言的原则，在将 DDD 的方法引入中台
设计时，我们要先建立中台和 DDD 的通用语言。这里的子域与中台是一致的，那我们就可
以将子域统一为中台。

避免重复造轮子

你需要站在企业高度，将重复的需要共享的通用能力、核心能力沉淀到中台，将分离的业务
能力重组为完整的业务板块，构建可复用的中台业务模型。前端个性能力归前端，后端管理
能力归后台。建立前、中、后台边界清晰，融合协作的企业级可复用的业务模型。

构建中台业务模型

自顶向下的策略

这种策略是先做顶层设计，从最高领域逐级分解为中台，分别建立领域模型，根据业务属性分为通用中台或核心中台。领域建模过程主要基于业务现状，暂时不考虑系统现状。自顶向下的策略适用于全新的应用系统建设，或旧系统推倒重建的情况。

自底向上的策略

这种策略是基于业务和系统现状完成领域建模。首先分别完成系统所在业务域的领域建模；然后对齐业务域，找出具有同类或相似业务功能的领域模型，对比分析领域模型的差异，重组领域对象，重构领域模型。这个过程会沉淀公共和复用的业务能力，会将分散的业务模型整合。自底向上策略适用于遗留系统业务模型的演进式重构。