65 篇帖子,标签为“新功能”
查看所有标签rabbitmq-tracing - firehose 的 UI
Federation 插件预览版发布
注意:这篇博文讨论的是为 RabbitMQ 2.5.0 发布的 federation 插件预览版。如果您使用的是 2.6.0 或更高版本,federation 是主版本的一部分;以与其他任何插件相同的方式获取它。
又一天,又一个新插件发布😃今天的主角是 federation。如果您想跳过这篇文章并直接下载插件,请转到此处。详细说明请参见此处。
federation 的高层次目标是在 WAN 和管理域之间横向扩展发布/订阅消息传递。
为此,我们引入了federation exchange的概念。federation exchange 的行为类似于给定类型的普通 exchange(它可以模拟任何已安装的 exchange 类型的路由逻辑),但也知道如何连接到上游 exchange(这些 exchange 本身也可能是 federation exchange)。
发送方选择的分发
RabbitMQ 2.4.0 引入了一个扩展,允许发布者在 CC 和 BCC 消息头中指定多个路由键。BCC 消息头在传递消息之前会从消息中删除。直接和主题 exchange 是唯二使用路由键的标准 exchange 类型,因此,此功能的路由逻辑仅适用于这些 exchange 类型。
介绍发布者确认
在许多消息传递场景中,您绝不能丢失消息。由于 AMQP 对消息持久性/处理的保证很少,因此传统的做法是使用事务,但事务的速度可能慢得令人无法接受。为了解决这个问题,我们以轻量级发布者确认的形式向 AMQP 引入了一个扩展。
你是谁?RabbitMQ 2.3.1 中的身份验证和授权
RabbitMQ 2.3.1 引入了几个新的插件机制,使您可以更好地控制用户如何针对 Rabbit 进行身份验证,以及我们如何确定他们被授权执行的操作。这里有三个需要关注的问题
- 客户端如何在线路上证明其身份?
- 用户和身份验证信息(例如密码哈希)存储在哪里?
- 权限信息存储在哪里?
问题 1 在 AMQP 的情况下通过 SASL 解决 - 一种用于可插拔身份验证机制的简单协议,嵌入在 AMQP(和各种其他协议)中。SASL 允许客户端和服务器协商和使用身份验证机制,而“外部”协议无需了解有关身份验证如何工作的任何详细信息。
SASL 提供了许多“机制”。从一开始,RabbitMQ 就支持 PLAIN 机制,该机制基本上包括在线路上以明文形式发送用户名和密码(当然,整个连接可能受到 SSL 的保护)。它还支持变体 AMQPLAIN 机制(在概念上与 PLAIN 相同,但如果您有 AMQP 编解码器,则更容易实现)。RabbitMQ 2.3.1 添加了一个插件系统,允许您添加或配置更多机制,并且我们编写了一个示例插件,实现了 SASL EXTERNAL 机制。
Ruby AMQP 0.7 发布!
我很高兴地宣布 AMQP 0.7 已发布,正如我在之前的博文中承诺的那样。那么有哪些变化呢?
AMQP 1.0 原型设计
我们一直在为新协议原型设计支持,这已成为我们的习惯。这个新协议称为“AMQP 1.0 R0”,它是 AMQP 工作组(RabbitMQ 和后来的 VMware 是其成员)的新问题。“R0”表示它是建议的第一个修订版。该规范尚不完整:有很多 TODO,并且在很大程度上未经证实。这两个事实是促使进行此原型设计的部分原因。
原型代码镜像在 github 上:http://github.com/rabbitmq/rabbitmq-amqp1.0。它的构建方式与我们所有插件的构建方式相同。
AMQP 1.0 R0 规范与以前版本的 AMQP 规范不同,因为它没有定义代理模型;即,它没有定义 exchange、队列和绑定,或它们的等价物。该协议实际上仅关于将消息从一个代理传输到另一个代理,然后就结果达成一致。这意味着它适用于附加到消息代理实现,以及其他用途——其想法是,人们可以调整现有模型以适应。
在我们的案例中,现有的模型是 AMQP 0-9-1,带有一些泛化和扩展(例如,链式绑定)。因此,我们原型的目标是能够让 1.0 客户端和 0-9-1 客户端同时连接时完成一些有用的工作。
嗯,好消息是,我们已经实现了这一点。事实上,该插件可以设置为替换 Rabbit 的常用网络侦听器,并且可以愉快地与 AMQP 0-8、0-9-1 和 1.0 客户端对话。我们一路走来确实进行了一些发明,并且规范的某些部分我们明显没有实现。这些内容将在 README 中详细说明。
其中一个重要的发明是填补规范中未明确说明的语义。其中一些在我们在 AMQP 工作组中所做的此客户端-代理协议工作中进行了详细说明。我们希望原型设计将有助于进一步完善这一点。
下周我将把我们的原型带到 AMQP 1.0“Connectathon”,在那里它将针对核心协议的其他实现进行测试(并非所有实现都是开源的)。同样,这将有助于找出规范中互操作性的障碍。
Exchange 到 Exchange 绑定
RabbitMQ 2.1.1 中引入了对 exchange 之间绑定的支持。这是 AMQP 规范的扩展,使用此功能(目前)将导致您的应用程序只能与 RabbitMQ 一起使用,而不能与外界无数的其他 AMQP 0-9-1 代理实现一起使用。但是,此扩展极大地提高了路由拓扑的表达性和灵活性,同时还解决了一些可扩展性问题。
普通绑定允许 exchange 绑定到队列:发布到 exchange 的消息,如果满足 exchange 及其各种绑定的各种标准,将通过各种绑定,并附加到每个绑定末尾的队列。这对于许多用例来说很好,但灵活性很差:它始终只是一跳——消息发布到一个 exchange,具有一组绑定,因此可能有一组目的地。如果您需要更灵活的东西,那么您必须多次发布同一条消息。通过 exchange 到 exchange 绑定,一条消息发布一次,可以流经任意数量的 exchange,具有不同的类型,以及比以前可能实现的复杂得多的路由拓扑。
RabbitMQ/0MQ 桥
最近,Michael Bridgen 和我实现了一个桥梁,用于将 RabbitMQ 代理与使用 0MQ 进行消息传递的应用程序连接起来。
就在这里:http://github.com/rabbitmq/rmq-0mq
那么:用户并行使用这两种产品可以获得什么好处呢?