下载本文的PDF版本 PDF

面向商品化企业中间件

AMQP 能否开启消息中间件的新纪元？深入了解基于标准的 AMQP 消息传递

John O'Hara，摩根大通

AMQP（高级消息队列协议）的诞生源于我在投资银行开发前台和后台处理系统中的经验和挫败感。在我看来，我们仿佛生活在集成的“土拨鼠日”——将系统连接在一起的相同问题会令人沮丧地频繁出现。每次都会就使用哪些产品进行相同的讨论，并且每次都会为了迁就所选中间件价格昂贵的事实而缩减某些系统的架构。

从 1996 年到 2003 年，我一直在等待针对这种显而易见的需求的解决方案以标准形式出现，从而实现商品化。但这未能实现，我厌倦了等待。

因此，AMQP 应运而生，并在 2006 年年中首次关键任务部署到生产环境。该项目在首次部署时就收回了成本，为 2,000 名用户提供服务，每天处理 3 亿条消息。

本文阐述了 AMQP 的动机、功能和资质，并将其作为基于标准的messaging基础设施的实用解决方案。

AMQP 是一种二进制线路协议和一套定义明确的行为，用于在使用存储转发、发布订阅和其他技术的系统之间传输应用程序消息。1 我使用术语应用程序消息来区分 AMQP 与即时消息或其他形式的最终用户消息传递。AMQP 解决的是消息丢失、未及时到达或处理不当可能会产生经济影响的场景。

该协议旨在可从不同的编程环境、操作系统和硬件设备中使用，并使在各种网络传输（包括 TCP、SCTP（流控制传输协议）和 InfiniBand）上实现高性能实现成为可能。

对标准的需求

华尔街的每家大型投资银行都曾在某个时候构建了自己的消息中间件。许多要么已经衰落，要么剥离出来成为商业专有解决方案。

他们为什么要构建自己的中间件？金融服务业对消息传递的需求最为苛刻，无论是在保证交付还是在发布订阅方面。需求通常超出当前可用软件的能力，而且银行不乏技术专长。因此，构建自己的中间件是一种可行的方法。

银行正在寻找高性能服务总线，以便挂载其系统架构。Web 服务不符合要求，因为它们在每个工作单元上的计算和带宽密集程度太高。

自动化交易的增长也点燃了对改进中间件的兴趣。据期权价格报告机构称，银行仍在突破市场数据事件的极限，源头每秒超过 500,000 个事件。处理如此大量的信息并在此基础上执行及时的业务交易具有挑战性。市场数据量加剧了交易处理量。

鉴于明显的需要，为什么许多内部努力没有持久？尽管银行拥有技术能力，但它们不是软件公司；消息中间件是复杂的软件，银行很难长期将智力和才能集中在该问题上。

在绝对有必要开展业务的情况下，银行已经设法合作制定开放技术标准；FIX（金融信息交换）协议、FAST（FIX 适配流媒体）、FpML（金融产品标记语言）和 SWIFT（环球银行金融电信协会）都是很好的例子。

2003 年，我开始寻求在公司外部标准化 MOM（面向消息的中间件）技术，以便我们可以在公司内部拾取并在公司之间使用它。

使其实现

这必须是一项行业倡议。即使是最大的主机组织，本土中间件也无法在主机组织内可用的小市场中蓬勃发展。

同样值得注意的是，诸如以太网、互联网协议、电子邮件和 Web 等普遍存在的网络标准具有一些共同特征。它们都是免版税且不受专利限制的，它们都是公开指定的，并且它们都免费附带了有用的早期实现。当以适合用途为前提时，自由和实用性的结合推动了它们的采用。

为了取得成功，AMQP 需要采用相同的特征

由于该项目由一家银行赞助，因此它也必须“自给自足”，正如他们所说的那样。这不是一个研究项目。非常幸运的是，需要刷新一些具有非常具体要求的大型系统。这为 AMQP 投资提供了切实的回报，因此我能够说服一位具有前瞻性的 CIO，AMQP 是正确的发展方向。

