有人可以解释一下消息代理的用途吗？
在我的工作中，很难在五分钟内没有人赞扬 MQ 系列或 MSMQ 等的优点，而且我总是想知道，在流行语的光芒过去之后，有哪些实际的示例现实世界中这些奇妙的设备。
我正在寻找的东西可能会激发我找到其中一个的用途，或者给我某种可以用来评估消息总线/消息代理/消息队列的指标——地狱，甚至是可以解释的东西上述消息*之间有什么区别。
In my line of work it's hard to go five minutes without someone extolling the virtues of MQ Series or MSMQ or the like, and I always wonder, after the sparkle of buzzwords has passed, what are some actual examples of these wonderful devices out in the real world.
What I'm looking for is something that might inspire me to find a use for one of these or give me some kind of metric I can use to evaluate a message bus/message broker/message queue -- hell, even something that will explain what the differences are between the aforementioned message* things.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
MQ 系列或 MSMQ 等消息队列解决方案广泛用于集成分布式企业应用程序，尤其是在不同平台上运行的应用程序。 如果做得好（使用持久队列、异步设计而不是“基于 MQ 的 RPC”并关注操作需求），与 RPC 或样板 Web 服务等同步请求/回复集成相比，这将为您提供高可用性（其可用性是各自可用性的乘积：同步集成 10 个可用性为 99% 的系统，您的综合可用性不会超过 90%，如果只有一个薄弱环节，情况会更糟）。 请注意，这要求消息队列本身具有高可用性：我们使用大型机来实现此目的（猜猜我们正在使用哪种产品！）。
消息（或集成）代理和“总线”是一个更复杂的问题。 添加
我按照难度（和潜在奖励）的递增顺序列出了这些功能。 你获得的越高，你的组织（包括业务方面）需要越成熟才能获得优势。
Message queuing solutions like MQ Series or MSMQ are used extensively for integrating distributed enterprise applications, especially running on different platforms. Done right (with persistent queues, asynchronous design rather than 'RPC over MQ' and attention to operational requirements), this gives you high availability compared to synchronous request/reply integrations such as RPC or boilerplate web services (whose availability is the product of the respective availabilities: integrating ten systems with 99 % availability synchronously gives you a combined availability of no more than 90 % -- or worse if there's just one weak link). Mind you, this requires the message queues to have high availability in themselves: we use our mainframe for that purpose (take a guess at which product we're using!).
Message (or integration) brokers and 'buses' are a more complex kettle of fish. They can add
I've listed these functionalities in roughly increasing order of difficulty (and potential reward). The higher you get, the more mature your organization (including the business side) needs to be in order to gain the advantages.
在不深入讨论特定产品的细节的情况下，我可以向您介绍使用典型消息队列系统的一些好处。
它们通常是模拟发布者/订阅者模式的良好基础设施。 想象一个大型事件系统，您不仅限于一个可执行文件，甚至一台机器。 您将信息放入这些队列中，以便任何正在侦听该数据的应用程序都可以获取该数据。
大多数消息队列系统都允许持久队列。 考虑一个典型的事件系统。 如果侦听器在事件发生时断开连接或无响应，则会错过该事件。 对于持久消息队列，消息将保留在队列中，直到侦听器重新连接。 这样不会丢失任何数据/事件。
我不了解您列出的产品，但我知道使用 JMS，当消息从队列中弹出时，您可以对线程进行细粒度控制。 理论上，每个队列可以有一个线程，在该线程中对拉出的消息执行操作。 或者，您可以从多个队列中提取消息并对它们执行操作，所有这些都在共享线程中进行。
Without getting into specifics about particular products, I can give you some of the benefits to using a typical message queuing system.
They are typically good infrastructure for simulating the publisher/subscriber pattern. Think of a big event system where you are not limited to one executable, or even one machine. You put information into these queues, such that the data can be picked up by any application who is listening for it.
Most message queuing systems allow for persistent queues. Think of a typical event system. If the listener is disconnected or otherwise unresponsive at the time of the event, then the event is missed. With a persistent message queue, the message will remain in queue until the listener is reconnected. No data/events are lost in this way.
I don't know about the products you listed, but I know with JMS you can have fine grained control over threading as messages are popped from the queue. In theory, you could have a thread per queue, performing actions in that thread, on the messages as they are pulled off. Alternatively, you have the ability to pull messages from multiple queues and perform actions on them, all within a shared thread.
虽然我对 MQ 系列有过非常痛苦的经历，部分原因是它是由合作公司推给我们（微软商店）的，但 MQ 系列（或任何消息系统）的使用是该应用程序不可或缺的一部分。
本质上，我们正在构建一个处理缺货订单供应链履行的流程。 如果我们的合作伙伴（分销商）没有客户想要的商品，他们会向 B2B 网站发送一条消息，该消息将针对能够履行订单的潜在公司。
我们构建了两种不同风格的集成。 第一种是 ftp 方法，其中固定宽度的文件定期来回发送，并且我们添加了各种规则来帮助确保我们不会错过任何数据。
第二种是使用 MQ 系列，其中使用有保证的传递将消息放入队列中。 然后我们将弹出队列并处理消息。 排队系统在这里带来了很大的好处，因为它为我们提供了一种可靠的方式来传输关键消息，从而导致真实的资金被转移。
另一方面，对于相同的 MQ 系列，我们必须实现同步查询来获取信息。 我们希望它是同步的，因为我们通过网络访问它的用户会等待获取信息。 在 MQ 系列上执行此操作是一个非常有趣且痛苦的挑战。 这里使用 MQ 的唯一原因是因为它是现有的通信线路并且查询功能已经存在。
第二个示例是使用 MSMQ，该站点从注入客户端应用程序的 dialhome 代码中收集信息。 dialhome 代码将收集功能使用统计信息，如 Microsoft 的 SQM 程序。 当消息进入 Web 服务时，我们会将它们放入队列中，然后我们可以让任意数量的应用程序服务器弹出消息并将它们推送到数据库以滚动到仓库中。
这里的 MSMQ 确保我们可以通过快速将消息放入队列来处理突发消息。 这有助于系统的可扩展性和可靠性。
While I had a very bitter experience with MQ Series partially due to the fact that it was pushed on to us (a Microsoft shop) by the partnering company, the use of MQ Series (Or any Messaging system) was an integral part to the application.
Essentially we were building a process that handled supply chain fullfilment for backorder items. If our partner a distributor didn't have the items their customers wanted, they would send a message into a B2B site, that would target potential companies that could fulfil the order.
We had built two different flavors of integration. The first was an ftp approach where fixed width files were sent back and forth at regular intervals, and we had added all sorts of rules to help ensure we didn't miss any data.
The second was using MQ Series where the messages were placed into a queue using guarenteed delivery. Then we would pop the queue and process the messages. The queing system was great benefit here as it allowed us a reliable way to transmit critical messages that resulted in real money being moved around.
On the flip side with the same MQ Series we had to implement a synchronous query to get information. We wanted it to be synchronous because our users accessing this via the web would wait to get the information. Doing this over MQ Series was a very interesting and painful challenge. The only reason MQ was used here was because it was an existing line of communication and the query functionality already existed.
A second example and this time was using MSMQ was a site that collected information from dialhome code injected into client applications. The dialhome code would collect feature usage statistics like Microsoft's SQM program. When the messages came in to the web service we would drop them on a queue, Then we could have any number of application servers popping the messages and pushing them to the database to be rolled into the warehouse.
MSMQ here ensured we could handle bursts of messages by quickly placing them on the queue. This help the scalability and reliability of the system.
消息队列对于实现负载平衡很有用。 例如，服务器接收“作业”消息（订单、状态消息...）并将它们分发给所有侦听客户端。
消息队列保证消息将准确地传递到一个客户端。
如果客户端在不同的计算机上运行，则总负载将被分配，并且在必要时很容易将另一个客户端扔给消息负载，客户端只需连接到队列并接收（部分）消息。
A message queue is useful to implement load balancing. For example, the server receives "job" messages (orders, status messages ...) and distributes them to all listening clients.
The message queue guarantees that a message will be delivered to exactly one client.
If the clients run on different computers, the total load will be distributed and it will be easy to throw another client to the message load when neccessary, the client just has to connect to the queue and will receive (some of) the messages.
一个好的排队系统可以更轻松地在多个线程、处理器、机器（甚至组织）上进行分布式计算。
不久前（10 年前），我使用消息发送比喻为交易商间经纪商实施了前台期权定价系统。 我们用 C++、VB6 和 Excel/VBA 实现服务（甚至使用 Excel 求解器！！），将数据存储为平面文件和 SQL，用 Excel 和 VB6 编写最终用户应用程序，并具有复杂的数据模型（市场数据、产量）曲线和体积曲面）。 异步消息传递（具有持久/可靠的消息和发布/订阅）使整个事情非常有效且可扩展 - 我们能够将东京和纽约办事处添加到伦敦基础设施中，甚至无需访问远程站点 - 只需一个沼泽标准安装。
我是他们的忠实粉丝，但我对他们在过去 10 年左右的时间里没有取得如此大的进步感到惊讶。
A good queuing system makes it easier to do distributed computing over multiple threads, processors, machines, (& even organizations).
A while back (10 years) I used a message sending metaphor to implement a front-office options pricing system for an interdealer broker. We had services implemented in C++, VB6 and Excel/VBA (even using the Excel solver!!), data storage as flat files and sql, end-user applications writen in Excel and VB6, with a complex data model (market data, yield curves and vol surfaces). Asynchronous messaging (with persistent / reliable messages and pub / sub) made the whole thing work very effectively and scalably - we were able to add Tokyo and NY offices to the London infrastructure without even visiting the remote site - just a bog standard install.
I'm a big fan though I am surprised at how far they haven't come in the last 10 years or so.
来自真实项目的一个非常“接近需求”的示例。 谁跑了好几年。 在ActiveMQ上
1）航运市场的交易中心。
航运公司有系统可以实时知道他们可以运送多少个包裹。
每个系统都是不同的（例如：语言、设计等）
我们为每个公司“非常特殊的 IT 系统到 ActiveMQ”编写了一个适配器”
每个适配器都有一个简单的工作要做：何时公司有可用空间以及以什么价格发布。 （“传输建议”）
我们编写了一个收集所有“交通建议”的客户端，并很好地显示它们。
=> 哒哒。 你有一个跨平台/语言/流程系统，适合那些不想互相交谈的公司
=> Ta-da 2：如果一家新公司想进入你的贸易系统，他们只需要编写适配器即可。
One very "close to to requirement" example from real project. Who run from several years. On ActiveMQ
1) Trade center for shipping market.
Shipping company have system who knows how many packets they can ship in real time.
Every system is different (eg: language, design, etc)
We wrote an adapter for each company "very special IT system to ActiveMQ"
Each adapter has a simple job to do: post when the company has free space, and at what price. (a "transport proposition")
We wrote a client who gather all "transport proposition", and display them nicely.
=> Ta-da. you have a cross platform/language/process system, for company who don't want to talk to each other
=> Ta-da 2 : If a new company wants to come in your trade system, they only have to write the adapter.