CQRS + 微服务处理事件回滚

Question

我们正在使用微服务、cqrs、使用 nodejs cqrs-domain 的事件存储，一切都像魅力一样工作，典型的流程如下：

1. 休息->2。服务->3。命令验证-> 4。命令-> 5。聚合-> 6。事件-> 7。事件存储（事务数据）-> 8。返回带有聚合 ID 的聚合-> 9. 存储在微服务本地数据库中（本质上是读取数据库）-> 10. 将事件发布到队列

上述流程的问题在于，由于事务数据保存，即事件存储的持久性和微服务读取数据的存储发生在不同的事务上下文中，如果在步骤 9 出现任何故障，我应该如何处理事件已经传播到事件存储和已经更新的聚合？

任何建议都将受到高度赞赏。

Answer 1

上述流程的问题在于，由于事务数据保存，即事件存储的持久性和微服务读取数据的存储发生在不同的事务上下文中，如果在步骤 9 出现任何故障，我应该如何处理事件已经传播到事件存储和已经更新的聚合？

您稍后重试。

“记录簿”是事件存储。下游视图（“已发布事件”，读取模型）来自记录簿。它们通常在时间上落后于记录 (eventual consistency)，并且通常不会相互同步。

因此，您可能在某个时间点将 105 个事件写入记录簿，但只有 100 个事件发布到队列中，并且您的服务数据库中的一个表示仅由 98 个构成。

更新视图通常以两种方式之一完成。当然，您可以从一个全新的表示开始，并将所有事件作为每次更新的一部分重播到其中。或者，您可以在视图的元数据中跟踪您已经获得的事件历史记录，并使用该信息来确定下一次读取事件历史记录的位置。

Answer 2

在您的事件存储中，您可以跟踪读取端复制是否成功。 一旦第 9 步成功，您就可以将事件标记为“已复制”。

这样，您可以引入一个组件来监视未复制的事件并触发第 9 步。您还可以跟踪复制是否多次失败。

更新读取端（第 9 步）并将事件标记为已复制应该始终如一地发生。您可以在此处使用 saga 模式。

Answer 3

我想我现在已经更好地理解了它。 仍然会创建聚合，答案是任何类型的一致性的所有验证都应该在构建聚合之前发生，如果发生超出代码范围的故障，则在更新读取侧数据库时存在故障需要处理的微服务。 因此，在理想情况下，将创建聚合，但相关的事件将保持未调度，除非所有读取依赖项都已更新，否则它保持未调度并且可以单独处理。 Event Store 仍将拥有所有事件，并且以这种方式保持最终一致性。