1

我刚刚下载了 joliver eventstore，并希望Windows Service Bus 1.0为一个跨多个有界上下文进程分离的应用程序连接一条服务总线。

如果有界上下文已离线，而其他有界上下文中的事件已创建（或者甚至可能是已部署的新上下文），我可以看到以下事件序列。

  1. 例如 ContextA、ContextB 和 ContextC，它们都使用服务总线 1.0 连接，并且每个上下文都有自己的事件存储，它们都共享相同的总线消息传递底板。
  2. ContextC 离线。
  3. 当 ContextC 备份时，需要通知其他有界上下文需要重新发送到刚刚恢复在线的上下文的事件。这些事件从每个事件存储中重放。

我的问题是：

  1. 上述场景适用于任何事件溯源库，那么在此之上是否有任何基础设施代码我可以使用，还是我必须自己编写？
  2. 使用 Windows 服务总线 1.0，我如何将事件存储中的序列号与服务总线上的序列号结合起来？
  3. 以安全方式检测和处理已接收事件的最佳实践是什么（防止消息处理程序失败）？
4

1 回答 1

2

上述场景适用于任何事件溯源库，那么在此之上是否有任何基础设施代码我可以使用，还是我必须自己编写？

与事件相关的投影机制的概念当然很常见。不幸的是，根据您的堆栈、性能要求和规模以及许多其他因素，有很多方法可以处理如何做到这一点。

因此，我不知道这种性质的商品化设施。

GetEventStore 商店有一个集成的 Projection 工具，它看起来非常强大，并且需要在桌面上构建所有这些。在它存在之前，我认为人们甚至不应该考虑超越 JOES 的 SRPness。

除了提到 Azure 之外，您还没有对您的实际堆栈说太多。

使用 Windows 服务总线，我如何将我的事件存储中的序列号与服务总线上的序列号结合起来？

您可以使用流 id + 提交序列号MessageId（并使用它来确保总线删除重复项）。您可能还会在消息元数据中包含属性。

以安全方式检测和处理已接收事件的最佳实践是什么（防止消息处理程序失败）？

如果您在 Azure 上并考虑使用 ServiceBus，则可以使用主题来确保至少一次交付（并且您将使用会话工具）。去看两个小时的 ClemensV 深度潜水订阅视频和其他几集，否则你会花同样多的时间犯错误）

为了减少广播流量，如果 ContextC 请求从 ContextA 和 ContextB 重播，有没有办法让这些重播消息只发送到 ContextC？还是我不应该担心这个？

亩。您开始询问这些东西是否是一个好主意，但现在似乎已经假设这是要走的路。

首先，这种基础设施是一个需要彻底改造的巨大轮子。您是否考虑过简单地为每个 BC 设置一个主题并让任何需要听的人听？

这里的关键是你需要牢记这样一个事实，即仅仅因为你可以想到 BC 需要消耗彼此事件的情况，这个无处不在的中央魔法总线将在任何地方提供一切。

编辑：回答您编辑的问题版本 2+

使用 Windows 服务总线 1.0，我如何将事件存储中的序列号与服务总线上的序列号结合起来？

您的事件存储没有序列号。每个聚合都有一个提交序列号。您通常会使用会话主题和订阅。然后，您需要选择是要全局排序（使用单个会话 ID）还是按聚合排序（使用流 ID 作为会话 ID）。

一旦事件发生在一个主题上，它们就会有一个MessageSequenceNumber，并且订阅（当会话时）按顺序交付（实际上是订阅者接收它们）它们。

以安全方式检测和处理已接收事件的最佳实践是什么（防止消息处理程序失败）？

这是内置在服务总线（或任何排队机制）中的。在成功处理之前，您不会将消息标记为已完成。任何失败都会导致放弃（将其放回队列以进行重新处理）。

订户休息、断开连接或工作备份自然由主题处理。

于 2013-03-16T21:12:14.633 回答