跳至主内容

RabbitMQ 3.7 新特性

·阅读 7 分钟
Michael Klishin
Michael Klishin

经过一年多的努力，RabbitMQ 3.7.0 已在假期开始前悄然发布。此次发布深受社区对 3.6.x 版本反馈的启发。在本篇文章中，我们将介绍此次发布的一些亮点。

RabbitMQ 3.7.0 专注于提高自动化友好性和可操作性。

新的配置格式​

让我们从新的配置格式开始。过去，RabbitMQ 一直使用 Erlang 术语文件进行配置。我们将在另一篇博文中详细介绍其优缺点。最重要的是，经典格式难以生成，这使得自动化变得复杂。

新格式深受 sysctl 和 ini 文件的启发。它对人类更易读，也更容易被配置工具生成。

请对比我们 TLS 指南中的以下示例。

经典（Erlang 术语）格式

[
    {ssl, [{versions, ['tlsv1.2', 'tlsv1.1']}]},
    {rabbit, [
            {ssl_listeners, [5671]},
            {ssl_options, [{cacertfile,"/path/to/ca_certificate.pem"},
                            {certfile,  "/path/to/server_certificate.pem"},
                            {keyfile,   "/path/to/server_key.pem"},
                            {versions, ['tlsv1.2', 'tlsv1.1']}
                            ]}
            ]}
].

与新格式的对比

listeners.ssl.1 = 5671
ssl_options.cacertfile = /path/to/ca_certificate.pem
ssl_options.certfile   = /path/to/server_certificate.pem
ssl_options.keyfile    = /path/to/server_key.pem
ssl_options.versions.1 = tlsv1.2
ssl_options.versions.2 = tlsv1.1

除了对人类和机器更友好之外，新的配置文件还包括对密钥和某些值类型（如文件路径）的验证。如果证书或公钥文件不存在，节点将报告错误并无法启动。未知或拼写错误的密钥也是如此。

敬请期待未来关于新格式的更详细的博文。

对等发现子系统​

当 RabbitMQ 集群首次形成时，新启动的节点需要一种相互发现的方式。在 3.6.x 及之前的版本中，有两种实现方式：

  • CLI 工具
  • 配置文件中的节点列表

前一种选项被一些配置工具使用，但通常不太友好于自动化。后一种更方便，但也有其局限性：节点集是固定的，更改它需要重新部署配置文件和重启节点。

还有第三种选择，并且它在社区中已经存在了几年：由 Gavin Roy 开发的 rabbitmq-autocluster。该插件修改了 RabbitMQ 的启动过程，使对等发现更加动态：例如，对等节点列表可以从 AWS 自动扩展组或 etcd 等外部工具中检索。

对于 RabbitMQ 3.7.0，我们采用了 `rabbitmq-autocluster` 并将其核心思想集成到核心中，并根据我们生产环境中 RabbitMQ 安装的经验和社区反馈进行了一些修改。

结果是一个新的 对等发现子系统，它将在另一篇博文中进行介绍。它支持多种机制和平台：

  • AWS（EC2 实例标签或自动扩展组）
  • Kubernetes
  • etcd
  • Consul
  • 预配置的 DNS 记录
  • 配置文件

并且在未来易于支持更多选项。

分布式管理插件​

统计数据库过载是早期版本的一个主要痛点。这与原始管理插件的设计有关，它将整个集群的统计数据收集和聚合委托给一个专用的节点。无论该节点多么高效，这都有扩展性限制。

一度，这个问题占了支持工单和邮件列表帖子的大部分，因此决定对管理插件进行重大且破坏性的重新设计是值得的。

在新设计中，每个节点都托管和聚合自己的统计数据，并在收到 HTTP API 请求时按需从其他节点请求数据。我们现在已经有近一年的支持数据和用户反馈，并且很高兴地报告统计数据库过载现在已基本不再是问题。

这些更改已向后移植到 3.6.x 版本，从 3.6.7 开始。

