极客时间已完结课程限时免费阅读

06 | 领域事件：解耦微服务的关键

06 | 领域事件：解耦微服务的关键-极客时间

06 | 领域事件：解耦微服务的关键

2019-10-25 欧创新 来自北京
《DDD实战课》
课程介绍

讲述：欧创新

时长17:38大小14.11M

你好，我是欧创新。今天我们来聊一聊“领域事件（Domain Event）”。
在事件风暴（Event Storming）时，我们发现除了命令和操作等业务行为以外，还有一种非常重要的事件，这种事件发生后通常会导致进一步的业务操作，在 DDD 中这种事件被称为领域事件。
这只是最简单的定义，并不能让我们真正理解它。那到底什么是领域事件？领域事件的技术实现机制是怎样的？这一讲，我们就重点解决这两个大的问题。

领域事件

领域事件是领域模型中非常重要的一部分，用来表示领域中发生的事件。一个领域事件将导致进一步的业务操作，在实现业务解耦的同时，还有助于形成完整的业务闭环。
举例来说的话，领域事件可以是业务流程的一个步骤，比如投保业务缴费完成后，触发投保单转保单的动作；也可能是定时批处理过程中发生的事件，比如批处理生成季缴保费通知单，触发发送缴费邮件通知操作；或者一个事件发生后触发的后续动作，比如密码连续输错三次，触发锁定账户的动作。
那如何识别领域事件呢？
很简单，和刚才讲的定义是强关联的。在做用户旅程或者场景分析时，我们要捕捉业务、需求人员或领域专家口中的关键词：“如果发生……，则……”“当做完……的时候，请通知……”“发生……时，则……”等。在这些场景中，如果发生某种事件后，会触发进一步的操作，那么这个事件很可能就是领域事件。
那领域事件为什么要用最终一致性，而不是传统 SOA 的直接调用的方式呢？
我们一起回顾一下 [第 05 讲] 讲到的聚合的一个设计原则：在边界之外使用最终一致性。一次事务最多只能更改一个聚合的状态。如果一次业务操作涉及多个聚合状态的更改，应采用领域事件的最终一致性。
领域事件驱动设计可以切断领域模型之间的强依赖关系，事件发布完成后，发布方不必关心后续订阅方事件处理是否成功，这样可以实现领域模型的解耦，维护领域模型的独立性和数据的一致性。在领域模型映射到微服务系统架构时，领域事件可以解耦微服务，微服务之间的数据不必要求强一致性，而是基于事件的最终一致性。
回到具体的业务场景，我们发现有的领域事件发生在微服务内的聚合之间，有的则发生在微服务之间，还有两者皆有的场景，一般来说跨微服务的领域事件处理居多。在微服务设计时不同领域事件的处理方式会不一样。

1. 微服务内的领域事件

当领域事件发生在微服务内的聚合之间，领域事件发生后完成事件实体构建和事件数据持久化，发布方聚合将事件发布到事件总线，订阅方接收事件数据完成后续业务操作。
微服务内大部分事件的集成，都发生在同一个进程内，进程自身可以很好地控制事务，因此不一定需要引入消息中间件。但一个事件如果同时更新多个聚合，按照 DDD“一次事务只更新一个聚合”的原则，你就要考虑是否引入事件总线。但微服务内的事件总线，可能会增加开发的复杂度，因此你需要结合应用复杂度和收益进行综合考虑。
微服务内应用服务，可以通过跨聚合的服务编排和组合，以服务调用的方式完成跨聚合的访问，这种方式通常应用于实时性和数据一致性要求高的场景。这个过程会用到分布式事务，以保证发布方和订阅方的数据同时更新成功。

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

跨微服务的领域事件会在不同的限界上下文或领域模型之间实现业务协作，其主要目的是实现微服务解耦，减轻微服务之间实时服务访问的压力。
领域事件发生在微服务之间的场景比较多，事件处理的机制也更加复杂。跨微服务的事件可以推动业务流程或者数据在不同的子域或微服务间直接流转。
跨微服务的事件机制要总体考虑事件构建、发布和订阅、事件数据持久化、消息中间件，甚至事件数据持久化时还可能需要考虑引入分布式事务机制等。
微服务之间的访问也可以采用应用服务直接调用的方式，实现数据和服务的实时访问，弊端就是跨微服务的数据同时变更需要引入分布式事务，以确保数据的一致性。分布式事务机制会影响系统性能，增加微服务之间的耦合，所以我们还是要尽量避免使用分布式事务。

