RabbitMQ 2.3.1 引入了几个新的插件机制，允许您更好地控制用户如何针对 Rabbit 进行身份验证，以及我们如何确定他们被授权执行的操作。这里有三个需要关注的问题

1. 客户端如何通过网络证明其身份？
2. 用户和身份验证信息（例如密码哈希）存储在哪里？
3. 权限信息存储在哪里？

对于 AMQP 来说，问题 1 的答案是 SASL - 一种用于可插拔身份验证机制的简单协议，它嵌入在 AMQP（以及各种其他协议）中。SASL 允许客户端和服务器协商并使用身份验证机制，而“外部”协议无需了解有关身份验证工作原理的任何详细信息。

SASL 提供了许多“机制”。从一开始，RabbitMQ 就支持 PLAIN 机制，该机制基本上包括以明文形式通过网络发送用户名和密码（当然，整个连接可能受 SSL 保护）。它还支持变体 AMQPLAIN 机制（在概念上与 PLAIN 相同，但如果您有 AMQP 编解码器，则更容易实现）。RabbitMQ 2.3.1 添加了一个插件系统，允许您添加或配置更多机制，并且我们编写了一个示例插件，该插件实现了 SASL EXTERNAL 机制。

有时，在我们的 邮件列表 和其他地方，会提出在 RabbitMQ 中使用不同的后端存储的想法。后端存储是负责将消息写入磁盘的部分（消息可能由于多种原因而写入磁盘），并且经常有人建议查看如果 RabbitMQ 的后端存储被另一个存储系统替换，它会是什么样子。

这种更改将允许目前无法实现的功能，例如带外队列浏览或分布式存储，但是消息代理（例如 RabbitMQ）与通用数据库之间的数据存储和访问模式的本质存在根本差异。实际上，RabbitMQ 故意不将消息存储在这样的数据库中。

我很高兴地宣布 AMQP 0.7 已发布，正如我在之前的博客文章中承诺的那样。那么变化是什么呢？

在过去的一年中，AMQP gem 的开发实际上处于停滞状态，因为其最初的作者 Aman Gupta (@tmm1) 很忙。许多错误未解决，代码变得陈旧和过时，并且没有添加新功能或文档。

此时，我开始与 RabbitMQ 团队讨论可能的合作。实际上，最初我在看到 Ezra Zygmuntowicz 正在寻找加入他云团队的人员时联系了 VMware，但当我发现 VMware 最近收购了伦敦的 RabbitMQ 项目时，我产生了兴趣。我签署了合同，从script/console切换到 Wireshark 和 RabbitMQ Tracer，从 11 月起，我一直愉快地开发 AMQP 和 AMQ-Protocol gem。

我们一直在对一个新协议进行原型设计，这是我们的惯例。这个协议称为“AMQP 1.0 R0”，它是 AMQP 工作组（RabbitMQ 以及后来的 VMware 是其中一员）的新版本。“R0”表示它是建议的第一个修订版。规范不完整：有很多待办事项，并且在很大程度上尚未得到验证。这两个事实是我们促使进行此原型设计的部分原因。

原型代码镜像在 github 上：https://github.com/rabbitmq/rabbitmq-amqp1.0。它的构建方式与我们所有的插件完全相同。

AMQP 1.0 R0 规范与先前版本的 AMQP 规范的不同之处在于，它没有定义代理模型；即，它没有定义交换机、队列和绑定，或其等效项。该协议实际上只是关于将消息从一个代理传输到另一个代理，然后就结果达成一致。这意味着它适用于附加到消息代理实现，以及其他用途 - 其想法是人们可以调整现有模型以适应。

在我们的案例中，现有的模型是 AMQP 0-9-1，并进行了一些泛化和扩展（例如，链式绑定）。因此，我们的原型目标能够使用 1.0 客户端和 0-9-1 客户端同时连接完成一些有用的工作。

好吧，好消息是，我们已经实现了这一点。事实上，插件可以设置为替换 Rabbit 通常的网络侦听器，并且可以愉快地与 AMQP 0-8、0-9-1 和 1.0 客户端通信。我们确实需要在此过程中进行一些创造，并且我们没有实现规范的某些部分。这些内容很快将在 README 中详细说明。

发明的一大部分是填充规范中没有说明的语义。其中一些在 我们为 AMQP 工作组完成的这个客户端-代理协议工作中进行了详细说明。我们希望原型设计将有助于进一步完善这一点。

下周，我将把我们的原型带到 AMQP 1.0“Connectathon”，在那里它将针对核心协议的其他实现（并非所有这些都是开源的）进行测试。同样，这将有助于消除规范中互操作性的障碍。