AMQP 工作组

当摩根大通和 iMatix 之间确定了 AMQP 的形状，并且规范的基础在最初实现的炙热中锻造出来时，是时候扩大合作伙伴关系并鼓励其他人将其才能带入规范并分享 AMQP 未来的所有权了。

强大的治理

在任何集体努力中，开放性和信任的核心是有效的治理。扩大团队需要一个新的合同框架和一个计划，以实现 AMQP 可以成为标准的目标。Red Hat 率先建立了标准的法律框架；它也理解管理开放知识产权的问题。这样做的关键部分是确保每个贡献者都有权这样做，并且从每个潜在的知识产权所有者到团队努力都有一个书面记录，并且即使在规范的草案修订中，分享的意图也很明确。结果是一份合同，该合同明确承诺工作组成员通过 AMQP 促进不受限制的开放中间件。

工作组成员已向任何想要实施 AMQP 的人授予了其专利组合必要部分的许可。您可以在规范本身中看到许可授予。这种程度的贡献表明了该小组对开放中间件的承诺。AMQP 工作组的网站是 http://www.amqp.org。

用户驱动

AMQP 工作组在技术标准工作中非常独特，因为它有用户的深度参与。摩根大通、瑞士信贷、TWIST 以及一定程度上的思科与其说是开发人员，不如说是最终用户。这种平衡导致了一群对解决问题感兴趣的人，而不是迎合技术议程或产品议程。

架构

从一开始，AMQP 的设计目标就是定义足够的 MOM 语义（见图 1），以满足大多数商业计算系统的需求，并以高效的方式进行，最终可以嵌入到网络基础设施中。它不仅仅适用于银行。

AMQP 涵盖了存储转发消息传递、发布订阅消息传递和文件传输领域。它结合了常用模式，以简化防火墙的遍历，同时保持安全性，并允许网络 QoS。为了简化采用和迁移，AMQP 还旨在涵盖 JMS（Java 消息服务）语义。JMS 是 Java 程序员非常流行的 API，不容忽视。然而，AMQP 更进一步，它包含工作组成员在过去几十年中发现对交付大型、稳健系统有用的 JMS 中没有的其他语义。有趣的是，AMQP 本身并没有指定开发人员使用的 API，尽管将来很可能会这样做。

JMS 中没有的示例功能是 AMQP 的强制交付模式，客户端可以使用 AMQP 从连接到 AMQP 代理队列的服务器池请求服务。AMQP 代理可以在订阅请求队列的服务之间进行负载均衡请求，并且提供服务的进程数量可以动态增长和缩小，而不会对客户端产生影响。但是，如果服务池缩小到零，则 AMQP 可以使用强制交付模式通知客户端，因为这可能是应用程序的操作错误。

AMQP 还为消息属性指定了一个小的线路级类型系统，使许多编程语言以及 MOM 服务器本身都可以高效地读取它们，以进行过滤和路由。因此，Python 客户端不仅可以读取在 Java 服务器中设置的标头，而且不同的供应商还可以无缝地在其实现之间中继消息。然而，类型系统也存在通常的问题，即对象类型无法在标头中传输；Cobol 程序如何处理 Smalltalk 对象？

最后，AMQP 在很大程度上借鉴了 IETF 开放标准的传统。它尽量不重新发明现有概念。早期版本的 AMQP 线路协议受到 SMTP、3 MIME、4 HTTP-NG、5 NFSv4、6 SCTP、7 BEEP、8 和 IETF 资深人士 Marshal Rose 9 的著作的影响。

主要功能

AMQP 分为两个主要领域：传输模型和排队模型。AMQP 的不同之处在于，它在其排队模型中彻底指定了其提供的服务的语义；由于应用程序与其中间件有着非常密切的关系，因此需要很好地定义这一点，否则就无法实现互操作性。在这方面，AMQP 语义比 JMS 语义定义得更严格。