领域事件相关案例

我来给你介绍一个保险承保业务过程中有关领域事件的案例。
一个保单的生成，经历了很多子域、业务状态变更和跨微服务业务数据的传递。这个过程会产生很多的领域事件，这些领域事件促成了保险业务数据、对象在不同的微服务和子域之间的流转和角色转换。
在下面这张图中，我列出了几个关键流程，用来说明如何用领域事件驱动设计来驱动承保业务流程。
事件起点：客户购买保险 - 业务人员完成保单录入 - 生成投保单 - 启动缴费动作。
1. 投保微服务生成缴费通知单，发布第一个事件：缴费通知单已生成，将缴费通知单数据发布到消息中间件。收款微服务订阅缴费通知单事件，完成缴费操作。缴费通知单已生成，领域事件结束。
2. 收款微服务缴费完成后，发布第二个领域事件：缴费已完成，将缴费数据发布到消息中间件。原来的订阅方收款微服务这时则变成了发布方。原来的事件发布方投保微服务转换为订阅方。投保微服务在收到缴费信息并确认缴费完成后，完成投保单转成保单的操作。缴费已完成，领域事件结束。
3. 投保微服务在投保单转保单完成后，发布第三个领域事件：保单已生成，将保单数据发布到消息中间件。保单微服务接收到保单数据后，完成保单数据保存操作。保单已生成，领域事件结束。
4. 保单微服务完成保单数据保存后，后面还会发生一系列的领域事件，以并发的方式将保单数据通过消息中间件发送到佣金、收付费和再保等微服务，一直到财务，完后保单后续所有业务流程。这里就不详细说了。
总之，通过领域事件驱动的异步化机制，可以推动业务流程和数据在各个不同微服务之间的流转，实现微服务的解耦，减轻微服务之间服务调用的压力，提升用户体验。

领域事件总体架构

领域事件的执行需要一系列的组件和技术来支撑。我们来看一下这个领域事件总体技术架构图，领域事件处理包括：事件构建和发布、事件数据持久化、事件总线、消息中间件、事件接收和处理等。下面我们逐一讲一下。

1. 事件构建和发布

事件基本属性至少包括：事件唯一标识、发生时间、事件类型和事件源，其中事件唯一标识应该是全局唯一的，以便事件能够无歧义地在多个限界上下文中传递。事件基本属性主要记录事件自身以及事件发生背景的数据。
另外事件中还有一项更重要，那就是业务属性，用于记录事件发生那一刻的业务数据，这些数据会随事件传输到订阅方，以开展下一步的业务操作。
事件基本属性和业务属性一起构成事件实体，事件实体依赖聚合根。领域事件发生后，事件中的业务数据不再修改，因此业务数据可以以序列化值对象的形式保存，这种存储格式在消息中间件中也比较容易解析和获取。
为了保证事件结构的统一，我们还会创建事件基类 DomainEvent（参考下图），子类可以扩充属性和方法。由于事件没有太多的业务行为，实现方法一般比较简单。
事件发布之前需要先构建事件实体并持久化。事件发布的方式有很多种，你可以通过应用服务或者领域服务发布到事件总线或者消息中间件，也可以从事件表中利用定时程序或数据库日志捕获技术获取增量事件数据，发布到消息中间件。

2. 事件数据持久化

事件数据持久化可用于系统之间的数据对账，或者实现发布方和订阅方事件数据的审计。当遇到消息中间件、订阅方系统宕机或者网络中断，在问题解决后仍可继续后续业务流转，保证数据的一致性。
事件数据持久化有两种方案，在实施过程中你可以根据自己的业务场景进行选择。
持久化到本地业务数据库的事件表中，利用本地事务保证业务和事件数据的一致性。
持久化到共享的事件数据库中。这里需要注意的是：业务数据库和事件数据库不在一个数据库中，它们的数据持久化操作会跨数据库，因此需要分布式事务机制来保证业务和事件数据的强一致性，结果就是会对系统性能造成一定的影响。

3. 事件总线 (EventBus)