重新设计的 CLI 工具​

RabbitMQ CLI 一个长期存在的限制是插件无法扩展它。这一情况随着 3.7.0 版本的发布而改变。像 Shovel 和 Federation 这样的插件现在可以提供自己的命令，帮助操作员评估系统状态并进行管理。

`rabbitmq-diagnostics` 是一个面向操作员的新命令，它包含了一些以前在 `rabbitmqctl` 中可用的命令，以及一些新命令。诊断命令列表将根据我们在邮件列表上的用户反馈继续增长。

代理协议支持​

客户端通过 HAproxy 或 AWS ELB 等代理连接到 RabbitMQ 节点是很常见的。这对操作员造成了一个复杂问题：节点不再知道真实的客户端 IP 地址，因此无法记录、在管理 UI 中显示等。

幸运的是，这个问题有一个解决方案，并且得到了一些最流行的代理工具的支持：代理协议。从 3.7.0 开始，如果操作员选择启用，RabbitMQ 支持代理协议。它需要一个兼容的代理，但不需要修改客户端库。根据代理协议规范的要求，当启用该协议时，将不再支持直接客户端连接。

跨协议 Shovel​

Shovel 插件现在支持双向的 AMQP 1.0 端点（作为源和目标）。这意味着 Shovel 现在可以将消息从仅支持 AMQP 1.0 的代理移动到 RabbitMQ，反之亦然。

运营商策略​

操作员策略 的工作方式与常规策略类似，但只能由管理员管理，并且会覆盖用户定义的策略。提供 RabbitMQ 作为服务的操作员可以使用它们来限制特定计划的队列最大长度等。

每个虚拟主机消息存储​

从 3.7.0 开始，每个虚拟主机都有自己的消息存储（实际上是两个存储）。这主要是为了提高弹性，并将潜在的消息存储故障限制在单个虚拟主机内，但也可以提高多虚拟主机环境中的磁盘 I/O 利用率。

其他值得注意的更改​

最低要求的 Erlang/OTP 版本现在是 19.3。我们强烈建议至少使用 19.3.6.5。该版本包含对两个可能阻止带有活动 TCP 连接的节点关闭的错误的修复，这反过来可能大大简化自动化升级。该版本与 20.1.7 和 20.2.x 一起包含对最近披露的ROBOT TLS 攻击的修复。

在 3.7 开发周期中，我们为客户端引入了新的版本方案。Java 和 .NET 的客户端库发布不再与 RabbitMQ 服务器的版本绑定。这使得客户端能够更快地发展，并遵循对它们有意义的版本方案。Java 和 .NET 客户端现在都已进入 5.x 版本，并且包含重要的更改，这些更改需要一个主版本号的提升，例如 lambda 和 .NET Core 支持。

软件包分发更改​

从 3.7.0 开始，RabbitMQ 软件包（二进制构件）通过三个服务进行分发：

  • Bintray 提供软件包下载以及 Debian 和 Yum (RPM) 仓库。
  • Package Cloud 提供 Debian 和 Yum 仓库。
  • GitHub releases 包含所有版本说明并提供备用软件包下载选项。

如果您目前从 rabbitmq.com 获取软件包，请切换到以上选项之一。

与 rabbitmq.com 的旧 apt 仓库不同，Package Cloud 和 Bintray 提供比最新版本更早的版本。当然，现在也有针对 RabbitMQ 本身以及我们的零依赖 Erlang/OTP RPM 包的官方 Yum 仓库。

Java 客户端发布现在仅通过 Maven 仓库（最著名的是 Maven Central）分发。 .NET 客户端发布仅通过 NuGet 提供。

升级到 3.7.x​

我们鼓励所有用户升级到 3.7.x，并在邮件列表中告诉我们您的使用情况。为了简化过渡，我们提供了一个新的关于升级的文档指南。当然，请务必先查阅完整的更改日志！

© . This site is unofficial and not affiliated with VMware.