events - 用于 CQRS 事件发布设置的 NServiceBus

Question

我们目前正在建立一个基于 CQRS 的项目。每个 Web 项目实例都运行 NEventStore，但是都共享相同的 EventStore 持久性(底层数据库)。

现在我们要发布存储的事件:不仅发布到我们的 ReadModel(每个 Web 项目实例一个)，而且发布到其他事件使用者(例如遗留应用程序，它们也需要以某种方式从我们的系统中获知事件，以及许多更多的)。

因此，我们有 x 个事件消费者(= 事件处理程序)和 y 个事件发布者，但只有一个“真实来源”的事件(底层 EventStore 数据库)。

Q1:现在是否有通过发布/订阅连接这些系统的最佳实践？

我们考虑通过 NServiceBus 从 EventStore 发布事件。所有消费者都应该订阅他们需要的事件类型——因此每个消费者还需要订阅可能不止一个发布者 - Q2 : 这甚至可能吗？我们了解到您不能在多个地点订阅同一事件，请参阅:David Boike “一旦您订阅了来自 QueueName@WebServer1 的 Message1，您将无法再订阅来自 QueueName@WebServer2 的 Message1。”

其他开放问题:
Q3:如何检测消费者是否已永远关闭(如果尚未成功从总线取消订阅)。 -> 队列已满？!如何将这与它只是失去网络连接的情况区分开来？

Q4:如果订阅服务和 EventStore 之间的连接不可靠和失败会发生什么？消费者在订阅服务上成功注册但 EventStore 不知道新订阅并且不传递消息......

Q5:一般而言:NServiceBus 如何处理队列？当消费者长时间(例如几天)无法联系到时会发生什么？

Answer 1

Q1:这有点取决于您订阅消息的方式。 NServiceBus 是建立在有业务服务(有界上下文)不能共享数据的基础上的。然而，在 CQRS 中，您有包含大量数据的胖事件，这些数据被发布以便订阅者可以将信息存储在他们的读取模型中。例如，在用户界面中使用此读取模型。通过普通 UI 或通过复合 UI(从多个业务服务收集信息)。所以这取决于你在寻找什么。

Q2:可以订阅多个事件。然而，事件只有一个逻辑发布者。因此事件“CustomerWasBilled”不能来自 ComponentA 和 ComponentB。但是，您可以订阅许多不同的事件，每个发布者当然可以有许多不同的订阅者。

[Udi] 一个给定的发布者可以跨多台服务器扩展，NServiceBus 会为你处理——无需订阅每台机器。

Q3:我认为这是纯粹的管理。如果它应该保持在线并接收消息，队列将填满。如果它应该永久关闭/离线并且不处理消息，那么在组件被删除后你会很快知道。但我强烈建议记录哪些订阅者和发布者相互连接，以及如果更改消息或组件会发生什么。

[Udi] 如果是有序关闭，那么应该包括取消订阅。如果是崩溃 - ergo 临时，那么您可以使用标准监控 (WMI) 检测到它。为了保护您的队列不被填满，您可以使用 TimeToBeReceived 属性定义何时应该丢弃消息。

Q4:这是在 NServiceBus 中处理的。它将订阅存储在数据存储中，可以是 SQL Server、RavenDB 和 InMemory。但它也会将订阅保留在内存中，并定期检查是否添加了新订阅。 NServiceBus 应该不是问题。

Q5:MSMQ 本身在本质上是可靠的。当然，如果您的整个服务器崩溃并且所有消息都在炸毁的 HD 上，那就是一个问题。如果某个组件在较长时间内无法访问，则这取决于 SLA 是否会发生。您可以监视传入队列或错误队列中的消息计数。也不要忘记 DeadLetterQueue。但是 NServiceBus 还允许您监视处理消息所需的时间。

当组件在很长一段时间内(例如几天)无法访问时，业务应该决定做什么。如果重要的消息得到处理，请引入聚类等。

希望这可以帮助