如前所述，AMQP 的传输是一种使用网络字节顺序的二进制协议。我们希望通过设计使 AMQP 易于嵌入到网络元素的 ASIC（专用集成电路）中。借助 Wireshark 等免费工具，无需将 XML 用于只有专家才能看到的技术基础设施层。XML 已用于 BEEP 和 XMPP 等：在 BEEP 的情况下，它使协议复杂化；在 XMPP 的情况下，它仅限于在面向流的传输上携带。AMQP 的目标是高性能和灵活性，对硬件友好而不是对人类友好。然而，协议规范本身是用 XML 编写的，因此实现者可以代码生成其实现的大部分内容；这使供应商更容易支持该技术。

传输模型本身可以重用不同的底层传输。第一个是 TCP/IP，但通过采用 SCTP，我们可以获得更好的消息并行性（SCTP 消除了 TCP 施加的字节流队头阻塞问题）。还有计划映射到 UDP 以支持通过多播的 AMQP，并且计划绑定到 InfiniBand。InfiniBand 的性能引起了银行的极大兴趣，AMQP 将使其对开发人员非常容易访问。

然而，TCP/IP 有望成为大多数最终用户的默认选择，以获得最佳互操作性。随着这些选项的出现，AMQP 必须建立一套有用的功能默认集，所有实现都必须遵守，否则将遭受早期版本 NFS 等协议所困扰的最低公分母问题（许多服务器未实现文件锁定）。希望合规性测试套件能够解决此问题。

消息

AMQP 中的消息是独立的且持久的，并且它们的内容是不可变的和不透明的。消息的内容本质上是无限大小的；4GB 消息与 4KB 消息一样容易支持。消息具有 AMQP 可以读取并用于帮助路由的标头。

您可以将其比作邮政服务：消息是信封，标头是写在信封上且邮件载体可见的信息，邮件载体可能会在信封上添加各种邮戳以帮助传递消息。有价值的内容在信封内，对载体隐藏且未被载体修改。这个比喻很贴切，只是 AMQP 可以根据需要无限复制消息以进行传递。

队列

队列是 AMQP 中的核心概念。每条消息始终最终都会进入队列，即使它是直接馈送客户端的内存中私有队列。为了扩展邮政比喻，队列是最终目的地或分拣办公室的中间存放区的邮箱。

队列可以将消息存储在内存中或磁盘上。它们可以搜索和重新排序消息，并且它们可以参与事务。管理员可以配置他们期望从队列获得的关于延迟、持久性、可用性等方面的服务级别。这些都是实现方面，并非由 AMQP 定义。这是商业实现可以在保持 AMQP 兼容和可互操作性的同时区分自身的一种方式。

交换机

交换机是消息的传递服务。在邮政比喻中，交换机提供分拣和递送服务。在 AMQP 模型中，选择不同的载体是如何选择不同的消息传递方式。例如，发布操作使用的交换机决定了传递是直接的还是发布订阅的。交换机概念是 AMQP 如何汇集和抽象不同的中间件交付模型。它也是协议中的主要扩展点。

客户端选择用于传递每个发布消息的交换机。交换机查看消息标头中的信息，并选择应将消息传输到何处。这就是 AMQP 如何将各种消息传递习惯用法结合在一起的方式 - 客户端可以选择哪个交换机应该路由他们的消息。

符合 AMQP 标准的实现必须支持多个交换机

在整个过程中，交换机从不存储消息，但它们会保留客户端提供给它们的绑定参数。这些绑定是交换机路由功能的参数，使一个或多个队列的选择成为可能。

绑定

提供给交换机以启用消息路由的参数称为绑定（见图 2）。绑定因交换机的性质而异；直接交换机比标头交换机需要的绑定信息更少。值得注意的是，并非总是清楚哪个实体应该为特定的消息传递交互提供绑定信息。在直接交换机中，发送方正在提供路由键和所需目标队列之间的关联。这是 JMS 和其他排队产品中常见的“目标”寻址习惯用法的起源。

