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

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

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

痛点与困局

阿里巴巴有大规模实践 RocketMQ 生产经验，迄今为止，集团稳定运行着数百个 RocketMQ 集群，数千个节点，自 RocketMQ 从 2016 年对外商业化以来，一直延续跟集团消息中间件相同的架构为云上的客户提供全托管的消息服务，从 16 年发展至今，消息队列 RocketMQ 在云上已经具备相当大的业务规模，大规模的场景下，这套极简的分布式架构在云原生环境下逐渐显露出来了一些弊端，云计算复杂的网络环境，数万企业客户的多租场景，为 RocketMQ 的商业化产品带来的不少的挑战。

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

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

• 富客户端形态，RocketMQ 的富客户端包含大量的企业级特性，富客户端意味着逻辑复杂，容易出 Bug，依赖客户经常性更新到最新 Release 来保持客户端和服务端良好的兼容性。在单个组织内往往没有任何问题，阿里集团内部通过潘多拉等容器也可以自动为用户升级，但云产品的用户多样性强，升级的驱动力也不足，导致线上存在大量的旧版本客户端，带来稳定性风险。
• 计算存储一体化，计算存储一体化的 Broker 具备部署结构简单，开源用户可以做的开箱即用；部署节