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

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。
• 微服务 A 侦听“B 已删除”事件，并在收到此类事件后，取消 A 与 B 的链接（对于 B 在收到链接到 B 事件的 A 之前删除的竞争条件）。

解决方案2：

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

编辑：解决方案 3，由纪尧姆提出：

• 如果微服务 A 之前没有收到“B 删除”事件，则它只允许将 A 链接到 B。
• 微服务 B 始终允许删除 B。
• 微服务 A 侦听“B 已删除”事件，并在收到此类事件后，取消 A 与 B 的链接。

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

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

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

任何意见，将不胜感激。

Answer 1

\n

如果微服务 A 之前收到过“B 创建”事件且没有“B 删除”事件，则仅允许将 A 链接到 B。

\n

\n

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

\n

乌迪·达汉，2010

\n

\n

时间上的微秒差异不应\xe2\x80\x99 对核心业务行为产生影响。

\n

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

\n

\n

我一点也不喜欢这种复杂性；听起来工作量很大，但商业价值却并不高。

\n

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

\n

稍后 添加自动修复。里纳特·阿卜杜林 (Rinat Abdullin)很好地描述了这一进展。

\n

自动化版本最终看起来类似于解决方案 2；但随着职责的分离，修复逻辑位于微服务 A 和 B 之外。

\n