20 总结（二）：分布式架构关键设计10问
你好，我是欧创新。
前面我们重点讲述了领域建模、微服务设计和前端设计方法，它们组合在一起就可以形成中台建设的整体解决方案。而中台大多基于分布式微服务架构，这种企业级的数字化转型有很多地方值得我们关注和思考。
我们不仅要关注企业商业模式、业务边界以及前中台的融合，还要关注数据技术体系、微服务设计、多活等多领域的设计和协同。结合实施经验和思考，今天我们就来聊聊分布式架构下的几个关键问题。
一、选择什么样的分布式数据库？
分布式架构下的数据应用场景远比集中式架构复杂，会产生很多数据相关的问题。谈到数据，首先就是要选择合适的分布式数据库。
分布式数据库大多采用数据多副本的方式，实现数据访问的高性能、多活和容灾。目前主要有三种不同的分布式数据库解决方案。它们的主要差异是数据多副本的处理方式和数据库中间件。
1. 一体化分布式数据库方案
它支持数据多副本、高可用。多采用 Paxos 协议，一次写入多数据副本，多数副本写入成功即算成功。代表产品是 OceanBase 和高斯数据库。
2. 集中式数据库 + 数据库中间件方案
它是集中式数据库与数据库中间件结合的方案，通过数据库中间件实现数据路由和全局数据管理。数据库中间件和数据库独立部署，采用数据库自身的同步机制实现主副本数据的一致性。集中式数据库主要有 MySQL 和 PostgreSQL 数据库，基于这两种数据库衍生出了很多的解决方案，比如开源数据库中间件 MyCat+MySQL 方案，TBase（基于 PostgreSQL，但做了比较大的封装和改动）等方案。
3. 集中式数据库 + 分库类库方案
它是一种轻量级的数据库中间件方案，分库类库实际上是一个基础 JAR 包，与应用软件部署在一起，实现数据路由和数据归集。它适合比较简单的读写交易场景，在强一致性和聚合分析查询方面相对较弱。典型分库基础组件有 ShardingSphere。
**小结：**这三种方案实施成本不一样，业务支持能力差异也比较大。一体化分布式数据库主要由互联网大厂开发，具有超强的数据处理能力，大多需要云计算底座，实施成本和技术能力要求比较高。集中式数据库 + 数据库中间件方案，实施成本和技术能力要求适中，可满足中大型企业业务要求。第三种分库类库的方案可处理简单的业务场景，成本和技能要求相对较低。在选择数据库的时候，我们要考虑自身能力、成本以及业务需要，从而选择合适的方案。
二、如何设计数据库分库主键？
选择了分布式数据库，第二步就要考虑数据分库，这时分库主键的设计就很关键了。
与客户接触的关键业务，我建议你以客户 ID 作为分库主键。这样可以确保同一个客户的数据分布在同一个数据单元内，避免出现跨数据单元的频繁数据访问。跨数据中心的频繁服务调用或跨数据单元的查询，会对系统性能造成致命的影响。
将客户的所有数据放在同一个数据单元，对客户来说也更容易提供客户一致性服务。而对企业来说，“以客户为中心”的业务能力，首先就要做到数据上的“以客户为中心”。
当然，你也可以根据业务需要用其它的业务属性作为分库主键，比如机构、用户等。
三、数据库的数据同步和复制
在微服务架构中，数据被进一步分割。为了实现数据的整合，数据库之间批量数据同步与复制是必不可少的。数据同步与复制主要用于数据库之间的数据同步，实现业务数据迁移、数据备份、不同渠道核心业务数据向数据平台或数据中台的数据复制、以及不同主题数据的整合等。
传统的数据传输方式有 ETL 工具和定时提数程序，但数据在时效性方面存在短板。分布式架构一般采用基于数据库逻辑日志增量数据捕获（CDC）技术，它可以实现准实时的数据复制和传输，实现数据处理与应用逻辑解耦，使用起来更加简单便捷。
现在主流的 PostgreSQL 和 MySQL 数据库外围，有很多数据库日志捕获技术组件。CDC 也可以用在领域事件驱动设计中，作为领域事件增量数据的获取技术。
四、跨库关联查询如何处理？
跨库关联查询是分布式数据库的一个短板，会影响查询性能。在领域建模时，很多实体会分散到不同的微服务中，但很多时候会因为业务需求，它们之间需要关联查询。
关联查询的业务场景包括两类：第一类是基于某一维度或某一主题域的数据查询，比如基于客户全业务视图的数据查询，这种查询会跨多个业务线的微服务；第二类是表与表之间的关联查询，比如机构表与业务表的联表查询，但机构表和业务表分散在不同的微服务。
如何解决这两类关联查询呢？
对于第一类场景，由于数据分散在不同微服务里，我们无法跨多个微服务来统计这些数据。你可以建立面向主题的分布式数据库，它的数据来源于不同业务的微服务。采用数据库日志捕获技术，从各业务端微服务将数据准实时汇集到主题数据库。在数据汇集时，提前做好数据关联（如将多表数据合并为一个宽表）或者建立数据模型。面向主题数据库建设查询微服务。这样一次查询你就可以获取客户所有维度的业务数据了。你还可以根据主题或场景设计合适的分库主键，提高查询效率。
对于第二类场景，对于不在同一个数据库的表与表之间的关联查询场景，你可以采用小表广播，在业务库中增加一张冗余的代码副表。当主表数据发生变化时，你可以通过消息发布和订阅的领域事件驱动模式，异步刷新所有副表数据。这样既可以解决表与表的关联查询，还可以提高数据的查询效率。
五、如何处理高频热点数据？
对于高频热点数据，比如商品、机构等代码类数据，它们同时面向多个应用，要有很高的并发响应能力。它们会给数据库带来巨大的访问压力，影响系统的性能。
常见的做法是将这些高频热点数据，从数据库加载到如 Redis 等缓存中，通过缓存提供数据访问服务。这样既可以降低数据库的压力，还可以提高数据的访问性能。
另外，对需要模糊查询的高频数据，你也可以选用 ElasticSearch 等搜索引擎。
缓存就像调味料一样，投入小、见效快，用户体验提升快。
六、前后序业务数据的处理
在微服务设计时你会经常发现，某些数据需要关联前序微服务的数据。比如：在保险业务中，投保微服务生成投保单后，保单会关联前序投保单数据等。在电商业务中，货物运输单会关联前序订单数据。由于关联的数据分散在业务的前序微服务中，你无法通过不同微服务的数据库来给它们建立数据关联。
如何解决这种前后序的实体关联呢？
一般来说，前后序的数据都跟领域事件有关。你可以通过领域事件处理机制，按需将前序数据通过领域事件实体，传输并冗余到当前的微服务数据库中。
你可以将前序数据设计为实体或者值对象，并被当前实体引用。在设计时你需要关注以下内容：如果前序数据在当前微服务只可整体修改，并且不会对它做查询和统计分析，你可以将它设计为值对象；当前序数据是多条，并且需要做查询和统计分析，你可以将它设计为实体。
这样，你可以在货物运输微服务，一次获取前序订单的清单数据和货物运输单数据，将所有数据一次反馈给前端应用，降低跨微服务的调用。如果前序数据被设计为实体，你还可以将前序数据作为查询条件，在本地微服务完成多维度的综合数据查询。只有必要时才从前序微服务，获取前序实体的明细数据。这样，既可以保证数据的完整性，还可以降低微服务的依赖，减少跨微服务调用，提升系统性能。
七、数据中台与企业级数据集成
分布式微服务架构虽然提升了应用弹性和高可用能力，但原来集中的数据会随着微服务拆分而形成很多数据孤岛，增加数据集成和企业级数据使用的难度。你可以通过数据中台来实现数据融合，解决分布式架构下的数据应用和集成问题。
你可以分三步来建设数据中台。
第一，按照统一数据标准，完成不同微服务和渠道业务数据的汇集和存储，解决数据孤岛和初级数据共享的问题。
第二，建立主题数据模型，按照不同主题和场景对数据进行加工处理，建立面向不同主题的数据视图，比如客户统一视图、代理人视图和渠道视图等。
第三，建立业务需求驱动的数据体系，支持业务和商业模式创新。
数据中台不仅限于分析场景，也适用于交易型场景。你可以建立在数据仓库和数据平台上，将数据平台化之后提供给前台业务使用，为交易场景提供支持。
八、BFF 与企业级业务编排和协同
企业级业务流程往往是多个微服务一起协作完成的，每个单一职责的微服务就像积木块，它们只完成自己特定的功能。那如何组织这些微服务，完成企业级业务编排和协同呢？
你可以在微服务和前端应用之间，增加一层 BFF 微服务（Backend for Frontends）。BFF 主要职责是处理微服务之间的服务组合和编排，微服务内的应用服务也是处理服务的组合和编排，那这二者有什么差异呢？
BFF 位于中台微服务之上，主要职责是微服务之间的服务协调；**应用服务主要处理微服务内的服务组合和编排。**在设计时我们应尽可能地将可复用的服务能力往下层沉淀，在实现能力复用的同时，还可以避免跨中心的服务调用。
BFF 像齿轮一样，来适配前端应用与微服务之间的步调。它通过 Façade 服务适配不同的前端，通过服务组合和编排，组织和协调微服务。BFF 微服务可根据需求和流程变化，与前端应用版本协同发布，避免中台微服务为适配前端需求的变化，而频繁地修改和发布版本，从而保证微服务核心领域逻辑的稳定。
如果你的 BFF 做得足够强大，它就是一个集成了不同中台微服务能力、面向多渠道应用的业务能力平台。
九、分布式事务还是事件驱动机制？
分布式架构下，原来单体的内部调用，会变成分布式调用。如果一个操作涉及多个微服务的数据修改，就会产生数据一致性的问题。数据一致性有强一致性和最终一致性两种，它们实现方案不一样，实施代价也不一样。
对于实时性要求高的强一致性业务场景，你可以采用分布式事务，但分布式事务有性能代价，在设计时我们需平衡考虑业务拆分、数据一致性、性能和实现的复杂度，尽量避免分布式事务的产生。
领域事件驱动的异步方式是分布式架构常用的设计方法，它可以解决非实时场景的数据最终一致性问题。基于消息中间件的领域事件发布和订阅，可以很好地解耦微服务。通过削峰填谷，可以减轻数据库实时访问压力，提高业务吞吐量和处理能力。你还可以通过事件驱动实现读写分离，提高数据库访问性能。对最终一致性的场景，我建议你采用领域事件驱动的设计方法。
十、多中心多活的设计
分布式架构的高可用主要通过多活设计来实现，多中心多活是一个非常复杂的工程，下面我主要列出以下几个关键的设计。
\1. 选择合适的分布式数据库。数据库应该支持多数据中心部署，满足数据多副本以及数据底层复制和同步技术要求，以及数据恢复的时效性要求。
\2. 单元化架构设计。将若干个应用组成的业务单元作为部署的基本单位，实现同城和异地多活部署，以及跨中心弹性扩容。各单元业务功能自包含，所有业务流程都可在本单元完成；任意单元的数据在多个数据中心有副本，不会因故障而造成数据丢失；任何单元故障不影响其它同类单元的正常运行。单元化设计时我们要尽量避免跨数据中心和单元的调用。
\3. 访问路由。访问路由包括接入层、应用层和数据层的路由，确保前端访问能够按照路由准确到达数据中心和业务单元，准确写入或获取业务数据所在的数据库。
\4. 全局配置数据管理。实现各数据中心全局配置数据的统一管理，每个数据中心全局配置数据实时同步，保证数据的一致性。
总结
企业级分布式架构的实施是一个非常复杂的系统工程，涉及到非常多的技术体系和方法。今天我罗列了 10 个关键的设计领域，每个领域其实都非常复杂，需要很多的投入和研究。在实施的时候，你和你的公司要结合自身情况来选择合适的技术组件和实施方案。
答疑：有关3个典型问题的讲解
你好，我是欧创新。
截至今天这一讲，我们的基础篇和进阶篇的内容就结束了。在这个过程中，我一直有关注大家提的问题。那在实战篇正式开始之前啊，我想针对 3 个比较典型的问题，做一个讲解，希望你也能同步思考，调动自己已学过的内容，这对我们后面实战篇的学习也是有一定帮助的。
问题 1：有关于领域可以划分为核心域、通用域和支撑域，以及子域和限界上下文关系的话题，还有是否有边界划分的量化标准？
我在 [第 02 讲] 中讲到了，在领域不断划分的过程中，领域会被细分为不同的子域，这个过程实际上是将问题范围不断缩小的过程。
借用读者“密码 123456”的总结，他认为：“对于领域问题来说，可以理解为，对一个问题不断地划分，直到划分为我们熟悉的、能够快速处理的小问题。然后再对小问题的处理排列一个优先级。”
这个理解是很到位的。在领域细分到一定的范围后，我们就可以对这个子域进行事件风暴，为这个子域划分限界上下文，建立领域模型，然后就可以基于领域模型进行微服务设计了。
虽然 DDD 没有明确说明子域和限界上下文的关系。我个人认为，子域的划分是一种比较粗的领域边界的划分，它不考虑子域内的领域对象、对象之间的关系和结构。子域的划分往往按照业务阶段或者功能模块边界进行粗分，其目的就是为了让你能够在一个相对较小的问题空间内，比较方便地用事件风暴来梳理业务场景。
而限界上下文本质上也是子域，限界上下文是在明确的子域内，用事件风暴划分出来的。它体现的是一种详细的设计过程。这个过程设计出了领域模型，明确了领域对象以及领域对象的依赖等关系，有了领域模型，你就可以直接进行微服务设计了。
关于核心域、通用域和支撑域，划分这三个不同类型子域的主要目的是为了区分业务域的优先级，确定 IT 战略投入。我们会将重要的资源投入在核心域上，确保好钢用在刀刃上。每个企业由于商业模式或者战略方向不一样，核心域会有一些差异，不要用固定的眼光看待不同企业的核心域。
核心域、通用域和支撑域都是业务领域，只不过重要性和功能属性不一样。采用的 DDD 设计方法和过程，是没有差异的。
从目前来看，还没有可以量化的领域以及限界上下文的划分标准。它主要依赖领域专家经验，以及和项目团队在事件风暴过程中不断地权衡和分析。不要奢望一次迭代就能够给复杂的业务，建立一个完美的领域模型。领域模型很多时候也需要多次迭代才能成型，它也需要不断地演进。但如果是用 DDD 设计出来的领域模型的边界和微服务内聚合的边界非常清晰的话，这个演进过程相对来说会简单很多，所需的时间成本也会很低。
问题 2：关于聚合设计的问题？领域层与基础层为什么要依赖倒置（DIP）？
聚合主要实现核心业务逻辑，里面有很多的领域对象，这些领域对象之间需要通过聚合根进行统一的管理，以确保数据的一致性。
在聚合设计时，我们会用到两个重要的设计模式：工厂（Factory）模式和仓储（Repository）模式。如果你有兴趣详细了解的话，推荐你阅读《实现领域驱动设计》一书的第 11 章和第 12 章。
那为什么要引入工厂模式呢？
这是因为有些聚合内可能含有非常多的实体和值对象，我们需要确保聚合根以及所有被依赖的对象实例同时被创建。如果都通过聚合根来构造，将会非常复杂。因此我们可以通过工厂模式来封装复杂对象的创建过程，但并不是所有对象的构造都需要用到工厂，如果构造过程不复杂，只是单一对象的构造，你用简单的构造方法就足够了。
又为什么要引入仓储模式？解答这个问题的同时，我也一起将依赖倒置的问题解答一下。
在传统的 DDD 四层架构中，所有层都是依赖基础层的。这样做有什么不好的地方呢？如果应用逻辑对基础层依赖太大的话，基础层中与资源有关的代码可能会渗透到应用逻辑中。而现在技术组件的更新频率是很快的，一旦出现基础组件的变更，且基础组件的代码被带入到了应用逻辑中，这样会对上层的应用逻辑产生致命的影响。
为了解耦应用逻辑和基础资源，在基础层和上层应用逻辑之间会增加一层，这一层就是仓储层。一个聚合对应一个仓储，仓储实现聚合内数据的持久化。聚合内的应用逻辑通过接口来访问基础资源，仓储实现在基础层实现。这样应用逻辑和基础资源的实现逻辑是分离的。如果变更基础资源组件，只需要替换仓储实现就可以了，不会对应用逻辑产生太大的影响，这样就实现了应用逻辑与基础资源的解耦，也就实现了依赖倒置。
关于聚合设计过程中的一些原则问题。大部分的业务场景我们都可以通过事件风暴，找到聚合根，建立聚合，划分限界上下文，建立领域模型。但也有部分场景，比如数据计算、统计以及批处理业务场景，所有的实体都是独立无关联的，找不到聚合根，也无法建立领域模型。但是它们之间的业务关系是非常紧密的，在业务上是高内聚的。我们也可以将这类场景作为一个聚合处理，除了不考虑聚合根的设计方法外，其它诸如 DDD 分层架构相关的设计方法都是可以采用的。
一些业务场景，如果复杂度并不高，而用 DDD 设计会带来不必要的麻烦的话，比如增加复杂度，有些原则也是可以突破的，不要为做 DDD 而做 DDD。即使采用传统的方式也是没有关系的，最终以解决实际问题为最佳。但必须记住一点，如果采用传统的设计方式，一定要保证领域模型的边界以及微服务内聚合的逻辑边界清晰，这样的话，以后微服务的演进就不会太复杂。
问题 3：领域事件采用消息异步机制，发布方和订阅方数据如何保证一致性？微服务内聚合之间领域事件是否一定要用事件总线？
在领域事件设计中，为了解耦微服务，微服务之间数据采用最终一致性原则。由于发布方是在消息总线发布消息以后，并不关心数据是否送达，或者送达后订阅方是否正常处理，因此有些技术人会担心发布方和订阅方数据一致性的问题。
那在对数据一致性要求比较高的业务场景，我们是有相关的设计考虑的。也就是发送方和订阅方的事件数据都必须落库，发送方除了保存业务数据以外，在往消息中间件发布消息之前，会先将要发布的消息写入本地库。而接收方在处理消息之前，需要先将收到的消息写入本地库。然后可以采用定期对发布方和订阅方的事件数据对账的操作，识别出不一致的数据。如果数据出现异常或不一致的情况，可以启动定时程序再次发送，必要时可以转人工操作处理。
关于事件总线的问题。由于微服务内的逻辑都在一个进程内，后端数据库也是一个，微服务内的事务相比微服务之间会好控制一些。在处理微服务内的领域事件时，如果引入事件总线，会增加开发的复杂度，那是否引入事件总线，就需要你来权衡。
个人感觉如果你的场景中，不会出现导致聚合之间数据不一致的情况，就可以不使用事件总线。另外，通过应用服务也可以实现聚合之间的服务和数据协调。
结束语 所谓高手，就是跨过坑和大海
你好，我是欧创新。
这是本专栏的最后一讲了，非常感谢你这两个月的陪伴，也非常感谢你的意见和建议。加上前期的专栏筹备，前前后后也有半年了，这半年其实也是自我提升的过程，通过专栏，我将原来不成体系的经验、方法和设计思想，整理成了中台和微服务设计的系统的理论和知识体系。
在撰写专栏时，我站在架构师的角度，尽力将我在实践过程中的经验、思考和体会，以及原创案例等全面详细地呈现给你。希望能够对你的 DDD 实践和架构设计有所帮助，也希望你能快速成长为具有企业级战略视角的架构师和 DDD 设计大师。
那说到成长，相信我们每个人的轨迹都是独特的，但有一点，你一定和我有同样的体会。那就是“所谓高手，就是跨过坑和大海！”每一步都是积累，每一步都是经验，每一步都算数！所以啊，在本专栏的最后，我还是要分享一些干货给你，也是我曾经踩过的一些坑。
很多人接触 DDD，可能是从 DDD 战术设计开始的，因此不知道如何开始 DDD 实践。这个专栏开启后，咱们就可以从领域建模开始了。有了领域模型，我们就可以划分出合理的微服务的逻辑和物理边界；也是因为有了它，我们才能识别出微服务内各关键对象，并建立它们之间的依赖关系，然后开始微服务的设计和开发。
而很多 DDD 和微服务设计的书籍，大多侧重于讲述 DDD 战术设计或者一些通用的微服务设计模式。这些书籍大多没有告诉我们：如何从业务领域开始，去构建领域模型？如何用 DDD 的思想，来指导中台和微服务设计？如何将领域模型作为输入，来设计和拆分微服务？如何将 DDD 知识体系组合起来，应用到中台和微服务的设计和开发中…
这也是本专栏与这些书籍的不同点。当然，我并不是说它们不好，只是各有侧重。在真正实践的时候，强大的知识基础自然也是刚需，你可以把专栏和书籍结合起来学习，从而发挥最大效能。
下面是我推荐的几本书，这些内容是可以和本专栏互补的，如果你有意愿进一步学习 DDD，它们是非常好的学习资料。
DDD 是一个相对复杂的方法体系，它与传统的软件开发模式或者流程存在一定的差异。在实践 DDD 时，你可能会遇到一些困难。企业需要在研发模式上有一定的调整，同时项目团队也需要提升 DDD 的设计和技术能力，培养适合 DDD 成长的土壤。拔高一点看的话，我觉得你可能会遇到这样三个大坑，下面我来说一说我的看法。
1. 业务专家或领域专家的问题
传统企业中业务人员是需求的主要提出者，但由于部门墙，他们很少会参与到软件设计和开发过程中。如果研发模式不调整，你不要奢望业务人员会主动加入到项目团队中，一起来完成领域建模。没有业务人员的参与，是不是就会觉得没有领域专家，不能领域建模了呢？其实并不是这样的。
对于成熟业务的领域建模，我们可以从团队需求人员或者经验丰富的设计或开发人员中，挑选出能够深刻理解业务内涵和业务管理要求的人员，担任领域专家完成领域建模。对于同时熟悉业务和面向对象设计的项目人员，这种设计经验尤其重要，他们可以利用面向对象的设计经验，更深刻地理解和识别出领域模型的领域对象和业务行为，有助于推进领域模型的设计。
而对于新的创业企业，他们面对的是从来没人做过的全新的业务和领域，没有任何可借鉴的经验，更不要提什么领域专家。对于这种情况，就需要团队一起经过更多次更细致的事件风暴，才能建立领域模型。当然建模过程离不开产品愿景分析，这个过程是确定和统一系统建设目标以及项目的核心竞争力在哪里。这种初创业务的领域模型往往需要经过多次迭代才能成型，不要奢望一次就可以建立一个完美的领域模型。
2. 团队 DDD 的理念和技术能力问题
完成领域建模和微服务设计后，就要投入开发和测试了。这时你可能会发现一些开发人员，并不理解 DDD 设计方法，不知道什么是聚合、分层以及边界？也不知道服务的依赖以及层与层之间的职责边界是什么？
这样容易出现设计很精妙，而开发很糟糕的状况。遇到这种情况，除了要在项目团队普及 DDD 的知识和设计理念外，你还要让所有的项目成员尽早地参与到领域建模中，事件风暴的过程除了统一团队语言外，还可以让团队成员提前了解领域模型、设计要点和注意事项。
3. DDD 设计原则问题
DDD 基于各种考虑，有很多的设计原则，也用到了很多的设计模式。条条框框多了，很多人可能就会被束缚住，总是担心或犹豫这是不是原汁原味的 DDD。其实我们不必追求极致的 DDD，这样做反而会导致过度设计，增加开发复杂度和项目成本。
DDD 的设计原则或模式，是考虑了很多具体场景或者前提的。有的是为了解耦，如仓储服务、边界以及分层，有的则是为了保证数据一致性，如聚合根管理等。在理解了这些设计原则的根本原因后，有些场景你就可以灵活把握设计方法了，你可以突破一些原则，不必受限于条条框框，大胆选择最合适的方法。
以上就是我对这三个问题的理解了。
用好 DDD 的关键，首先要领悟 DDD 的核心设计思想和理念，了解它为什么适合微服务架构，然后慢慢体会、消化、吸收和实践。DDD 体系虽然复杂，但也是有矩可循的，照着样例多做几个事件风暴，完成领域建模和微服务设计，体会 DDD 的整个设计过程。相信你很快就能领悟到 DDD 的核心设计理念了，这样就可以做到收放自如，趟出一条适合自己的 DDD 实践之路。
好了，到了该说再见的时候了。再次感谢你的陪伴，期待再相遇！愿我们都能跨过坑和大海，开辟出一片广阔新天地！