NServiceBus 消息类型和思考过程答案

【问题标题】：NServiceBus message types and thought processNServiceBus 消息类型和思考过程
【发布时间】：2011-11-22 14:59:41
【问题描述】：

在我们的场景中，我正在考虑使用 pub sub 技术。但是我不知道哪个是更好的选择。

1 ########

我们的网络服务在外部调用时会发布一条消息，表示发生了什么事，ExternalPersonCreatedMessage！

此消息将包含一个字段，该字段表示将消息处理到的目标（允许多个）。

各种订阅者都会订阅。这些订阅者将通过检查目标字段来过滤消息以查看是否需要任何操作。

2 ########

我们的 Web 服务将解析传入呼叫并根据字段中提供的目的地发布特定类型的消息。即将创建许多 Destination[n]PersonCreatedMessage 消息。

订阅者将只订阅他们关心的特定消息。即不必过滤任何消息

问题

以上哪个是更好的选择，为什么？以及如何阻止自己制作 RequestMessages。从我读过/看到的内容来看，我应该尝试以 PersonCreated、PersonDeleted 的方式来构建它，即在 CreatePerson 或 DeletePerson 等请求中发生了某些事情并且没有 >

我的想法正确吗？我一直在寻找有关如何构建消息的指导，并确保我不会走错路，但没有找到关于该做什么和不该做什么的指导。任何人都可以帮助和指导吗？我想试着从一开始就纠正这个:)

【问题讨论】：

您能否详细介绍一下业务规则是什么？您可能不需要发布。根据我的经验，内容过滤不是一个好方法。
亚当。我觉得我在兜圈子，但following 有助于解释业务场景。作者非常友善（非常感谢）帮助我掌握了 NServiceBus。这个问题与上述博客上的评论混合在一起，是我仍然需要快速回答的巨大漏洞。我不知道这些问题/问题是否以任何方式表明 NServiceBus 是错误的工具。任何帮助表示赞赏。
您可以使用 PServiceBus(pservicebus.codeplex.com)，它允许您发布通知并让订阅者使用过滤器进行订阅，指定他们仅在包含特定字段时才希望接收消息，例如目的地。过滤将在 ESB 服务器级别而不是在订阅者级别完成，因此订阅者不需要检查消息是否符合他们的标准。使用这种方法可以让您不必担心发布两条或更多条不同的消息

【解决方案1】：

根据参考文章中的集成场景，在我看来，您可能需要一个 Saga 来完成接受消息 -> 操作消息 -> 发送确认的工作流程。在操作后立即发送确认的情况下，您可以使用 NSB 消息处理程序管道功能，该功能允许您以指定的顺序链接处理程序，例如...

First<FilterHandler>.Then<DoWorkHandler>().AndThen<SendConfirmationHandler>();

在内容过滤方面，尽管会产生一些传输开销，但您可以这样做，这意味着队列将不得不接受消息，并且进程将始终在每条消息上调用第一个处理程序（您可以将上述内容短路任何时候的管道）。可能您真正想要的是一个 Distributor/Worker 设置，其中所有 Worker 都是相同的，并且您可以处理一些负载。

如果您确实有具有完全不同逻辑的不同端点，那么我会让发布者进程（仅接受和发布消息）完成将入站消息转换为订阅者可能感兴趣的其他内容的工作。如果那时你发现给定的已发布消息只有 1 个订阅者，那么您根本不需要发布，您只需将 Bus.Send() 发送到正确的端点。

【讨论】：

谢谢亚当。然而，工作流程（事务周期）是接受 1 消息 > 各种端点可以对消息进行操作 > 在发回响应之前确认所有都已完成。我怎么知道所有消息何时处理完毕？我没有开始计数，而且超时是不可接受的，因为端点可能已关闭，并且仍然需要在将响应发送回第三方之前处理消息。
在这种情况下，您肯定需要一个 Saga 来跨多个端点维护状态。它应该是一个简单的，从收到消息开始，到所有端点都确认完成时结束。

【解决方案2】：

NServiceBus 处理 pub-sub 的方式更像是您的选择二。

在我看来，您应该停止考虑目的地。消息就是消息。它们不应包含任何固有的目的地信息。订阅机制定义了解决方案的寻址/路由要求。

【讨论】：

感谢您的回答。还要感谢您更详细地解释内部工作。在我看来，我必须考虑示例 2 中解释的目的地。在示例 2 中，由于使用了 pub/sub，我没有考虑与端点有关的目的地，但发布特定端点需要的特定类型的消息对目的地有足够的了解。这令人沮丧，因为我想确保按预期方式使用 NServiceBus。引发 Destination1Message 或 Destination2Message 类型的消息似乎是错误的。
[续] 在我看来，示例 1 是更通用的示例，因为路由/消息是目的地不知道的。订阅者中的处理会根据消息的内容执行或不执行任何操作。
我仍在寻找发布/订阅和消息类型示例。我似乎无法摆脱必须发布面向请求而不是面向“发生某事”的消息:'(