标签：5.0 存储 架构 部署 新思路 计算 云上 RocketMQ

作者：林清山

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

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

痛点与困局

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

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

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

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

• 计算存储一体化，计算存储一体化的 Broker 具备部署结构简单，开源用户可以做的开箱即用；部署节点少，低成本支持集团双十一万亿级的消息规模；数据就近处理，无中间环节，性能高，延迟低。但在云上复杂网络情况下，会带来较多额外的运维工作，难以满足云用户多样性的网络诉求，比如 SingleTunel、AnyTunnel、PrivateLink、公网等。

基于这个大背景，阿里云消息团队对 RocketMQ 在云上进行了云原生架构升级专项，实践存储计算分离的新架构，同时引入基于 gRPC 的全新多语言解决方案（阅读《全面升级 —— Apache RocketMQ 5.0 SDK 的新面貌》了解更多详情），来加速消息中间件的云原生化。

存算分离新思路

如何在云上实践存算分离，如何探索出一个适合 RocketMQ 三位一体的新架构，是 RocketMQ 进行云原生架构升级主要考虑的点，这里面有很多现实因素的考量：

• RocketMQ 在集团已经充分验证了其架构优秀的特征，是否需要适配云的需求进行存算分离？由此带来的延迟、额外的成本是否能覆盖新架构带来的新价值。

• 阿里云上多款消息产品已经是存算分离的架构形态，比如消息队列 RabbitMQ，消息服务 MNS，新的架构怎么与这些产品架构进行融合，又有哪些差一点？

对于第一个问题，实践的结果已经告诉我们架构简单的优异性，但在云上遇到的痛点又告诉我们存算分离势在必行，可见存储与计算要不要分离，并不是一个非此即彼的选择，架构上的选择是否能都要呢？对于这个问题，我们的解法是存储计算需要能做到可分可合：

• 「分」有两层解释，首先代表了模块和职责的分明，属于计算的逻辑应该封闭在计算模块，属于存储的逻辑应该下成到存储模块；第二层是计算和存储要支持分开部署，计算完全采用无状态的部署方式，存储是有状态的放式，来很好的解决在云上多租户场景面临的种种问题。

• 「合」的前提是从代码设计上要先分开，至于是分开部署还是合并部署完全是业务的选择，新的架构必须要支持合并的部署形态，满足吞吐型的业务场景，比如阿里集团内部超大规模的消息流场景。又比如小规模单租户场景，不需要服务化的场景，合并部署可以快速将 RocketMQ 投产。

对于第二个问题，在阿里云上，有多个阿里云自研的不同协议标准的消息服务，如何通过单一架构支持多产品形态至关重要，将 RocketMQ 的核心业务消息的能力无缝复制到多个产品，放大业务价值。

总而言之，架构层面的核心理念是以存储计算架构分离为切入点，进一步探索单一架构多产品形态，以降低消息子产品的重复建设，最终也需要实现存储与计算可分可合的部署形态，同时满足云上的运维灵活性以及开源、集团等部署简单、高性能的需求。

存储计算分离架构

RocketMQ 5.0 在架构上的第一个升级便是存储计算分离改造，通过引入无状态的 Proxy 集群来承担计算职责，原 Broker 节点会逐步演化为以存储为核心的有状态集群，同时会重新研发一批多语言的瘦客户端来解决富客户端带来的诸多问题。

上图是一个存储计算分离架构的简图，图中借用了 Service Mesh 关于控制和数据面的划分思想以及 xDS 的概念来描述，架构中各个组件的职责分别为：

• 多语言瘦客户端，基于 gRPC 协议重新打造的一批多语言客户端，采取 gRPC 的主要考虑其在云原生时代的标准性、兼容性以及多语言传输层代码的生成能力。

• 导航服务（Navigation Server），通过 LB Group 暴露给客户端，客户端通过导航服务获取数据面的接入点信息（Endpoint），随后通过计算集群 Proxy 的 LB Group 进行消息的收发。通过 EDS 来暴露 Proxy 的接入点信息与通过 DNS 解析的负载均衡进行路由相比而言，可以作出更智能与更精细的租户及流量控制、负载均衡决策等。

• NameServer，RocketMQ 中原有的核心组件，主要提供用于存储的 Broker 集群发现（CDS），存储单元 Topic 的路由发现（RDS）等，为运维控制台组件、用户控制台组件、计算集群 Proxy 提供 xDS 服务。

• Proxy，重新研发的无状态计算集群，数据流量的入口，提供鉴权与签名、商业化计量、资源管理、客户端连接管理、消费者管控治理、客户端 RPC 处理、消息编解码处理、流量控制、多协议支持等。

