AMQP 是否适合作为机器内和机器间软件总线？
我正在尝试了解 AMQP。 它看起来非常适合应用程序之间的机器间（集群、LAN、WAN）通信，但我不确定它是否适合（在架构和当前实现方面）用作一台机器内的软件总线。
是否值得拿出当前的高性能消息传递框架来用 AMQP 替换它，或者这是否落入 与 RPC 相同的陷阱，模糊了本地和非本地通信之间的区别？
我还对使用 WAN 技术进行机器内通信的性能影响持谨慎态度，尽管这可能更多的是实现问题而不是体系结构。
战争故事将受到赞赏。
I'm trying to get my head around AMQP. It looks great for inter-machine (cluster, LAN, WAN) communication between applications but I'm not sure if it is suitable (in architectural, and current implementation terms) for use as a software bus within one machine.
Would it be worth pulling out a current high performance message passing framework to replace it with AMQP, or is this falling into the same trap as RPC by blurring the distinction between local and non-local communication?
I'm also wary of the performance impacts of using a WAN technology for intra-machine communications, although this may be more of an implementation concern than architecture.
War stories would be appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
AMQP 不是 RPC 框架。 它提供了构建块来对共享队列、RPC、pubsub 等进行建模，但它不强制要求任何特定的使用方式。
如果您想对应用程序进行分区（使其可分发）并将其与 AMQP 连接在一起，我认为这是正确的技术。 虽然可能有更快的替代方案，但可能没有一个像 AMQP 那样通用。
AMQP is not an RPC framework. It provides the building blocks to model things like shared queues, RPC, pubsub etc. but it does not mandate any specific way to use it.
If you want to partition your application (making it distributable on the way) and to wire it together with AMQP I think it's the right technology. There might be faster alternatives though but probably none as generic as AMQP.
AMQP 是一个规范，因此您实际上是在将苹果与橙子进行比较。 实际上，并没有那么多生产就绪的 AMQP 提供程序； 在撰写本文时，没有一个主要消息传递提供商或供应商支持 AMQP（例如 IBM、Tibco、Sonic、BEA、Oracle、SwiftMQ、MS、Apache ActiveMQ、Sun 的 openmq） - 因此所有可用的 AMQP 提供商都是相当新的。
因此，我建议将您感兴趣的任何 AMQP 提供程序与您的消息传递框架进行比较。 仅仅因为它的读取和读取方式而将运行良好的东西撕下来是没有意义的。 将字节写入套接字:)
AMQP is a specification so you'd be comparing apples with oranges really. There are not that many production ready AMQP providers out there really; none of the major messaging providers or vendors support AMQP at the time of writing (e.g. IBM, Tibco, Sonic, BEA, Oracle, SwiftMQ, MS, Apache ActiveMQ, openmq from Sun) - so all the available AMQP providers are pretty new.
So I'd recommend comparing whatever AMQP provider you are interested in with your message passing framework. There's no point ripping something out that is working fine just because of the way it reads & writes bytes to a socket :)
AMQP 标准正在变得成熟，并解决了困扰 JMS 等其他消息传递标准的一些棘手问题。 对于您的问题是否值得更换现有解决方案，我想说这取决于情况。 我会非常怀疑，因为想必该系统已经在生产中运行并且具有高性能。
如果您遇到以下问题：
您应该调查所需的工作并更准确地分析收益。 如果您已经很满意，那么更换消息传递框架不会带来投资回报。
The AMQP standard is getting mature and solves some of the hairy problems that have plagued other messaging standards like JMS. To your question whether it's worth replacing an existing solution, I'd say it depends. I would be very skeptical, since presumably the system is already working, in production and highly performant.
If you have problems like:
You should investigate the work required and analyze the benefits more precisely. If you're already happy, replacing a messaging framework isn't going to return on investment.
作为可靠、极其灵活（就消息传递模式而言）的基础，它可用于许多消息传递场景，包括机器内（即进程间）和网络间。 它可以从零一直扩展到巨大的高带宽、多网络系统。
我目前正在评估一个小型但相对复杂的近实时系统，我们不关心消息传输多远或谁/什么（在合理范围内；）正在消耗它们。 如果消费者坐在同一台机器上，那就这样吧。 我想尝试一下，看看你能做些什么。 如果您想构建一个原型系统，请使用 python 和 Pika 库。
As a basis for a reliable, extremely flexible (in terms of messaging patterns) it can be used for many messaging scenarios, both intra-machine (i.e inter-process) and inter-network. It can scale all the way from zero to huge, high-bandwidth, multi-network systems.
I am currently evaluating it for a small, but relatively complex near real-time system where we don't care how far the messages travel or who/what (within reason ;) is consuming them. If a consumer is sitting on the same machine so be it. I'd give it a go and see what you make of it. If you want to knock together a prototype system, use python and the Pika library.
AMQP 看起来更像是为 SOA 提供的可靠传输中间件，而不是内部使用的东西。
AMQP looks more like a reliable transport middleware offering for SOA than something to be used internally.
如果您主要对机器内场景中的性能感兴趣，那么问题不是关于 AMQP（这只是一个线路级协议），而是关于您应该尝试哪种实现。
通过消除网络引入的延迟，您可能会对各种实现的原始性能更加敏感。 因此，我会考虑用 C++ 实现的产品，例如 Qpid 或 Zeromq。
在一些不错的硬件（四核）上，Qpid 可以轻松达到 400 000 条消息/秒（消息为 1024 字节）。 Zeromq 可能会表现得更好，因为您可以拥有点对点通道，而 Qpid 使用代理架构（有一个步骤）。
If you're primarily interested in performances in an intra-machine scenario, the question is less about AMQP (which is only a wire level protocol) than about which implementation you should try.
By removing the latency introduced by the network, you'll probably be a lot more sensitive to the raw performances of the various implementation. Therefore, I would look at products implemented in C++ such as Qpid or Zeromq.
Qpid can easily reach 400 000 messages/second (with messages of 1024 bytes) on some decent hardware (quad core). Zeromq will probably perform a lot better because you can have peer to peer channels whereas Qpid is using a broker architecture (which had a step).