事件总线是实现微服务内聚合之间领域事件的重要组件，它提供事件分发和接收等服务。事件总线是进程内模型，它会在微服务内聚合之间遍历订阅者列表，采取同步或异步的模式传递数据。事件分发流程大致如下：
如果是微服务内的订阅者（其它聚合），则直接分发到指定订阅者；
如果是微服务外的订阅者，将事件数据保存到事件库（表）并异步发送到消息中间件；
如果同时存在微服务内和外订阅者，则先分发到内部订阅者，将事件消息保存到事件库（表），再异步发送到消息中间件。

4. 消息中间件

跨微服务的领域事件大多会用到消息中间件，实现跨微服务的事件发布和订阅。消息中间件的产品非常成熟，市场上可选的技术也非常多，比如 Kafka，RabbitMQ 等。

5. 事件接收和处理

微服务订阅方在应用层采用监听机制，接收消息队列中的事件数据，完成事件数据的持久化后，就可以开始进一步的业务处理。领域事件处理可在领域服务中实现。

领域事件运行机制相关案例

这里我用承保业务流程的缴费通知单事件，来给你解释一下领域事件的运行机制。这个领域事件发生在投保和收款微服务之间。发生的领域事件是：缴费通知单已生成。下一步的业务操作是：缴费。
事件起点：出单员生成投保单，核保通过后，发起生成缴费通知单的操作。
1. 投保微服务应用服务，调用聚合中的领域服务 createPaymentNotice 和 createPaymentNoticeEvent，分别创建缴费通知单、缴费通知单事件。其中缴费通知单事件类 PaymentNoticeEvent 继承基类 DomainEvent。
2. 利用仓储服务持久化缴费通知单相关的业务和事件数据。为了避免分布式事务，这些业务和事件数据都持久化到本地投保微服务数据库中。
3. 通过数据库日志捕获技术或者定时程序，从数据库事件表中获取事件增量数据，发布到消息中间件。这里说明：事件发布也可以通过应用服务或者领域服务完成发布。
4. 收款微服务在应用层从消息中间件订阅缴费通知单事件消息主题，监听并获取事件数据后，应用服务调用领域层的领域服务将事件数据持久化到本地数据库中。
5. 收款微服务调用领域层的领域服务 PayPremium，完成缴费。
6. 事件结束。
提示：缴费完成后，后续流程的微服务还会产生很多新的领域事件，比如缴费已完成、保单已保存等等。这些后续的事件处理基本上跟 1～6 的处理机制类似。

总结

今天我们主要讲了领域事件以及领域事件的处理机制。领域事件驱动是很成熟的技术，在很多分布式架构中得到了大量的使用。领域事件是 DDD 的一个重要概念，在设计时我们要重点关注领域事件，用领域事件来驱动业务的流转，尽量采用基于事件的最终一致，降低微服务之间直接访问的压力，实现微服务之间的解耦，维护领域模型的独立性和数据一致性。
除此之外，领域事件驱动机制可以实现一个发布方 N 个订阅方的模式，这在传统的直接服务调用设计中基本是不可能做到的。

思考题

思考一下你公司有哪些业务场景可以采用领域事件驱动的设计方式？
欢迎留言和我分享你的思考，你也可以把今天所学分享给身边的朋友，邀请他加入探讨，共同进步。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 37

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
05 | 聚合和聚合根：怎样设计聚合？
下一篇
07 | DDD分层架构：有效降低层与层之间的依赖
 写留言