• Broker，原 Broker 模块的存储部分独立为新的存储节点，专注提供极具竞争力的高性能、低延迟的存储服务，存储计算分离后也更易加速存储能力的创新。原 Broker 模块的计算部分逐渐上移到 Proxy 集群当中。

• LB Group，根据用户的需求提供 Classic VIP，VPC VIP，Internet VIP，Single Tunnel，PrivateLink 等多样化的接入能力。

虽然存储计算分离带来的额外的成本，主要是延迟和成本：

• 关于延迟，存储和计算节点从本地方法调用转换为远程调用后，无可避免地增加了延迟，一般是毫秒级别，在阿里云上及时是跨 AZ 的网络通信，延迟一般在 2ms 以内，这种量级的延迟增加，对大多数业务来讲是完全可以接受的。

• 关于成本，存算的分开，导致网络传输层面，序列化和反序列化层面不可避免需要更多的 CPU 资源。但另一方面，存储和计算一个属于磁盘 IO、内存密集型，一个是 CPU 密集型，拆开后可以更好的设计规格，更好的利用碎片化资源，更容易提高资源利用率，利用云的弹性能力，成本反而可以降低。

简而言之，在云上环境，云服务形态的 RocketMQ 非常适合存储计算分离架构。

存储计算合并架构

但从本质来讲，存储计算分离，与就近计算和就近存储的理念是冲突的。存储计算一体化的架构固然在云上为我们带来了极大的困扰。这里面的本质还是因为云上是一个多租户的环境，存储计算一体化在多租户的场景下灵活性是不够的，但很多场景往往都是小规格单租户，其实更适合存储计算一体化。

• 在开源场景，开源用户更加期望 RocketMQ 是一款开箱即用，部署简单的消息中间件，存储计算分离架构会带来一定的复杂度，影响开源生态的建设。

• 在集团的场景，数千台物理机的规模，存储计算分离将带来额外的机器成本。

• 在专有云场景，很多专有云可能节点数量有限，更倾向于采用一体化的架构。

为了云外云内都能统一技术方案，我们更加期望的一种机构是存储与计算可分可合的部署形态，分开部署是计算节点完全无状态，运维迭代极其简单，合并部署时更原架构体验保持一致。

但无论采用什么样的部署架构，存储和计算的分离是一种良好的模块化设计方式，在编程层面的分开是必须要进行的。

如上图所示，左边是云上一个分离部署的形态，右边是合并部署的形态，合并部署是计算节点可以作为存储节点的 SideCar，采用网格的思想进行部署，也可以将计算和存储揉进同一个进程进行部署，实际上，我们在实践的过程中，通过对代码充分的进行设计，Proxy 节点可以通过构造器构造出「Local」和「Cluster」部署的两种形态，分别对应合并部署和分离部署的两种架构形态。

单一架构多产品形态

在《云原生时代消息中间件的演进路线》一文中提到阿里云消息团队目前有业界最丰富的消息产品矩阵，包括消息队列 RocketMQ、消息队列 Kafka、微消息队列 MQTT、消息队列 AMQP、消息服务 MNS、事件总线 EventBridge。丰富的产品矩阵是团队多年来践行多样性和标准化演进路线的结果，所有的消息子产品目前都构建在 RocketMQ 存储内核之上，非常具备统一架构的前提。

通过单一的存储计算分离架构，支持多产品的业务形态，是云原生消息探索的一个重要方向，这种单一架构多产品形态会带来诸多好处，比如计算节点共建，通过模型抽象支持多业务模型，多通信协议，释放重复建设的人力。通过存储节点并池，各产品打通内部存储节点，形成资源池合并，统一运维和管控，有助于降低成本、提高效率，加速存储创新，孵化消息中台。

如上图所示，单一架构多产品形态的核心先统一存储和计算，并进一步统一管控和运维，真正做到一套架构支撑多个云产品：

• 存储集群足够抽象，满足通用的消息存取需求。

• 计算集群多合一，足够的模块化，可插拔，满足多产品部署带来不同权限体系、不同协议、不同抽象模型等的需求。

总结

目前阿里云消息队列 RocketMQ 实践存储计算彻底分离的架构还处于第一个过渡阶段，未来的路还很长，我们会投入至少 1 年的时间在公有云环境全面落地存储计算分离的架构，让消息服务更弹性、更云原生，让团队提高效率，加速业务创新。我们期望新的架构能稳定服务于未来至少 5 年的业务增长，同时，存算可分可合的部署架构也能过非常好的支撑开源不同规模用户的个性化需求，让 Apache RocketMQ 开源社区能过整体收益于存算计算可分可合架构的新形态。

标签：5.0,存储,架构,部署,新思路,计算,云上,RocketMQ
来源： https://www.cnblogs.com/aliware/p/16322735.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。