微服务事件驱动架构的设计选择

Question

假设我们有以下内容：

DDD聚合A和B，A可以引用B。

一个管理 A 的微服务，它公开以下命令：

• 创建一个
• 删除A
• 将 A 链接到 B
• 取消 A 与 B 的链接

一个微服务管理 B，它公开以下命令：

• 创建 B
• 删除B

成功的创建、删除、链接或取消链接总是会导致执行该操作的微服务发出相应的事件。

为这两个微服务设计事件驱动架构的最佳方法是：

1. A 和 B 最终将始终保持一致。通过一致性，我的意思是如果 B 不存在，则 A 不应引用 B。
2. 来自两个微服务的事件可以轻松地投射到单独的读取模型中，在该模型上可以进行跨越 A 和 B 的查询

具体来说，以下示例可能会导致暂时的不一致状态，但在所有情况下都必须最终恢复一致性：

示例 1

• 初始一致状态：A 存在，B 不存在，A 未链接到 B
• 命令：将 A 链接到 B

示例 2

• 初始一致状态：A存在，B存在，A链接到B
• 命令：删除B

示例 3

• 初始一致状态：A存在，B存在，A未链接到B
• 同时执行两个命令：将 A 链接到 B 并删除 B

我有两个解决方案。

解决方案 1

• 微服务 A 仅允许将 A 链接到 B，前提是它先前已收到“B 创建”事件且未收到“B 已删除”事件。
• 仅当微服务 B 之前未收到“A 链接到 B”事件，或者该事件之后出现“A 与 B 未链接”事件时，微服务 B 才允许删除 B。
• 微服务 A 侦听“B 已删除”事件，并在接收到此类事件后，将 A 与 B 取消链接（针对 B 在收到链接到 B 事件的 A 之前被删除的竞争条件）。

解决方案 2：

• 微服务 A 始终允许将 A 链接到 B。
• 微服务 B 侦听“A 链接到 B”事件，并在收到此类事件后验证 B 是否存在。如果没有，它会发出“拒绝 B 的链接”事件。
• 微服务 A 侦听“B 已删除”和“链接到 B 被拒绝”事件，并在收到此类事件后，将 A 与 B 取消链接。

编辑：Guillaume 提出的解决方案 3：

• 微服务 A 仅允许在之前未收到“B 已删除”事件的情况下将 A 链接到 B。
• 微服务 B 始终允许删除 B。
• 微服务 A 侦听“B 已删除”事件，并在收到此类事件后，将 A 与 B 取消链接。

我看到的解决方案 2 的优势是微服务不需要跟踪其他服务发出的过去事件。在解决方案 1 中，基本上每个微服务都必须维护另一个微服务的读取模型。

解决方案 2 的一个潜在缺点可能是在读取模型中投射这些事件会增加复杂性，特别是如果将更多遵循相同模式的微服务和聚合添加到系统中。

一种或另一种解决方案是否有其他（不利）优势，甚至是我不知道的反模式，应该不惜一切代价避免？ 有比我建议的两个更好的解决方案吗？

任何建议将不胜感激。

Answer 1

微服务 A 仅在之前收到“B 创建”事件且没有“B 删除”事件的情况下才允许将 A 链接到 B。

这里有一个潜在的问题；考虑两条消息之间的竞争，link A to B 和 B Created。如果B Created 消息恰好先到达，那么一切都按预期连接。如果B Created 恰好第二个到达，则链接不会发生。简而言之，您的业务行为取决于您的消息管道。

Udi Dahan, 2010

时间上的微秒差异不应影响核心业务行为。

解决方案 2 的一个潜在缺点可能是在读取模型中投射这些事件会增加复杂性，特别是如果将更多遵循相同模式的微服务和聚合添加到系统中。

我根本不喜欢那种复杂性；听起来工作量很大，但商业价值并不高。

异常报告可能是一个可行的替代方案。 Greg Young talked about this in 2016。简而言之;拥有一个检测不一致状态的监视器并修复这些状态可能就足够了。