精选留言(121)

  • 阿神
    2019-10-25
    微服务内的领域事件我建议少用，增加复杂性了

    作者回复: 我跟你的观点一样。

    共 20 条评论
    59
  • 兆哲
    2020-01-31
    在公司与同事沟通微服务之间的关系的时候，DDD提倡服务之间使用领域事件进行解耦， 但是某些同事觉得，rpc调用与通过总线发布事件，在执行的内容上没有本质上减少的东西（RPC 调用失败也可以加入重试机制），并且这种解耦方式可能会导致追踪调用链路更加困难。 如何看待这样的解读呢？

    作者回复: 在微服务设计时，微服务之间尽量通过领域事件的方式来解耦，耦合度过高，在一个微服务出现问题时容易导致整体出现雪崩现象。这种异步方式不仅可以解耦微服务，还可以起到削峰填谷的作用。所以非实时的调用尽量采用领域事件的方式。

    共 11 条评论
    27
  • 杨杰
    2019-10-28
    关于领域事件有几个问题： 1、如果采用了主流的消息队列（如rabbitmq，kafka，rocketmq），是否领域事件还需要持久化？ 2、对于领域事件的内容，是否需要把所有变化（或绝大多数）的内容都保存到事件里面（比如保单里面的所有内容）？这样的话这个这个领域事件会不会比较大？ 3、关于领域事件还有一种方案就是基于数据库cdc的方式，在系统中有大量领域事件的场景下，是否cdc的形式更加灵活一点？
    展开

    作者回复: 第一个问题：虽然这些消息队列自身有持久化的功能，但是中间过程，或者在订阅到数据后，在处理之前出问题，需要进行数据对账，这样就没法找到发布时和处理后的数据版本。关键的业务数据我建议还是落库比较好。 第二个问题：事件实体的业务数据还是按需发布比较好，避免不必要的业务信息泄露。 第三个问题：CDC的设计方式比较简单，属于数据库底层的技术，不会对上层应用产生太多的影响。

    共 10 条评论
    23
  • 游泳速度快内裤跟不上
    2019-10-25
    跨微服务的聚合间的领域事件驱动用消息中间件来衔接，这个比较容易理解，同一微服务内的聚合间的在实现层面如何来衔接呢，不太清楚这里面说的事件总线是一个什么概念，这个落实到代码上的话具体如何实现呢

    作者回复: 事件总线你可以理解为运行在同一个进程内的消息中间件，它是一个很小的技术组件，可以通过配置支持异步或同步的消息机制。具体实现你可以查阅一下Eventbus组件相关的资料。

    共 3 条评论
    15
  • 信了
    2020-10-26
    在领域事件运行机制相关案例中，投保微服务有两个领域服务，createPaymentNotice 和 createPaymentNoticeEvent，createPaymentNoticeEvent是为了创建缴费通知单事件，而createPaymentNotice是做什么的？

    作者回复: createPaymentNotice完成领域模型的业务逻辑：创建缴费通知单，createPaymentNoticeEvent是在领域逻辑完成后，执行领域事件发布逻辑：创建缴费通知单事件。在这个案例中，将业务逻辑处理和事件处理逻辑做了分离，然后在应用层来编排，这样的好处是可以实现事件发布逻辑的复用。如果不需要复用，你也可以直接在统一个领域服务中完成业务逻辑处理和领域事件发布逻辑，不需要上升到应用层来编排。

    共 3 条评论
    11
  • 昌南一枝花
    2020-08-04
    微服务内使用诸如SpringEvent同步方式保证在一个事务在修改多个聚合数据时，数据一致性得到了保证。但和前一讲提到的聚合设计原则跨聚合操作不应放在一个事务中，而应保证最终一致性略有矛盾。 是不是可以理解为Martinflow原本是想按聚合拆分微服务，所以跨聚合的操作不应放在一个事务里，否则没法按聚合拆分了。但实际应用中很少按聚合拆分微服务，为了方便也就允许跨聚合修改放一个本地事务里，后面万一要按聚合拆分微服务再拆分本地事务。
    展开

    作者回复: 这是因为聚合是微服务内最小的业务功能单元。为了保证聚合内数据更新时，符合聚合内固定的业务规则，在一次事务提交时通常会将聚合内所有变更的对象数据作为整体，通过聚合领域服务或聚合根方法一次通过仓储完成数据持久化操作。如果在一次交易中需要同时更新多个聚合数据，那么每一个聚合就是一个独立的数据提交单元，我们需要确保多个聚合数据都能在这个交易中提交更新成功，以保证不同聚合数据的一致性。 为什么要做聚合之间的解耦，这是因为微服务的架构演进基本是以聚合为单位来演进的，未来在业务演进时微服务可能会根据聚合功能来重新拆分和组合聚合，所以要提前做好聚合之间的解耦，如果聚合的解耦做的不好，微服务演进时重新拆分和组合的工作量会非常大。

    共 3 条评论
    8
  • zj
    2019-11-21
    spring提供的事件机制我感觉也可以啊，可以用在微服务内

    作者回复: 现在的技术路线很多，只要能保证在一个事务在修改多个聚合数据时，能保证数据一致性就可以使用。

    共 2 条评论
    7
  • cup
    2020-01-06
    老师，您好，有几个问题想请教一下 1、领域事件和一般的微服务之间的rpc调用区别是什么，因为大部分通信还是同步的rpc或者http调用，那每次rpc调用做一次更新操作就是一次领域事件么 2、大家都比较疑惑的问题 “微服务内应用服务，可以通过跨聚合的服务编排和组合，以服务调用的方式完成跨聚合的访问，这种方式通常应用于实时性和数据一致性要求高的场景。这个过程会用到分布式事务，以保证发布方和订阅方的数据同时更新成功。” 老师的答案是：微服务内主要是因为跨聚合了。一个聚合一个仓储，在一次修改多个聚合的时候，可能会存在数据不一致的情况，所以用事件总线或者分布式事务。 您这里说的一个聚合一个仓储是指的不同的聚合使用不同的数据库是么？普通数据库事务无法保证跨库操作的数据一致性，所以使用分布式事务？这样做是为了不同聚合之间解耦，方便以后的微服务拆分？ 但如果简化一下，可不可以同一微服务中不同聚合的数据放在一个库里，在应用服务开启数据库事务，操作两个聚合的数据，然后结束事务 3、同一个微服务内为什么不能用消息中间件呢，比如一个聚合生产，扔到rabbitmq，同一微服务里面另一个聚合消费 消息保存到进程内部，如果消费能力较低，会不会内存溢出
    展开

    作者回复: 1、领域事件方式主要是采用异步方式，实现数据的最终一致性。 2、一个聚合一个仓储，是指一个聚合与数据库交互的仓储服务是一个，并不是指一个聚合一个数据库。因为在DDD中为了保证聚合内数据和业务规则的一致性，通过聚合根将所有的实体等数据作为一个整体持久化到数据库中，所以一次事务只能修改一个聚合的数据。而如果一个操作跨了多个聚合的话，就需要考虑事务的概念了，其中有两种实现方式：最终一致性的事件总线机制和Saga等分布式事务的方式。这样也是为了聚合之间的解耦。 3、在同一个微服务内采用消息中间件过重了，事件总线属于轻量级的可实现发布订阅基本功能。

    共 3 条评论
    7
  • 朱振光
    2019-10-25
    内容很充实，但还是有两个问题。 1. 在采取最终一致性的情况下，event消费端如果出现错误，消费失败，但是之前的业务都成功了，虽然记录了event dB，但是后续如何处理，是需要人工介入解决吗？如果人工介入再解决，前端用户会不会看到数据不一致，体验不好？ 2. 因为event都是异步发送，当最后一个event消费成功后，如何有效的通知前端界面，是用Web Socket吗？还是需要前端轮询到后台看是否都成功
    展开

    作者回复: 第一个问题，失败的情况应该比例是很少的。失败的信息可以采用多次重发的方式，如果这个还解决不了，只能将有问题的数据放到一个问题数据区，人工解决。当然要确保一个前提，要保证数据的时序性，不能覆盖已经产生的数据。 第二个问题，一般来说发布方不会等待订阅方反馈结果。发布方有发布的事件表，订阅方有消费事件表，你可以采用每日对账的方式来发现问题数据。

    共 3 条评论
    7
  • 堵车
    2019-12-16
    我看到第一条留言，微服务领域时间建议少用，增加了复杂性。我有这么一个场景，用户入住一个房间后，要修改房态。如果不用领域事件，那么就得将入住和改房态写在同一个事务里。这里面入住是主操作，改房态是副操作。副操所除了问题，导致事务回滚，主操作也将无效，用户入住不成功。

    作者回复: 在微服务内，不是少用领域事件，是少用事件总线。在DDD中是以聚合为单位进行数据管理的，如果一次操作会修改同一个微服务内的多个聚合的数据，你就需要保证多个聚合的数据一致性，为了解耦不同聚合，你需要采用分布式事务或者用事件总线两种方式，用事件总线不太方便管理服务和数据的关系，你可以用类似saga之类的分布式事务技术。总之需要确保你的不同聚合的业务规则和数据一致性，尽量减少系统建设复杂度。

    共 7 条评论
    6
  • itrickzhang
    2019-12-11
    欧老师我想问下，微服务之间用消息中间件通讯，那么注册中心是否是微服务设计的一个鸡肋

    作者回复: 不是这样的。消息中间件主要用于微服务之间的异步处理，其实很多场景还是实时服务调用的。

    共 3 条评论
    5
  • Geek_a91670
    2019-10-31
    "微服务内应用服务，可以通过跨聚合的服务编排和组合，以服务调用的方式完成跨聚合的访问，这种方式通常应用于实时性和数据一致性要求高的场景。这个过程会用到分布式事务，以保证发布方和订阅方的数据同时更新成功。" -------服务类的领域事件怎么还牵扯到分布式事务了呢?

    作者回复: 如果一个领域事件会同时修改多个聚合之间的数据的话，可能会存在不同聚合内数据一致性的问题。事件总线的方式可以以同步或者异步的方式来保证聚合之间数据的一致性。多个聚合之上的应用服务也可以来协调这种数据一致性，但由于是跨聚合，需要保证多个聚合同时成功，这可以用事务的方式来实现。但是由于在同一个微服务内的进程内，出错的概率要比微服务之间小得多。

    共 11 条评论
    5
  • 风中舞者
    2020-08-20
    老师，不同微服务之间领域事件的调用，基于消息队列的事件发布，在微服务代码模型上是放到应用层还是领域层比较合适。

    作者回复: 事件发布在领域层和应用层都可以，根据代码情况自由选择。事件订阅建议放在应用层。

    3
  • 乖，摸摸头
    2020-06-06
    好嘛，我摊牌了，我是写php 的，看了 第13章后又回来把这章看了一遍，基于 laravel框架做得开发， 框架里的 view controller model 层 对应 用户接口层 应用层 领域层 通用层 是怎么划分的？请教一下老师

    作者回复: 建议你看一下第7章里面，里面有“三层架构如何演进到 DDD 分层架构”的内容，这里面有三层架构和DDD分层架构的对比分析。

    3
  • wallace
    2020-04-04
    老师好，请问从投保到核保通过是通过领域事件完成的，这种异步操作前端客户如何实时感知处理结果，并进行进一步处理，如缴费？

    作者回复: 在后台会有一些监听的机制，当核保通过后，接收端会监听到核保通过的消息，接收相关数据并修改投保单核保状态后。前端可以采用待办刷新或者用Ajax等前端技术刷新后端的最新数据。

    3
  • Luke
    2020-02-01
    将事件发布放在应用层是否合适呢，还是应该视具体业务来? 看到老师的「领域事件运行机制相关案例」中，「创建缴费通知单事件」是在应用层，独立发布的。我们开发的业务中，事件发布的调用直接放在领域层逻辑中了。

    作者回复: 事件发布应用层和领域层两个都是可以的，看具体情况。事件接收建议放应用层。

    共 3 条评论
    3
  • 观弈道人
    2019-10-28
    欧老师你好：事件有没有被消费成功（消费端成功拿到消息或消费端业务处理成功），一般如何通知到消息生产端?谢谢。

    作者回复: 因为事件发布方有事件实体的原始的持久化数据，事件订阅方也有自己接收的持久化数据。一般可以通过定期对账的方式检查数据的一致性。

    共 3 条评论
    3
  • keys头
    2021-01-19
    欧老师，共享的数据类微服务，也就是数据代码类的数据字典系统应该怎么设计？有什么要点和注意事项吗？某一类字典数据可能只有一张表，是不是有必要把其他类的数据也放到同一个微服务中？比方说品牌库和行业库，各自都只有增删改查的功能。另外，有没有什么好的资料可以提供参考？

    作者回复: 这类业务没有太多的业务逻辑，所以基本没有领域模型的概念，整个业务逻辑读多写少，其微服务主要是提供查询服务，所以按照传统方式设计也是可以的，不必先构建领域模型，然后设计微服务。 但是这类数据可能会与业务数据进行组合查询的可能，而他们分别在不同的微服务中。这时，你可以将这部分代码类数据以事件驱动的方式复制到业务数据库中。另外如果业务系统需要考虑多中心多活，这部分数据可能需要部署在不同的数据中心，这类数据属于全局数据，这时可以按照一写多读的设计方式，在一个地集中完成写入，而在多个数据中心提供读的数据副本，为多个数据中心提供数据查询服务。

    共 3 条评论
    3
  • 有爱有波哥
    2020-12-18
    欧老师 怎么聚合之间怎么实现强一致性

    作者回复: 聚合之间强一致可以在应用层的应用服务中用事务来实现。

    2
  • JKing
    2020-08-21
    老师我还有一个疑问，同一个微服务跨聚合的业务编排我理解可以在应用层application进行编排吧，跨服务的业务依赖是通过领域事件来进行解耦吧？

    作者回复: 是的。

    2