7

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

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

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

可能的场景：

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

  2. 作为 web api 本身的一部分托管。 例如，如果我使用EventStore进行事件存储和事件订阅处理，是否会为每个单个事件触发多个处理程序（每个 Web 场进程中的一个），从而在处理程序尝试读/写时引起争用到他们的阅读商店？或者我们是否保证对于给定的聚合实例，它的所有事件都将按事件版本顺序一次处理一个？

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

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

编辑：

澄清一下，我说的是将事件数据提取到非规范化表中的过程，而不是读取这些表以获取 CQRS 中的“Q”。

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

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

事件总线

事件总线/队列用于在事件保存后发布消息，通常由存储库实现。相关方（订阅者），例如读取模型或 sagas/流程管理器，“以某种方式”使用总线/队列以幂等方式处理它。

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

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

订阅/订阅

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

如有必要，这对于重新创建读取模型非常有用。但是，按照通常的发布/订阅模式，似乎每个下游依赖项只应使用一个订阅者进程。如果我们为同一个事件流注册多个订阅者，例如在每个 web 农场节点中注册一个，他们都将尝试处理和更新相同的相应读取模型。

4

2 回答 2

7

在我们的项目中，我们使用基于订阅的预测。原因如下：

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

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

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

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

于 2016-11-26T16:38:08.603 回答
0

特别是对于 EventStore，他们现在有竞争的消费者，这是基于服务器的订阅，许多客户端可以订阅订阅组，但只有一个客户端获取消息。

听起来这就是你所追求的，农场中的每个节点都可以订阅订阅组，接收消息的节点进行投影

于 2016-11-21T05:59:53.093 回答