共计 4540 个字符，预计需要花费 12 分钟才能阅读完成。
简介：在阿里云上，RocketMQ 的商业化产品也以弹性云服务的模式为寰球数万个用户提供企业级的音讯解决方案，被广泛应用于互联网、大数据、挪动互联网、物联网等畛域的业务场景，成为了业务开发的首选消息中间件。
Apache RocketMQ 自 2012 年开源以来，因其架构简略，业务功能丰富，具备极强的可扩展性等特点被宽泛采纳。RocketMQ 在阿里巴巴团体外部有着数千台的集群规模，每天十万亿音讯的规模。在阿里云上，RocketMQ 的商业化产品也以弹性云服务的模式为寰球数万个用户提供企业级的音讯解决方案，被广泛应用于互联网、大数据、挪动互联网、物联网等畛域的业务场景，成为了业务开发的首选消息中间件。
只管消息中间件 RocketMQ 在阿里巴巴和开源社区曾经走过了十多个年头，但在云原生浩浩荡荡的浪潮下（《云原生时代消息中间件的演进路线》），咱们开始对 RocketMQ 的架构有了一些新的思考。
痛点与困局
阿里巴巴有大规模实际 RocketMQ 生产教训，迄今为止，团体稳固运行着数百个 RocketMQ 集群，数千个节点，自 RocketMQ 从 2016 年对外商业化以来，始终连续跟团体消息中间件雷同的架构为云上的客户提供全托管的音讯服务，从 16 年倒退至今，音讯队列 RocketMQ 在云上曾经具备相当大的业务规模，大规模的场景下，这套极简的分布式架构在云原生环境下逐步显露出来了一些弊病，云计算简单的网络环境，数万企业客户的多租场景，为 RocketMQ 的商业化产品带来的不少的挑战。
1.png
image.gif
团体消息中间件通过存储计算一体化的部署架构，为团体电商业务提供了高性能、低提早、低成本的音讯服务。随着云的进化，云开始变得更加弹性，网络环境更加简单，云原生时代对效率也有了更高的要求，咱们也迎来了对云上音讯架构进行云原生化革新的契机。
如上图所示，是目前 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 节点会逐渐演变为以存储为外围的有状态集群，同时会从新研发一批多语言的瘦客户端来解决富客户端带来的诸多问题。
2.png
上图是一个存储计算拆散架构的简图，图中借用了 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 是一款开箱即用，部署简略的消息中间件，存储计算拆散架构会带来肯定的复杂度，影响开源生态的建设。
在团体的场景，数千台物理机的规模，存储计算拆散将带来额定的机器老本。
在专有云场景，很多专有云可能节点数量无限，更偏向于采纳一体化的架构。
为了云外云内都能对立技术计划，咱们更加冀望的一种机构是存储与计算可分可合的部署状态，离开部署是计算节点齐全无状态，运维迭代极其简略，合并部署时更原架构体验保持一致。
但无论采纳什么样的部署架构，存储和计算的拆散是一种良好的模块化设计形式，在编程层面的离开是必须要进行的。
image.gif
3.png
如上图所示，右边是云上一个拆散部署的状态，左边是合并部署的状态，合并部署是计算节点能够作为存储节点的 SideCar，采纳网格的思维进行部署，也能够将计算和存储揉进同一个过程进行部署，实际上，咱们在实际的过程中，通过对代码充沛的进行设计，Proxy 节点能够通过结构器结构出「Local」和「Cluster」部署的两种状态，别离对应合并部署和拆散部署的两种架构状态。
繁多架构多产品状态
在《云原生时代消息中间件的演进路线》一文中提到阿里云音讯团队目前有业界最丰盛的音讯产品矩阵，包含音讯队列 RocketMQ、音讯队列 Kafka、微音讯队列 MQTT、音讯队列 AMQP、音讯服务 MNS、事件总线 EventBridge。丰盛的产品矩阵是团队多年来践行多样性和标准化演进路线的后果，所有的音讯子产品目前都构建在 RocketMQ 存储内核之上，十分具备对立架构的前提。
4.png
通过繁多的存储计算拆散架构，反对多产品的业务状态，是云原生音讯摸索的一个重要方向，这种繁多架构多产品状态会带来诸多益处，比方计算节点共建，通过模型形象反对多业务模型，多通信协议，开释反复建设的人力。通过存储节点并池，各产品买通外部存储节点，造成资源池合并，对立运维和管控，有助于降低成本、提高效率，减速存储翻新，孵化音讯中台。
5.png
如上图所示，繁多架构多产品状态的外围先对立存储和计算，并进一步对立管控和运维，真正做到一套架构撑持多个云产品：
存储集群足够形象，满足通用的音讯存取需要。
计算集群多合一，足够的模块化，可插拔，满足多产品部署带来不同权限体系、不同协定、不同形象模型等的需要。
总结
目前阿里云音讯队列 RocketMQ 实际存储计算彻底拆散的架构还处于第一个过渡阶段，将来的路还很长，咱们会投入至多 1 年的工夫在私有云环境全面落地存储计算拆散的架构，让音讯服务更弹性、更云原生，让团队提高效率，减速业务翻新。咱们冀望新的架构能稳固服务于将来至多 5 年的业务增长，同时，存算可分可合的部署架构也能过十分好的撑持开源不同规模用户的个性化需要，让 Apache RocketMQ 开源社区能过整体收益于存算计算可分可合架构的新形态。