在主题交换机中，接收客户端提供绑定信息，指定当主题交换机看到与任何给定客户端的绑定匹配的消息时，应将消息传递给所有客户端。

AMQP 没有“目标”的概念，因为它对消费者驱动的消息传递没有意义。它会限制其抽象路由功能。绑定概念和使用路由键作为默认寻址信息的约定克服了许多消息传递产品中存在的人为划分。

实现

没有实现的标准什么都不是。AMQP 现在有几个可用的实现。第一个实现是 iMatix OpenAMQ (openamq.org)，它是摩根大通生产环境中使用的服务器的 C 实现。

Apache 的 Qpid 项目已进入孵化阶段 (incubator.apache.org/projects/qpid.html)。它将是 Apache 的 AMQP 多语言实现，服务器以 C++ 和 Java 提供，客户端以 C、C++、Java JMS、Python 和 Ruby on Rails 提供，并且还将推出更多客户端。Qpid 拥有非常活跃的开发社区，并且在 M2 版本的开发中取得了快速进展。此外，Qpid 正被用作 IONA 和 Red Hat 等多家商业产品的基石。

最近，也是最引人入胜的是，Rabbit Technologies 基于 Erlang/OTP（开放电信平台）开发了一个实现，该平台建立在该语言对并行性和网络连接的强大支持之上。

当然，您应该能够混合和匹配来自任何供应商产品的客户端和服务器组件 - 例如，Qpid 的 Java 客户端与 RabbitMQ 的 Erlang 服务器通信。

了解有关 AMQP 的更多信息的最佳方法是访问 amqp.org，您可以在其中下载规范，试用免费实现之一，甚至构建自己的实现。协议工作组和实现组都欢迎审查和反馈；我们希望这个协议有用、成功和具有包容性。

其他标准的传输

除了用于支持组织的内部消息传递需求外，AMQP 还可以用作其他标准的标准传输；毕竟，开放标准应该使用其他开放标准构建。

许多业务消息传递标准描述了业务交易，但传输选项相对较少。HTTP 通常被使用仅仅是因为它被认为通常可用，并且防火墙通常被配置为允许 HTTP 流量通过。但是，HTTP 仅提供基本的推送消息传递语义；它不启用任何类型的回调或事件通知，并且它要求使用它的应用程序在其之上构建自己的消息存储、可靠性和访问控制设施。EDI AS2 和 WS-RM 是分层在 HTTP 上的标准的示例；但这些仅描述消息传输，而不描述消息如何传递到应用程序的语义。这给开发人员留下了一个部分解决方案和更多需要解决的问题。

通过提供 AMQP 作为业务消息传递的标准，我们可以使消息传递中间件的全部丰富性可用于其他标准。使用 AMQP 服务器，我们可以消除最终用户应用程序提供可用性和可靠性的负担，从而使它们更简单、更便宜且功能更强大。唯一的要求是运行 AMQP 服务器，并在防火墙中打开 TCP/IP 端口 5672。鉴于任何商业活动都涉及律师和合同，打开端口是获得丰富消息传递功能的一小部分代价。

TWIST 标准组织（该组织促进围绕金融供应链管理的标准）是 AMQP 工作组的成员，并推广 AMQP 作为其传输业务消息的首选标准。

FIX 社区也在考虑将 AMQP 作为 FIX 5 的可能传输层。FIX 是一种流行的交易协议，最近已扩展以支持市场数据的有效交付；但是，当前的会话层无法提供发布-订阅或可扩展的保证交付。AMQP 为 FIX 用户提供了获得他们所需功能的机会，同时保持开放性。

基于 AMQP 的 SOA

