RocketMQ 5.0: 存储计算分离新思路

Apache RocketMQ 自 2012 年开源以来，因其架构简单、业务功能丰富、具备极强的可扩展性等特点被广泛采用。RocketMQ 在阿里巴巴集团内部有着数千台的集群规模，每天十万亿消息流转的规模。在阿里云上，RocketMQ 的商业化产品也以弹性云服务的形式为全球数万个用户提供企业级的消息解决方案，被广泛应用于互联网、大数据、移动互联网、物联网等领域的业务场景，成为了业务开发的首选消息中间件。

尽管消息中间件 RocketMQ 在阿里巴巴和开源社区已经走过了十多个年头，但在云原生浩浩荡荡的浪潮下，我们开始对 RocketMQ 的架构有了一些新的思考。

痛点与困局

阿里巴巴有大规模实践 RocketMQ 的生产经验，自 RocketMQ 从 2016 年对外商业化以来，一直延续跟集团消息中间件相同的架构为云上的客户提供全托管的消息服务，发展至今，消息队列 RocketMQ 在云上已经具备相当大的业务规模。随着业务的发展，这套极简的分布式架构在云原生环境下逐渐显露出了一些不足，比如，运维成本增加、效率降低。

集团消息中间件通过存储计算一体化的部署架构，为集团电商业务提供了高性能、低延迟、低成本的消息服务。随着云的进化，云开始变得更加弹性，网络环境更加复杂，云原生时代对效率也有了更高的要求，我们也迎来了对云上消息架构进行云原生化改造的契机。

上图是目前RocketMQ在云上部署的一个简化版架构（仅包含最核心的组件），这套部署架构近年来在云上遇到的主要痛点有以下几点：

01 富客户端形态

RocketMQ 的用户需要借助官方提供的 SDK 使用云上的服务，这是一个比较重量级的富客户端，提供了诸如顺序消费、广播消费、消费者负载均衡、消息缓存、消息重试、位点管理、推拉结合、流控、诊断、故障转移、异常节点隔离等一系列企业级特性。RocketMQ 的富客户端极大地降低了集团内客户的接入成本，一站式助力集团客户构建高韧性、高性能的消息驱动应用，但云上的富客户端有一些不足：

• 富客户端跟云原生的技术栈不匹配，比如很难跟 Service Mesh 结合，也跟 Dapr 这类新兴的云原生应用框架不兼容（？），消费者物理资源耗费比较大，对 Serverless 弹性也不是很友好；
• 多语言客户端对齐困难，在云上对多语言的诉求是非常强烈的，但富客户端逻辑复杂，团队无充足的人力保障多语言客户端的质量，为此云上诞生了基于 GraalVM 和 HTTP 协议的多语言 SDK，但都有其局限性；
• 客户端不是完全无状态，存在内存状态，重启的时候会触发重平衡，导致消费抖动、延迟。这种重平衡的设计满足了性能上的需求，但对于敏感型业务，这些抖动可以说在过去几年贡献了很多的工单；
• 分区级别的消费粒度，客户端负载均衡的粒度在分区，一个分区无法同时被多个消费者消费，在慢消费者场景影响非常大，无法通过扩容分