稍后会添加自动修复。 Rinat Abdullin described这个进展真好。

自动化版本最终看起来类似于解决方案 2；但是通过职责分离——修复逻辑存在于微服务 A 和 B 之外。

Answer 2

您的解决方案看起来不错，但有些事情需要澄清：

在 DDD 中，聚合是一致性边界。聚合始终处于一致状态，无论它收到什么命令以及该命令是否成功。但这并不意味着从业务角度来看，整个系统处于允许的永久状态。有时整个系统处于不允许的状态。这没关系，只要最终它会在允许的状态下转换。 Saga/Process managers 来了。这正是它们的作用：使系统处于有效状态。它们可以部署为单独的微服务。

我在 CQRS 项目中使用的另一种类型的组件/模式是最终一致的命令验证器。他们使用私有读取模型在命令到达聚合之前验证命令（如果它不是有效，则拒绝它）。这些组件最大限度地减少了系统进入无效状态时的情况，并补充了 Sagas。它们应该部署在包含聚合的微服务内部，作为域层（聚合）之上的一层。

现在，回到地球。您的解决方案是聚合、Sagas 和最终一致的命令验证的组合。

解决方案 1

• 微服务 A 仅允许将 A 链接到 B，前提是它先前已收到“B 创建”事件且未收到“B 已删除”事件。
• 微服务 A 侦听“B 已删除”事件，并在收到此类事件后，将 A 与 B 取消链接。

在此架构中，微服务 A 包含 Aggregate A 和 Command validator，微服务 B 包含 Aggregate B 和 Saga。重要的是要了解验证器不会阻止系统的无效状态，而只会降低概率。

解决方案 2：

• 微服务 A 始终允许将 A 链接到 B。
• 微服务 B 侦听“A 链接到 B”事件，并在收到此类事件后验证 B 是否存在。如果没有，它 发出“拒绝 B 的链接”事件。
• 微服务 A 侦听“B 已删除”和“链接到 B 被拒绝”事件，并在收到此类事件后，将 A 与 B 取消链接。

在这个架构中，微服务 A 包含 Aggregate A 和一个 Saga，Microservice B 包含 Aggregate B 和一个 Saga。如果 B 上的 Saga 将验证 B 的存在并向 A 发送 Unlink B from A 命令而不是产生事件，则可以简化此解决方案。

无论如何，为了应用SRP，您可以将 Sagas 提取到他们自己的微服务中。在这种情况下，您将拥有每个聚合和每个 Saga 的微服务。

Answer 3

我将从与@ConstantinGalbenu 相同的前提开始，但随后提出不同的主张；）

最终一致性意味着整个系统最终将 收敛到一致的状态。

如果您添加到那个“无论接收消息的顺序如何”，您就会得到一个非常有力的声明，您的系统在没有帮助的情况下自然会趋向于最终的连贯状态外部流程管理器/传奇。

如果您从接收者的角度使最大数量的操作可交换，例如link A to B 是在 create A 之前还是之后到达都没有关系（它们都导致相同的结果状态），你几乎就在那里。这基本上是解决方案 2 的第一个要点，概括为最多事件，但不是第二个要点。

• 微服务 B 侦听“A 链接到 B”事件，并在收到 这样的事件，验证 B 存在。如果没有，它会发出一个“链接 对 B 拒绝”事件。

您无需在名义情况下执行此操作。在您知道 A 没有收到 B deleted 消息的情况下，您会这样做。但是，它不应该成为您正常业务流程的一部分，这是消息平台级别的交付失败管理。我不会通过原始数据来源的微服务对所有内容进行这种系统的双重检查，因为事情变得太复杂了。看起来好像您正试图将一些即时一致性恢复到最终一致的设置中。

该解决方案可能并不总是可行，但至少从不发出事件以响应其他事件的被动读取模型的角度来看，我想不出您无法管理的情况以可交换的方式处理所有事件。