高弹性、低成本的云消息队列 RabbitMQ 版

摘要：本次分享的主题是高弹性、低成本的云消息队列 RabbitMQ 版，由阿里云消息队列产品专家杨文婷分享。接下来将从四个方面进行介绍。首先会阐述这款语音消息队列相比 ABQ 具有哪些优势。针对这些优势会详细讲解其架构实现原理。在此基础上会进一步说明，利用这一架构实现的 Serverless 系列能为大家带来哪些好处。之后会探讨这个系列产品的适用场景分别是什么。

1. 云消息队列 RabbitMQ 的产品优势

2. 架构实现原理

3. 高弹性低成本的 Serverless 系列

4. Serverless 系列适用场景

01. 云消息队列 RabbitMQ 的产品优势 

在此之前，有一个前提条件需要特别指出：云消息队列 RabbitMQ 并非开源的托管版本，而是基于自主研发的高可用分布式存储架构实现的，它遵循 AMQP 协议 0-9-1 版本，是一款功能强大的消息队列产品。

云消息队列产品具备三大显著优势。首先，它能够让大家十分安心的是该产品完全兼容开源客户端。由于它支持 AMQP 协议，因此开源的所有语言、所有版本的客户端都能实现无缝上云使用。这意味着用户无需修改任何代码，仅需调整服务接入点，即可轻松接入并使用。在保持这一兼容性的基础上架构还成功解决了开源产品中存在的许多稳定性问题。

比如，开源消息队列的堆积能力可能会导致服务在单机状态下不可用，同时其集群的容量受限于机器规格的上限。另外，当尝试支持多可用区的高可用性时，开源消息队列很容易出现脑裂等问题。而开源消息队列的运维也因其基于的编程语言而面临挑战，往往难以快速定位并解决根本原因。然而在云上的消息队列产品中，这些问题都不复存在。因为架构从根本上解决了这些开源稳定性方面的痛点，确保了产品的稳定与可靠。

再者基于 Server 弹性以及该架构，还能为用户提供卓越的弹性能力。得益于其分布式架构的设计，该产品拥有极高的弹性。同时它采用按量付费的模式，使得用户能够以低成本享受这一消息队列产品。具体来说，其弹性能力体现在秒级扩展上，能够轻松支持高达 5 万 QPS 的弹性需求。

除了上述特点外，作为商业化产品还为用户提供了极为强大的可观测性能力，以助力用户高效排查线上业务问题。在监控方面为用户提供了十分完善的监控指标。这些指标不仅种类繁多，而且 Label 的粒度非常细致，能够精确到 Exchange 和 Queue 级别。同时还提供了非常直观的数据大盘。通过展示的两个截图，用户可以一目了然地查看到实例资源中所有 Exchange 的各项指标排序情况，以及资源在解决问题过程中的趋势变化。

另外与开源产品相比还具有一个显著的优势，即消息轨迹查询能力。在这张图中，用户可以看到非常详尽的生产者信息，包括消息的路由、入队信息，以及消息的投递和 ACK 的完整信息。借助这些信息，用户可以迅速定位问题出现的原因及具体环节。

02. 架构实现原理

展开来讲如何实现这一高弹性且无需频繁扩容的优势的。这背后其实依赖于两个关键点：一个是纯算分离的分布式架构，另一个则是我们强大的弹性调度系统。分布式架构是实现高弹性的经典方式之一。它主要分为计算层和存储层。计算层主要负责协议适配，如 AMQP 0-9-1 协议，以及处理商业化权限、负载均衡等计算相关的逻辑。而存储层则专注于存储队列中的消息，处理消息的删除、 ACK 、提交、写入等存储相关的能力。这两层是分离且各自独立的。

实际上计算层和存储层都可以分别进行扩容，并且它们被部署在多个可用区内。图中虽然仅展示了两个可用区，但实际上它们可以部署在不同的可用区中。因此，当某个可用区遭遇网络或电力等故障时，人员和客户端可以无缝地重新连接到另一个可用区，并确保消息能够平稳迁移。在此基础上为什么又能够实现快速扩容呢？由于采用的是分布式架构，无论是计算节点还是存储节点，都可以通过横向扩容的方式增加节点，从而通过扩容来提升整体容量。

