关于消息总线/命令调度程序模式的混淆
最近，我阅读了很多有关分布式消息传递和相关模式的内容。我使用了其中一些受工具支持的工具，例如 NServiceBus。
其中许多模式在互联网上都有描述。我最近读到的其中一些是：
- 消息代理：http://msdn.microsoft.com/en-us /library/ff648849.aspx
- 消息总线：http://msdn.microsoft.com/en-us/library/ms978583.aspx
- 中的消息传递模式面向服务架构：http://msdn.microsoft.com/en-us/library/aa480027.aspx
- Udi Dahan 的帖子关于差异：http://www.udidahan.com/2011/03/24/bus-and -broker-pubsub-differences/
如果使用 NService 总线这样的工具可以做很多事情而无需考虑太多基础设施问题，那么当我尝试实现基本的消息总线和命令处理程序。事实上，当谈到这些模式时，我看不出它们之间有什么区别。
我不会粘贴代码，因为它太长了，但我发现两篇博客文章很好地描述了我想谈论的实现想法。
想法很简单，消息总线跟踪订阅者并将消息分派给不同的订阅者如果他们有兴趣。
它与消息总线非常相似。命令总线调用给定命令类型的命令处理程序。
所以这两种情况都有相似之处。
使用一种模式与另一种模式相比的真正区别和好处是什么（我不是在谈论支持工具）。我缺少什么？
第二个问题是。 如果没有支持工具，消息总线还有价值吗？我不认为自己能够独自实现对所有租户的支持。
我很抱歉问了一个又长又令人困惑的问题，但请随时询问更多详细信息。
Recently I've been reading a lot about distributed messaging and associated patterns. I used some of them supported by the tools like for exemple NServiceBus.
Many of those patterns are described on internet. Some of them I recently read was :
- Message Broker : http://msdn.microsoft.com/en-us/library/ff648849.aspx
- Message Bus : http://msdn.microsoft.com/en-us/library/ms978583.aspx
- Messaging patterns in SOA : http://msdn.microsoft.com/en-us/library/aa480027.aspx
- Udi Dahan's post about differences : http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences/
If using such tooling as NService bus alows to do a lot without thinking to much about infrastructure problems, some questions have araised when I tried to implement a basic Message Bus and command handler. In fact when it comes to these patterns I can't see many differences between them.
I won't paste code because it's to long but I found two blog posts that quite describe the idea of implementation I would like to talk about.
The idea is simple, the message bus tracks the subscribers and dispatches the messages to different subscribers if they are interested in.
- Command Handler : http://weblogs.asp.net/shijuvarghese/archive/2011/10/18/cqrs-commands-command-handlers-and-command-dispatcher.aspx
It's quite similar to message bus. The command bus invokes the command handlers for a given command type.
So in both cases there are similarities.
What are the real differences and benefits using one pattern than another (I'm not talking about supporting tooling). What I'm missing ?
The second question is. Does the message bus is valuable without the supporting tooling ? I don't see myself to impelment the support for all tenents on my own.
I'm sorry for a long and confusing question but don't hesitate to ask for more details.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
哇哦，很难给出比您链接到的 MSDN 更彻底或更可信的答案，所以让我们更简洁一些。
消息总线与通信有关。它甚至不要求所传递的通信是否是命令。它也不关心有效负载是什么。它是“类型不可知的”。消息总线的主要关注点只是跟踪谁应该获得每条通信（发布/订阅）。该模型的一个好处是，它将支持您尚未具备规格的未来扩展。您可能会在以后添加新的消息类型，该模型将很乐意交付它。消息总线更有可能分布在应用程序外部，甚至可能分布在计算机外部（例如分布在 10 个服务器的集群之间）。
命令处理程序模型涉及将操作与命令的执行分开。传统上（至少在我使用的语言中）命令与 UI 控件及其事件和 UI 线程紧密相关。使用这种旧模型，也很难自定义或扩展应用程序中可用命令的范围（例如使用扩展 DLL）。命令处理程序模型将 UI 和命令执行的关注点分开。现在，您可以灵活地轻松添加更多命令处理程序并在没有 UI 事件的情况下执行命令（可进行单元测试）。这使得代码更加清晰、模块化和可测试。命令处理程序更有可能是应用程序内部的一部分。命令集合的任何扩展都可能会影响您的一个应用程序，而不是多个应用程序。
消息/命令代理涉及连接不兼容或不同设计的独立系统。在这种用例中，您希望一个应用程序与另一个应用程序交互，但没有一个或两个应用程序的源代码。因此，您创建一个代理，它从一侧接收信息，并在另一侧提供此信息，同时考虑这两个应用程序通信所需的任何转换。 MSDN 上的示例是一个电子商务网站，它可能需要与支付处理商、运输公司和会计系统进行通信。您可能无法更改任何这些应用程序（包括电子商务系统）的源代码。也许电子商务系统需要 IExamplePaymentGateway 接口，而您的支付提供商需要 IDifferentPaymentAPI 接口。也许一个 API 是用 XML 实现的，另一个 API 是用 JSON 实现的？无论有何差异，您的经纪人都有责任使连接成为可能。
正如您所看到的，它们都涉及以一种或另一种方式进行通信。它们之间的界限可能很模糊，您甚至可以使用其中几种模式的组合来实现您的特定用例。
虽然我从未使用过 NServiceBus，但大多数此类库只是尝试将抽象/学术模型包装成更具体的特定于语言的实现。有时这可以节省您的时间，有时您会因未知开源贡献者的糟糕实现而陷入困境。您需要评估自己的用例以及首选开发语言中可用工具的适用性。
Woah, it'll be tough to give an answer more thorough or more credible than the MSDN you linked to, so lets go for more concise.
A Message Bus is concerned with communication. It doesn't even require that the communication be delivered is a command or not. It also doesn't care what the payload is. It is "type agnostic". The primary concern of the message bus is simply to keep track of who should get each piece of communication (pub/sub). A benefit of this model is that it will support future expansion that you don't yet have the specs for. You might add in a new message type down the road and this model will be happy to deliver it. A message bus is more likely to be distributed outside your application and perhaps even outside your machine (say distributed between a cluster of 10 servers).
A command handler model is concerned with separating the actions from the execution of a command. Traditionally (at least in the languages I use) commands were very tightly associated with UI controls and their events and the UI thread. With this old model, it was also difficult to customize or extend the range of available commands in your application (say with an extension DLL). The command handler model separates those concerns of UI and command execution. You now have the flexibility to easily add more command handlers and to execute commands without a UI event (Unit test-able). This makes for cleaner, more modular and testable code. The command handler is more likely to be part of your application internally. Any extensions to your commands collection are likely intended to affect your one application and not multiple applications.
A Message/Command Broker is concerned with connecting incompatible or differently designed independent systems. This is the use case where you want one application to interface with another and don't have the source code to one or both applications. So you create a broker which receives information from one side and provides this information on the other side taking into account any transformations necessary for these two apps to communicate. The example on MSDN is an ecommerce website which might need to talk to a payment processor, a shipping company, and an accounting system. You may not have the ability to change the source code for any of these apps (including the ecommerce system). Maybe the ecommerce system requires an IExamplePaymentGateway interface and your payment provider requires a IDifferentPaymentAPI interface. Maybe one API is implemented in XML and the other in JSON? Whatever the differences, your broker is responsible to make the connection possible.
As you can see they all involve communicating in one way or another. The lines between them can be blurry and you may even use a combination of several of these patterns to achieve your particular use case.
While I've never used NServiceBus, most of these type of libraries simply try to wrap up the abstract/academic models into more concrete language specific implementations. Sometimes this saves you time, sometimes you get stuck with a poor implementation from an unknown open source contributor. You'll need to evaluate your own use case and the suitability of the tools available in your preferred development language.
通常，消息总线（或标准事件调度程序）可以有许多不同类型的消息/事件的订阅者。
命令总线通常将命令分派给 1 个处理程序，类似于路由器解析控制器的路由。
Generally, a message bus (or a standard event dispatcher) can have many subscribers for different types of messages / events.
A command bus usually dispatches commands to exactly 1 handler, similar to a router resolving routes to controllers.