SOA（面向服务的架构）是一种使用高度内聚的服务构建大型系统的技术，这些服务松散耦合以提供业务流程。SOA 不是一个新概念。它在 90 年代中期及更早的时候就广为人知，但在其最新的化身中，它被标榜为Web 服务导向的架构。架构模式既不需要 HTTP 也不需要 XML。

SOA 最基本的部分之一是连接服务的通信机制。术语 EMB（企业消息总线）与 SOA 密切相关。

EMB 的传统部署使用了专有技术，但企业宁愿拥有基于标准的开放解决方案，以及在供应商之间进行选择和切换的能力，以及竞争带来的改进。因此，AMQP 代表了 EMB 的理想选择。它允许从专有协议干净地迁移，并为包括 Web 服务在内的其他标准提供了一条途径。

Web 服务有四个基本部分：服务描述、XML 消息内容、服务发现和传输。传输通常被认为是 HTTP，但它不一定是。企业经常使用 XML over messaging 中间件作为传输，以获得它带来的所有好处。这样做之后，企业发现他们创造了他们想要避免的问题：在专有传输上运行开放架构。将 Web 服务与 AMQP 作为传输相结合，为企业提供了其核心架构所需的丰富性和渴望的开放性。

AMQP 在 SOA 中的使用才刚刚开始，您只需要 AMQP 即可完成它。我已经参与了一个项目，将现有的关键任务 EMB 从专有中间件迁移到 AMQP，以便我们可以经济高效地将总线扩展到更多系统。

连接到旧版中间件

AMQP 是一种完整的中间件协议。它不是最低公分母解决方案，唯一的政治设计约束是它对 JMS 语义的显式支持。显然，实现 AMQP 规范的软件将能够互操作，即使该软件来自不同的供应商也是如此。这意味着产品 A 的 JMS 客户端将能够与产品 B 的 C++ 服务器通信，并将消息发送到产品 C 中的 Ruby 客户端。当然，在现实世界中，会存在一些初期困难，AMQP 工作组正在开始关注如何创建和管理协议合规性测试套件以减轻这种风险。

然而，有很多中间件产品，每个产品都有其内部架构。AMQP 工作组鼓励中间件供应商在其产品中实现 AMQP，但要获得良好的语义匹配将并非易事，并且一些供应商可能出于商业原因而不愿支持互操作性。

与此同时，将需要从专有产品的安装基础进行桥接。做到这一点的最简单方法可能是使用许多商业或开源 EAI（企业应用程序集成）软件包之一，但我们预计一些 AMQP 产品很快将包括到最常见的专有中间件的本机桥接器。

采用 AMQP

组织采用 AMQP 的最自然方式是机会主义地部署它，或者作为转向基于标准的 EMB 战略的一部分。这种方法可以使组织从具有竞争力的定价或开源解决方案中受益，并获得协议和支持它的产品的经验。这就是我们采取的方法：在隔离系统中使用 AMQP，然后分支到核心 EMB 系统。

在几年内，通过采用这种方法，您的许多消息传递可能会变为支持 AMQP 的消息传递。您当前的中间件供应商可能会采用 AMQP，并以这种方式使您能够转向基于标准的模型。AMQP 很可能最终将作为核心服务由您的网络基础设施以硬件形式提供。

另一方面，如果您的公司正在开展 SOA（或其他基于总线的架构），我们建议您认真考虑大规模部署 AMQP 作为 SOA 的骨干。这样做可能会使您能够从 AMQP 兼容中间件供应商之间的竞争中受益，从而使您能够从合适的供应商那里获得所需的支持水平和服务质量。部署 AMQP 还可能减轻供应商锁定或供应商故障对于 SOA 的关键总线组件的令人担忧的问题，这对于您的公司来说是一项长期投资。同样的思路适用于在互联网或专线上的贸易伙伴之间部署的电子业务开放协议。当然，您选择的任何策略都完全由您自己决定，并且必须根据您的具体情况确定。