RabbitMQ 需要更多更好的文档。（谁不需要呢？）特别是，我们需要更多更好的入门资料，向读者介绍各种基本概念，解释它们为什么重要，并鼓励他或她继续阅读并学习更多关于 RabbitMQ 的知识。以下是该简介第 1 章的剪辑。欢迎您发表评论，第 2 章和第 3 章将很快发布。（您可能已经了解所有这些内容，但令人惊讶的是，许多人并不了解。本简介适用于他们。）

对于那些远离互联网的人来说，node.js 是一个基于 Google V8 的事件驱动的 JavaScript 引擎。因为它本质上是一个大型、高效的事件循环，所以它非常适合在少量状态之间来回传递数据的程序。而且编程很有趣，显然很多人也这么认为，因为围绕它出现了大量的库。

在这些库中，比较令人印象深刻的是 Socket.IO。可以将 Socket.IO 与 node.js 的内置 Web 服务器结合使用以创建 websocket 服务器，并为浏览器提供套接字抽象，当没有 websockets 时，它会降级为 XHR 技巧。（我很乐意相信 node.js 和 Socket.IO 是由一个仁慈且有远见的先驱种族为我们创建的；但当然，它们是由勤奋聪明的人创造的。谢谢，大家！）

一旦在浏览器中有了套接字抽象，整个世界就打开了。具体来说，为了我们的目的，一个充满消息的世界。由于 node.js 有一个 AMQP 客户端，我们可以很容易地将其与 RabbitMQ 连接起来；不仅可以桥接到其他协议和后端系统，还可以提供浏览器之间、应用程序服务器之间等等的消息传递。

继 我们与 ZeroMQ 的 Martin Sustrik 合作之后，我决定为在浏览器套接字上使用的非常简单的协议，反映 ZeroMQ 中（以及 RMQ-0MQ 中）使用的消息模式 - **发布/订阅**、**请求/回复**和**推送/拉取**（或管道）。我编写了一个 node.js 库，它使用 RabbitMQ 通过其路由和缓冲来实现消息模式；桥接然后是免费的，因为 RabbitMQ 有一堆用于各种语言的协议适配器和客户端。

消息模式的简要说明

**发布/订阅**用于发布的消息应传递给多个订阅者的场景。在一般情况下，可以使用各种类型的路由来为每个订阅者过滤消息。例如，这可能用于将后端系统中的通知广播到用户的浏览器。

**请求/回复**用于通过消息传递进行 RPC；请求在工作进程之间轮询分发，回复路由回请求套接字。这可能用于浏览器查询后端服务；甚至用于浏览器相互查询。

**管道**用于将进程链接在一起。消息按轮询方式推送到工作进程，这些进程本身可能会推送到另一个处理阶段。这可能用于协调用户组（或个人）之间的工作流。

在正式介绍后，这里就是rabbit.js。

它只需要安装一个基本的 RabbitMQ 和 node.js；以及 node-amqp 和 Socket.IO 库。这些内容的说明和位置在 README 中。（请注意，您需要 我分叉的 node-amqp。）

它还包含一个微型消息套接字服务器；即一个接受套接字连接并以长度前缀消息进行通信的 node.js 服务器。由于所有内容都通过 RabbitMQ 进行，因此您可以通过套接字与使用 Socket.IO 连接的浏览器进行通信。您还可以使用来自 node.js 本身运行的代码的进程内管道服务器。

总而言之，我很惊讶只需几行代码和一些各具优势的技术就能完成多少工作 - node.js 用于有趣的网络服务器编程、Socket.IO 用于神奇的浏览器套接字，以及 RabbitMQ 用于无泪消息传递。

从 RabbitMQ 2.1.1 版本开始，支持交换机之间的绑定。这是 AMQP 规范的扩展，使用此功能将（目前）导致您的应用程序仅与 RabbitMQ 兼容，而不是其他众多 AMQP 0-9-1 代理实现。但是，此扩展极大地提高了路由拓扑的表达能力和灵活性，同时解决了某些可扩展性问题。

普通的绑定允许交换机绑定到队列：发布到交换机的消息，只要满足交换机及其绑定的各种条件，就会通过各种绑定，并在每个绑定的末尾追加到队列中。这对许多用例来说都很好，但灵活性很差：它始终只是一个跳跃——消息发布到一个交换机，具有一组绑定，因此只有一组可能的目的地。如果您需要更灵活的东西，则必须诉诸多次发布相同的消息。通过交换机到交换机的绑定，发布一次的消息可以流经任意数量的交换机，使用不同的类型，并且路由拓扑比以前复杂得多。

最近，我和 Michael Bridgen 实现了一个桥接器，用于连接 RabbitMQ 代理与使用 0MQ 进行消息传递的应用程序。

它在这里： https://github.com/rabbitmq/rmq-0mq

那么：用户通过并行使用这两个产品可以获得什么好处？

我正在设置我的旧 MacBook，从我的室友那里收回，以便能够用于编程。