4

我们目前正在建立一个基于 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 是如何处理队列的？当消费者长时间（例如几天）无法联系到时会发生什么？

4

1 回答 1

2

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

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

[Udi] 给定的发布者可以在多个服务器上进行横向扩展，NServiceBus 将为您处理 - 无需订阅每台机器。

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

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

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

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

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

希望这可以帮助

于 2013-06-25T19:16:26.290 回答