服务的高可用性实际上是基于多可用区部署的策略来实现的。在两个可用区中，节点之间是平等的，并且采用主从架构，虽然与开源的主副节点架构有所不同，但这里强调的是节点的平等性。在异常情况发生时，前端负载均衡能够迅速将服务切换到另一个可用区。此外之所以不存在脑裂问题，是因为所有节点都是对等的，因此从根本上避免了选举主节点时可能出现的分裂情况。

在这种情况下如何实现快速的弹性扩展呢？这主要依赖于实现的弹性调度系统。首先该系统包含一个监控模块，该模块能够快速分析整个集群的流量、服务指标、集群水位以及资源池的各项指标。接着根据预设的计算规则，系统会通过 ACK 容器服务，迅速地在每个集群中拉起缺失的节点，从而实现机器的快速扩容。这包括实例的迁移、流量的迁移以及容灾切换等操作，都是通过调度系统拉起缺失的容器节点来完成的。因此正是得益于这种高效的监控与调度机制，系统才能够实现快速的弹性扩展以及多可用区的高可用性。

在底层，容器技术实际上调用了阿里巴巴的整个ECS资源池，以及云盘、 OSS 和盘古等多种存储资源，还有网络负载均衡等多样化的资源。在这个庞大的资源池支持下，系统能够拥有巨大的资源数量。通过容器的快速启动和计算，以及集群水位的动态计算，系统能够迅速地实现弹性的资源调度和扩展。

03. 高弹性低成本的 Serverless 系列

在这个基础上推出了高弹性、低成本的 Service 系列，这一系列为用户带来了两大显著好处。首先它的付费模式是按量计费，即根据累计的消息收发次数来收费。这种模式为用户提供了一个低成本、零门槛的付费选择。具体来说，用户在开通实例时无需支付任何费用，只有在真正进行消息收发、创建 Queue 资源时，才会产生费用。大家无需像其他云厂商那样，在开始时就需要预估业务的最高峰值，并根据这个峰值去部署一个最大规格的集群。因为很多时候，这样的部署会导致资源的浪费。而我们则可以根据实际的业务流量来计费，这有效地解决了用户的成本问题。

此外资源池规模庞大，因此您无需担心突发流量或大流量会导致集群水位不足的问题。您也无需预估将来可能达到的最大流量，并据此部署多种规格的集群。而服务也无需进行容量评估，从而降低了您的运维成本。

04. Serverless 系列适用场景

在此基础上 Service 系列适用的场景非常广泛。它实现了开箱即用，只需简单点击购买，即可立即创建实例。在创建实例后，对于许多场景，特别是在普通流量场景下，它能够显著节约成本。由于无需根据峰值流量预部署资源，可以根据实际流量来付费。因此，大部分闲置资源无需支付费用。

在一些极端情况下，比如开发测试环境，消息量通常非常少。许多开发测试环境使用 Service ，可能每月仅需支付不到 10 元或非常低廉的费用，即可满足其需求。在这样的开发测试环境下，很多团队或项目经常需要创建独立的环境，比如每个项目或业务线都可能需要一个独立的环境。在这种情况下 Service 能够大量节约机器资源。

还有一个场景是有一些业务具有非常明显的流量波峰和波谷。例如充电桩业务、学校打开水业务，或是 KTV 等娱乐场所。这些业务在一天中的大部分时间里可能几乎没有流量，但在某些特定时段会有大量使用。比如学校的打开水业务，可能仅在每天的晚饭后高峰期有较高流量，而其他 22 或 23 个小时里几乎无流量。对于这类业务 Service 能够极大地节约成本，非常适合它们的使用。

而在面对非预期流量，比如突发流量的情况。如果采用传统的自建系统或其他厂商按机器规格购买的方案，很难保障这种突发流量的稳定性。例如，一些游戏活动在人数突然增加时，流量峰值会非常高，这是非预期的。另外，很多平台软件会允许第三方随机提交数据，这时可能会突然出现一个巨大的数据提交量，需要缓慢地分配给下游的消费者，从而形成一个流量高峰。在这种情况下弹性服务，特别是高达 5 万 QPS 的弹性能力，能够满足这些突发流量的业务需求。因此在这些场景下实际上在很多情况下都节约了大量的成本，有时甚至可以达到 50% 到 80% 左右的成本节约。