结论

在经过二十年的专有消息传递中间件之后，最终出现了一种可信的基于标准的替代方案。AMQP 工作组正在迅速发展该协议，并希望在 2008 年期间达到 1.0 版本，但今天可用的实现既有用又在实际部署中得到了验证。

AMQP 让更多应用程序成为企业级应用程序，而无需承担与该标签相关的成本。它提供了一个强大的消息传递骨干网，可以成为新创新和新型应用程序的跳板。

参考文献

  1. O'Hara, R.J., Hintjens, P., Greig, R., Sim, G., et al. 2006. AMQP 高级消息队列协议版本 0.8；amqp.org/tikiwiki/tiki-index.php?page=Download。
  2. Bradner, S. 1996. IETF 标准流程，RFC 2026。
  3. Postel, J., Klensin, J. 1982/2001. 简单消息传输协议，RFC 821 / 2821。
  4. Freed, N., Borenstein, N. 1996. 多用途互联网邮件扩展 (MIME)，RFC 2045。
  5. Janssen, B. 1998. HTTP-ng 的二进制线路协议；w3.org/Protocols/HTTP-NG/。
  6. Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., Noveck, D. 2003. 网络文件系统 (NFS) 版本 4 协议，RFC 3530。
  7. Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer. H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., Paxson, V. 2000. 流控制传输协议，RFC 2960。
  8. Rose, M. 2001. 块可扩展交换协议核心，RFC 3080。
  9. Rose, M. 2002. “导言：应用程序协议设计。” BEEP：权威指南。O'Reilly。

R. JOHN O'HARA 是摩根大通的高级架构师和杰出工程师。他推动了 AMQP 的创建，并且是 FpML 金融市场消息传递标准的早期贡献者。他是 AMQP 工作组的主席。他的兴趣包括数据中心虚拟化、开源在商业数据处理中的创造性用途、事件和数据复制中间件，以及使软件架构“简单直观”。O'Hara 拥有英国阿斯顿大学电子工程和计算机科学荣誉学位。

acmqueue

最初发表于 Queue 第 5 卷，第 4 期—
在 数字图书馆 中评论本文




更多相关文章

Niklas Blum, Serge Lachapelle, Harald Alvestrand - WebRTC - 开放 Web 平台的实时通信
在这个疫情时期，世界比以往任何时候都更依赖于基于互联网的 RTC（实时通信）。在过去十年中，RTC 产品的数量呈爆炸式增长，这在很大程度上是由于更便宜的高速网络接入和更强大的设备，同时也归功于一个名为 WebRTC 的开放、免版税平台。WebRTC 正在从实现有用的体验发展为在疫情期间让数十亿人继续工作和教育，并保持重要的人际接触的关键。WebRTC 未来的机遇和影响确实令人着迷。


Benjamin Treynor Sloss, Shylaja Nukala, Vivek Rau - 重要的指标
衡量您的站点可靠性指标，设定正确的目标，并努力准确地衡量指标。然后，您会发现您的服务运行得更好，停机时间更少，并且用户采用率更高。


Silvia Esparrachiari, Tanya Reilly, Ashleigh Rentz - 跟踪和控制微服务依赖关系
如果您曾将钥匙锁在房屋或汽车内，您会对依赖循环感到熟悉。没有钥匙您就无法打开锁，但是不打开锁您就无法拿到钥匙。有些循环是显而易见的，但是更复杂的依赖循环可能很难在导致中断之前找到。跟踪和控制依赖关系的策略对于维护可靠的系统是必要的。


Diptanu Gon Choudhury, Timothy Perrett - 为互联网规模服务设计集群调度器
希望构建调度系统的工程师应考虑他们使用的底层基础设施的所有故障模式，并考虑调度系统的运营商如何在租户系统所有者进行故障排除期间配置补救策略，同时帮助保持租户系统尽可能稳定。



© 保留所有权利。

© . All rights reserved.