技术盘点：消息中间件的过去、现在和未来

作者介绍：林清山（花名：隆基）

操作系统、数据库、中间件是基础软件的三驾马车，而消息队列属于最经典的中间件之一，已经有 30 多年的历史。其发展主要经历了以下几个阶段：

第一个阶段，2000 年之前。 80 年代诞生了第一款消息队列是 The Information Bus，第一次提出发布订阅模式来解决软件之间的通信问题；到了 90 年代，则是国际商业软件巨头的时代，IBM、Oracle、Microsoft 纷纷推出了自己的 MQ，其中最具代表性的是 IBM MQ，价格昂贵，面向高端企业，如大型金融、电信等企业；这类商业 MQ 一般采用高端硬件，软硬件一体机交付，MQ 本身的架构是单机架构。

第二阶段，2000~2007 年。 进入 00 年代后，初代开源消息队列崛起，诞生了 JMS、AMQP 两大标准，与之对应的两个实现分别为 ActiveMQ、RabbitMQ，开源极大的促进了消息队列的流行度，降低了使用门槛，逐渐成为了企业级架构的标配。相比于今天而言，这类 MQ 主要还是面向传统企业级应用，面向小流量场景，横向扩展能力比较弱。

第三阶段，2007~2018 年。 PC 互联网、移动互联网爆发式发展。由于传统的消息队列无法承受亿级用户的访问流量和海量数据传输，诞生了互联网消息中间件，核心能力是全面采用分布式架构、具备很强的横向扩展能力，开源典型代表有 Kafka、RocketMQ，还有淘宝的 Notify。Kafka 的诞生还将消息中间件从 Messaging 领域延伸到了 Streaming 领域，从分布式应用的异步解耦场景延伸到大数据领域的流存储和流计算场景。

第四阶段，2014~至今。 IoT、云计算、云原生引领了新的技术趋势。面向 IoT 的场景，消息队列开始从云内服务端应用通信，延伸到边缘机房和物联网终端设备，支持 MQTT 等物联网标准协议也成了各大消息队列的标配。

随着云计算的普及，云原生的理念深入人心，各种云原生代表技术层出不穷，包括容器、微服务、Serverless、Service Mesh、事件驱动等。云原生的核心问题是如何重新设计应用，才能充分释放云计算的技术红利，实现业务成功最短路径。

消息队列本身作为云计算的 PaaS 服务之一，要进一步发挥“解耦”的能力，帮助业务构建现代化应用，这里最关键的一个能力演进是 Eventing 的演进。通过将消息升华为“事件”，提供面向标准 CloudEvent 的编排过滤、发布订阅等能力构建更大范围的解耦，包括云服务事件和业务应用的解耦、跨组织 SaaS 业务事件的解耦、遗留应用和现代化应用的解耦等，同时事件驱动也是天然符合云计算 Serverless 函数计算的范式，是应用 Serverless 化演进的催化剂。

云原生对于消息中间件而言，还有另一层含义就是消息队列自身架构的云原生化演进，如何充分发挥云的弹性计算、存储、网络，让自己获得更强的技术指标和 Serverless 弹性能力。

消息中间件在技术上有哪些进展与突破？

阿里云 MQ 是基于 RocketMQ 打造的一站式消息服务，以 RocketMQ 作为统一内核，实现业界标准、主流的消息协议，包括 MQTT、Kafka、RabbitMQ、AMQP、CloudEvent、HTTP 等，满足客户多样化场景诉求。为了提高易用性，我们分别对不同的协议进行了产品化，以独立产品的模式提供消息服务（如阿里云 RabbitMQ、阿里云 Kafka），开箱即用、免运维、完备的可观测体系，帮助开源客户无缝迁云。

在经历数万企业客户多样化场景的持续打磨，数年的超大规模云计算的生产实践，我们的内核 RocketMQ 逐渐往一体化架构和云原生架构演进。

1. 一体化架构

微服务、大数据、实时计算、IoT、事件驱动等技术潮流，不断的扩展消息的业务边界，业界有不同的消息队列满足不同的业务场景，比如 RabbitMQ 侧重满足微服务场景，Kafka 则是侧重于满足大数据、事件流场景，EMQ 则是满足了 IoT 垂直领域场景。而随着数字化转型的深入，客户的业务往往同时涉及交叉场景，比如来自物联网设备的消息、或者微服务系统产生的业务消息要进行实时计算，如果是引入多套系统，会带来额外的机器、运维、学习等成本。

