Windows 服务总线点对点通信以减少广播答案

【问题标题】：Windows Service Bus Point-to-Point Communications to Reduce BroadcastsWindows 服务总线点对点通信以减少广播
【发布时间】：2013-03-18 04:37:51
【问题描述】：

我使用Windows Service Bus 1.0在不同进程之间进行通信，每个上下文事件流作为一个主题存在于总线上。

使用服务总线在有界上下文之间链接事件我需要一种方法来同步事件（或者换句话说，请求重播过去的事件）当有界上下文重新联机但想要限制返回的潜在消息泛滥时只去请求它的端点，至少如果这是可以通过使用现有服务总线功能轻松完成的事情。

所以假设一个假想的 ContextC 发送一条消息来请求来自 ContextA 和 ContextB 的所有先前事件，有没有办法让这些重播消息只发送到 ContextC？

将上下文映射为主题所有者（或者换句话说，将单个总线订阅者映射到总线主题）以促进上述单播重播的最佳方式是什么？

【问题讨论】：

您是否正在尝试实现一种可以在本地或 Windows Azure 中同等部署的解决方案？
对我来说，术语都是错误的，因为您的其余问题都假设事件源 CQRS 架构。上下文不应该互相“发送”消息，而是可以互相收听。你能谈谈你更高层次的需求吗？为什么下游消费者需要担心所有这些东西？您这样做是为了促进事件的重播，以便在依赖上下文中的读取模型中“清除并重建”状态吗？
Ruben 感谢您一直以来的帮助。事件的发送和重放仅适用于恢复已上线并希望同步先前事件的有界上下文 - 我同意您的 cmets，因为这与我们通常只听的正常操作中应该发生的事情相同
当您说“上线”时，您是在谈论创建一个全新的上下文，该上下文需要从其宇宙的黎明开始从合作伙伴上下文中获取事件源？因为如果您谈论的是典型的上线感觉，即处理 10 秒到 10 天的中断，那真的只是正常的生活。如果您使用任何适当的排队机制，这就是全部理由

【解决方案1】：

在我的世界里，我将这些东西保持松散耦合 - 每个上下文都将东西放在一个主题上，任何需要东西的人都会订阅。

每个 SB 订阅都可以使用基于属性的服务总线过滤工具（例如，您可以通过在消息上添加属性来标记事件，然后在订阅上设置过滤条件，这意味着只有列入白名单的事件类别才会应用于每个消费者)。

再加上您已经按主题进行了分类。

然后订阅和主题允许您处理事件而不会丢失任何事件或让发布者担心或追逐订阅者。

您还在其他问题中提到您将其与事件存储相关联 - 在这种情况下，您的消息可能需要按顺序使用。如果是这种情况，您需要在消息中添加会话 ID。

我可以推测您为什么想要这个订阅者驱动的重新投递，但现在不想要。在任何人回答如何使用服务总线最好地实现这一点之前，您需要先进一步解释/验证该概念和要求（通过提出解释您的更高级别目标的问题）。

【讨论】：