logo标签列表

消息总线/命令调度模式的混淆

design-patternsevent-handlingdistributed-systemmessage-bus
26

最近我一直在阅读有关分布式消息传递及其相关模式的内容。我使用了像NServiceBus这样的工具支持其中的一些模式。

许多这些模式都可以在互联网上找到描述。最近我阅读到的一些模式包括：

如果使用 NServiceBus 等工具，可以在不太考虑基础设施问题的情况下完成很多工作，但当我尝试实现一个基本的消息总线和命令处理程序时，一些问题就出现了。实际上，当涉及到这些模式时，我看不到它们之间有很多区别。

我不会粘贴代码，因为它太长了，但我找到了两篇博客文章，可以比较好地描述我想谈论的实现思路。

这个思路很简单，消息总线跟踪订阅者，并将消息分发给感兴趣的不同订阅者。

它与消息总线非常相似。命令总线调用给定命令类型的命令处理程序。

因此，在两种情况下都有相似之处。

使用一种模式而不是另一种模式的真正区别和好处是什么（我不是在谈论支持工具）？我错过了什么?

第二个问题是。没有支持工具，消息总线是否有价值?我看不到自己能够为所有租户实现支持。

抱歉问题冗长且含混不清，但请随时要求更多详细信息。

2个回答
46

哇，想要给出比你链接的MSDN更详尽或更可靠的答案是很困难的，所以我们选择更简洁。

消息总线关注的是通信。它甚至不需要关心通信是否被传递为命令。它也不关心有效载荷是什么。它是“类型不可知”的。消息总线的主要关注点只是跟踪谁应该得到每个通信（发布/订阅）。这种模型的好处是它将支持未来扩展，而您还没有规格。您可能会在路上添加新的消息类型，这个模型将很乐意交付它。消息总线更有可能在应用程序外分布，甚至可能在您的机器之外分布(例如，在10个服务器的集群之间分布)。

命令处理程序模型关注的是将操作与命令执行分离开。传统上（至少在我使用的语言中），命令与UI控件及其事件和UI线程紧密相关联。在这种旧模型中，定制或扩展应用程序中可用的命令范围也很难（例如使用扩展DLL）。命令处理程序模型将这些UI和命令执行的问题分开。现在，您可以轻松地添加更多的命令处理程序并执行无UI事件的命令（可进行单元测试）。这使代码更清洁、更模块化和易于测试。命令处理程序更有可能成为您的应用程序内部的一部分。对命令集合的任何扩展都可能影响您的一个应用程序而不是多个应用程序。

一个消息/命令代理负责连接不兼容或设计不同的独立系统。这种情况适用于您希望一个应用程序与另一个应用程序进行接口交互，但对其中一个或两个应用程序的源代码没有控制权。因此，您可以创建一个代理，该代理从一侧接收信息，并在考虑到任何必要的转换以便这两个应用程序进行通信的情况下，在另一侧提供此信息。MSDN上的示例是电子商务网站，它可能需要与支付处理器、运输公司和会计系统通信。您可能无法更改任何这些应用程序的源代码（包括电子商务系统）。也许电子商务系统需要一个IExamplePaymentGateway接口，而您的支付提供程序需要一个IDifferentPaymentAPI接口。也许一个API是用XML实现的，而另一个API是用JSON实现的？无论差异如何，您的代理都负责使连接成为可能。
正如您所看到的，它们都涉及某种形式的通信。它们之间的界限可能很模糊，甚至您可能会使用几种组合模式来实现特定的用例。
虽然我从未使用过NServiceBus，但大多数此类库只是尝试将抽象/学术模型包装成更具体的语言实现。有时这可以节省您的时间，有时您可能会卡在未知开源贡献者的低质量实现中。您需要评估自己的用例以及首选开发语言中可用工具的适用性。
我认为你的解释值得接受。谢谢。 - Tomasz Jaskuλa
4

通常情况下，消息总线（或标准事件分发器）可以有许多订阅者，用于处理不同类型的消息/事件。

命令总线通常将命令分派到一个处理程序，类似于路由器将路由解析到控制器。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接