在过去“分”往往是技术实现的妥协，而现在“合”才是用户的真正需求。 RocketMQ 5.0 基于统一 Commitlog 扩展多元化索引，包括时间索引、百万队列索引、事务索引、KV 索引、批量索引、逻辑队列等技术。在场景上同时支撑了 RabbitMQ、Kafka、MQTT、边缘轻量计算等产品能力，真正实现了“消息、事件、流”，“云边端”一体化架构。

2. 云原生架构

云原生架构是指云上原生的架构，云计算是云原生的“源动力”，脱离了云计算谈云原生如同纸上谈兵。RocketMQ 过去几年正是立足于阿里云超大规模的云计算生产实践，帮助数万企业完成数字化转型的经验中吸取养分，从而完成互联网消息中间件到云原生消息中间件的进化。这也是 RocketMQ 和其他消息中间件最大的区别，他是实践出来的云原生架构，下面我们盘点一下 RocketMQ 在云原生架构的关键技术演进。

RocketMQ 是 2011 年诞生于淘宝核心电商系统，一开始是定位于服务集团业务，面向单一超大规模互联网企业设计。原来的架构并不能很好的满足云计算的场景，有不少的痛点，比如重型 SDK，客户端逻辑复杂、多语言 SDK 开发成本高、商业特性迭代慢；弹性能力差，计算存储耦合、客户端和物理队列数耦合、队列数无法扩展到百万级、千万级；而其他主流的开源消息项目也同样未进行云原生架构的转型，比如 RabbitMQ 单队列能力无法横向扩展、Kafka 弹性扩容会面临大量的数据拷贝均衡等，都不适用于在公共云为大规模客户提供弹性服务。

为此，RocketMQ 5.0 面向云计算的场景进行重新设计，期望从架构层面解决根本性问题，对客户端、Broker 到存储引擎全面升级：

客户端轻量化。 RocketMQ 5.0 SDK 把大量逻辑下沉到服务端，代码行数精简三分之二，开发维护多语言 SDK 的成本大幅度降低；轻量的 SDK 更容易被 Service Mesh、Dapr 等云原生代表技术集成。

可分可合的存算分离架构。 用户根据不同的场景诉求,既可以同一进程启动存储和计算的功能，也可以将两者分开部署。分开部署后的计算节点可以做到“无状态”，一个接入点可代理所有流量，在云上结合新硬件内核旁路技术，可以降低分离部署带来的性能及延迟问题。而选择“存储计算一体化”架构，则具备“就近计算”的优势，性能更优。在云上多租、多 VPC 复杂网络、多协议接入方式的场景下，采用存储计算分离模式能够避免后端存储服务直接暴露给客户端，便于实现流量的管控、隔离、调度、权限管理、协议转换等。

但是有利必有弊，存算分离也同时带来了链路变长、延迟增大、机器成本上升等问题，运维也没得到简化，除了要运维有状态存储节点外，还要多运维无状态计算节点。其实在大多数简单消息收发场景，数据链路基本上就是写 Log、读 Log，无复杂计算逻辑（计算逻辑和数据库相比太简单），这个时候优选存储计算一体化架构，简单够用、性能高、延迟低。 特别是在大数据传输场景下，存算一体能够极大降低机器及流量成本，这个从 Kafka 的架构演进也可以得到印证。总的来说不要为了存算分离而分离，还是要回归客户、业务场景的本质诉求。

弹性存储引擎。 面向 IoT 海量设备、云上大规模小客户场景，我们引入 LSM 的 KV 索引，实现单机海量队列的能力，队列数量可以无限扩展；为了进一步释放云存储的能力，我们实现分级存储，消息存储时长从 3 天提高到月、年级别，存储空间可以无限扩展，同时还分离了冷热数据，冷数据存储成本降低了 80%。

Serverless 化。 在老架构里面，客户感知物理队列，物理队列绑定固定存储节点，强状态。Broker、客户端、物理队列的扩缩容互相耦合，负载均衡粒度是队列级，对 Serverless 的技术演进很不友好。为了实现极致弹性 Serverless，RocketMQ 5.0 对逻辑资源和物理资源做进一步的解耦。

