cqrs - 应如何托管事件溯源事件处理程序来构建读取模型？

Question

有各种示例应用程序和框架实现 CQRS + 事件溯源架构，并且大多数描述了使用事件处理程序从存储在事件存储中的域事件创建非规范化 View 。

托管此架构的一个示例是作为 Web API，它接受写入端的命令并支持查询非规范化 View 。此 Web API 可能会扩展到负载平衡场中的许多计算机。

我的问题是读取模型事件处理程序托管在哪里？

可能的情况:

1. 托管在单独主机上的单个 Windows 服务中。如果是这样，这不会造成单点故障吗？这可能也会使部署变得复杂，但它确实保证了单线程执行。缺点是读取模型可能会出现延迟增加。

2. 作为 Web API 本身的一部分托管。如果我使用EventStore例如，对于事件存储和事件订阅处理，是否会为每个事件触发多个处理程序(每个 Web 场进程中都有一个)，从而在处理程序尝试读取/写入其读取存储时导致处理程序发生争用？或者我们是否保证对于给定的聚合实例，其所有事件都将按照事件版本顺序一次处理一个？

我倾向于方案 2，因为它简化了部署，并且还支持需要监听事件的流程管理器。情况相同，因为只有一个事件处理程序应该处理单个事件。

EventStore 可以处理这种情况吗？其他人如何在最终一致的架构中处理事件？

编辑:

为了澄清，我正在谈论将事件数据提取到非规范化表中的过程，而不是读取 CQRS 中“Q”的这些表。

我想我正在寻找的是我们“应该”如何实现和部署可以支持冗余和规模的读取模型/传奇等的事件处理的选项，当然假设事件处理是以幂等方式处理。

我读过两种可能的解决方案，用于处理在事件存储中保存为事件的数据，但我不明白应该使用哪一种。

事件总线

事件总线/队列用于在事件保存后发布消息(通常由存储库实现)。感兴趣的各方(订阅者)，例如读取模型或 sagas/流程管理器，“以某种方式”使用总线/队列以幂等方式对其进行处理。

如果队列是发布/订阅的，这意味着每个下游依赖项(读取模型、sagas 等)只能支持一个进程来订阅队列。多个流程意味着每个流程都处理相同的事件，然后竞争在下游进行更改。幂等处理应注意一致性/并发问题。

如果队列是竞争消费者，我们至少有可能在每个网络场节点中托管订阅者以实现冗余。尽管这需要每个下游依赖项都有一个队列；一个用于 sagas/流程管理器，一个用于每个读取模型等，因此存储库必须发布到每个模型以实现最终的一致性。

订阅/提要

订阅/提要，感兴趣的各方(订阅者)按需读取事件流并从已知检查点获取事件以处理到读取模型中。

如果需要的话，这对于重新创建读取模型来说看起来很棒。然而，根据通常的发布/订阅模式，似乎每个下游依赖项只应使用一个订阅者进程。如果我们为同一事件流注册多个订阅者，例如每个网络场节点中都有一个订阅者，那么它们都将尝试处理和更新各自的相同读取模型。

Answer 1

在我们的项目中，我们使用基于订阅的预测。其原因有:

• 提交到写入端必须是事务性的，如果您使用两个基础设施(事件存储和消息总线)，则必须开始使用 DTC，否则您的事件将面临被保存到存储但无法发布到的风险总线，或相反，取决于您的实现。 DTC 和两阶段提交是令人讨厌的事情，你不想走这条路
• 无论如何，事件通常都会在消息总线中发布(我们也通过订阅来实现)，以便在不同的限界上下文之间进行事件驱动的通信。如果您使用消息订阅者来更新您的读取模型，当您决定重建读取模型时，您的其他订阅者也会收到这些消息，这将使系统进入无效状态。我想您在说每种已发布的消息类型只能有一个订阅者时已经考虑到了这一点。
• 消息总线使用者无法保证消息顺序，这可能会使您的读取模型陷入困惑。
• 消息使用者通常通过将消息发送回队列来处理重试，并且通常是在队列末尾进行重试。这意味着您的事件可能会变得严重无序。此外，通常在重试一定次数后，消息使用者会放弃有害消息并将其放入某个 DLQ。如果这是您的预测，这将意味着一个更新将被忽略，而其他更新将被处理。这意味着您的读取模型将处于不一致(无效)状态。

考虑到这些原因，我们有可以做任何事情的基于单线程订阅的投影。您可以使用自己的检查点进行不同类型的投影，使用追赶订阅来订阅事件存储。为了简单起见，我们将它们托管在与许多其他事物相同的进程中，但该进程仅在一台计算机上运行。如果我们想要扩展这个过程，我们将不得不取消订阅/预测。这很容易完成，因为除了读取模型 DTO 本身之外，这部分实际上不依赖于其他模块，无论如何它都可以作为程序集共享。

通过使用订阅，您始终可以投影已提交的事件。如果投影出现问题，写入端绝对是事实来源，并且仍然如此，您只需修复投影并再次运行即可。

我们有两个独立的 - 一个用于投影到读取模型，另一个用于将事件发布到消息总线。事实证明，这种结构非常有效。