在 Messaging/无序消息的场景，客户指定 Topic 进行消息无序收发，新架构对客户端屏蔽队列概念，只暴露逻辑资源 Topic。负载均衡粒度从队列级到消息级，实现了客户端的无状态化，客户端、服务端弹性伸缩解耦。

在 Streaming/顺序消息的场景，客户端需要指定 Topic 下的某个队列（也称分区）进行消息顺序收发。在新架构里，对客户端屏蔽物理队列，引入逻辑队列概念，一个逻辑队列通过横向分片和纵向分段，分散在不同的物理存储节点。横向分片解决了高可用问题，同一个逻辑队列的多个分片多点随机可写，基于 Happen before 的原理保序，秒级 Failover，无需主备切换；纵向分段，解决逻辑队列的扩容问题，通过多级队列映射，实现 0 数据迁移的秒级扩容，逻辑资源和物理资源的弹性伸缩解耦。

如何看待消息领域生态玩家?

在云原生、IoT、大数据的趋势引导下，消息成为现代化应用架构的刚需，使用场景更加广泛，可应用于微服务的异步解耦、事件驱动、物联网设备数据上下行、大数据流存储、轻量流计算等场景。客户需求旺盛、市场活跃，吸引了不少厂商加入角逐。

从好的角度来看，厂商的充分竞争，会进一步激活创新，培养更多用户，共同做大消息的市场，用户看起来也有更多的选择；

从坏的角度来看，未来部分竞争失利的消息队列会进入停滞期、下线期，用户的应用就会面临迁移大改造和稳定性风险，所以建议用户在满足自身业务需求的情况下，尽可能选择标准接口、协议的方式接入，或者直接使用业界事实标准的消息队列。

消息中间件未来的发展趋势是什么？

随着 IoT、5G 网络的持续发展，数据量增速 28%,预计到 2025 年物联网设备将达到 400 亿台，进入万物互联的时代。物联网时代的消息存储量和计算量会爆发式增长，消息系统将面临巨大的成本压力。未来消息系统，需要深挖新硬件的红利，比如持久内存、DPU 等技术，采用软硬结合的方式深度优化，将消息的存储计算成本进一步降低。

IoT 时代还有另外一个很重要的趋势是边缘计算，Gartner 预计到 2025 年，75%的数据将在传统数据中心或云环境之外进行处理,消息系统需要进一步轻量化、降低资源消耗以适应边缘计算环境。这也意味着，消息中间件的一体化架构，要具备良好的插件化设计，能够根据场景的特点实现多形态输出。比如公共云的形态可以和公共云的基础设施深度集成，充分利用云盘、对象存储增强存储能力，集成日志服务、应用监控等服务提升可观测能力；而边缘计算的形态则是以最小的资源代价输出核心存储、轻量计算的能力，简单够用即可。

近几年云计算高速发展，得益于全球范围内大量企业在进行数字化转型，通过业务在线化、业务数据化、数据智能化来提升企业竞争力。数据化转型也伴随着商业思维的转型，越来越多的企业采用“事件驱动”的模式来构建商业逻辑和数字化系统。

Gartner 预测，未来超过 60%的新型数字化商业的解决方案会采用“事件驱动”模式，从业务角度看，“事件驱动”的模式能够帮助企业实时响应客户，抓住更多的商业机会，创造增量价值；从技术角度看，“事件驱动”的架构，能够以动态、灵活、解耦的方式来链接跨组织、跨环境的异构系统，天然适合用于构建大型的跨组织数字化商业生态。

为了应对这个趋势，Messaing 往 Eventing 演进，出现了 EventBridge （EventBroker）的产品形态。在 EventBridge 里，“事件”这个概念成为一等公民，事件的发布者和订阅者不耦合任何一种具体的消息队列 SDK 和实现。EventBroker 围绕标准的 CloudEvent 规范构建更加泛化的发布订阅模式，能够链接一切跨组织、跨环境的异构事件源和事件处理目标。

目前以“事件驱动”构建的数字化商业生态才刚起步，未来 EventBridge 将围绕事件这一抽象层次实现更强大的能力，比如事件的全链路可观测、事件分析计算、低代码开发等特性，帮助企业全面落地云时代的“事件驱动”架构。

作者介绍：

​林清山（花名：隆基），阿里云资深技术专家，阿里云消息产品线负责人。国际消息领域专家，致力于消息、实时计算、事件驱动等方向的研究与探索，推进 RocketMQ 云原生架构、超融合架构的演进。​