共计 5599 个字符，预计需要花费 14 分钟才能阅读完成。
简介：只管消息中间件 RocketMQ 在阿里巴巴和开源社区曾经走过了十多个年头，但在云原生浩浩荡荡的浪潮下，咱们开始对 RocketMQ 的架构有了一些新的思考。本文咱们将对其开展具体的解说。
作者 | 林清山
起源 | 阿里开发者公众号
Apache RocketMQ 自 2012 年开源以来，因其架构简略、业务功能丰富、具备极强的可扩展性等特点被宽泛采纳。RocketMQ 在阿里巴巴团体外部有着数千台的集群规模，每天十万亿音讯流转的规模。在阿里云上，RocketMQ 的商业化产品也以弹性云服务的模式为寰球数万个用户提供企业级的音讯解决方案，被广泛应用于互联网、大数据、挪动互联网、物联网等畛域的业务场景，成为了业务开发的首选消息中间件。
只管消息中间件 RocketMQ 在阿里巴巴和开源社区曾经走过了十多个年头，但在云原生浩浩荡荡的浪潮下，咱们开始对 RocketMQ 的架构有了一些新的思考。
痛点与困局
阿里巴巴有大规模实际 RocketMQ 的生产教训，自 RocketMQ 从 2016 年对外商业化以来，始终连续跟团体消息中间件雷同的架构为云上的客户提供全托管的音讯服务，倒退至今，音讯队列 RocketMQ 在云上曾经具备相当大的业务规模。随着业务的倒退，这套极简的分布式架构在云原生环境下逐步透出了一些有余，比方，运维成本增加、效率升高。
团体消息中间件通过存储计算一体化的部署架构，为团体电商业务提供了高性能、低提早、低成本的音讯服务。随着云的进化，云开始变得更加弹性，网络环境更加简单，云原生时代对效率也有了更高的要求，咱们也迎来了对云上音讯架构进行云原生化革新的契机。
上图是目前 RocketMQ 在云上部署的一个简化版架构（仅蕴含最外围的组件），这套部署架构近年来在云上遇到的次要痛点有以下几点：
01 富客户端状态
RocketMQ 的用户须要借助官网提供的 SDK 应用云上的服务，这是一个比拟重量级的富客户端，提供了诸如程序生产、播送生产、消费者负载平衡、音讯缓存、音讯重试、位点治理、推拉联合、流控、诊断、故障转移、异样节点隔离等一系列企业级个性。RocketMQ 的富客户端极大地升高了团体内客户的接入老本，一站式助力团体客户构建高韧性、高性能的音讯驱动利用，但云上的富客户端有一些有余：
- 富客户端跟云原生的技术栈不匹配，比方很难跟 Service Mesh 联合，也跟 Dapr 这类新兴的云原生利用框架不兼容（？），消费者物理资源消耗比拟大，对 Serverless 弹性也不是很敌对；
- 多语言客户端对齐艰难，在云上对多语言的诉求是十分强烈的，但富客户端逻辑简单，团队无短缺的人力保障多语言客户端的品质，为此云上诞生了基于 GraalVM 和 HTTP 协定的多语言 SDK，但都有其局限性；
- 客户端不是齐全无状态，存在内存状态，重启的时候会触发重均衡，导致生产抖动、提早。这种重均衡的设计满足了性能上的需要，但对于敏感型业务，这些抖动能够说在过来几年奉献了很多的工单；
- 分区级别的生产粒度，客户端负载平衡的粒度在分区，一个分区无奈同时被多个消费者生产，在慢消费者场景影响十分大，无奈通过扩容分担慢消费者的压力。
02 计算存储一体化
Broker 是 RocketMQ 最外围的节点，承当了服务端所有的计算和存储逻辑，其外围能力为：
- 计算：鉴权与签名、商业化计量、资源管理、客户端连贯治理、消费者管控治理、客户端 RPC 解决、音讯编解码解决等。
- 存储：基于分区的 WAL 存储，多类型索引（一般、定时、事务等），外围的收、发、查问能力，多正本复制能力等。
计算存储一体化的 Broker 具备以下长处：部署构造简略、开源用户能够开箱即用；部署节点少，低成本反对团体双十一万亿级的音讯规模；数据就近解决，无中间环节，性能高，提早低。但一体化的 Broker 在云环境也有其局限性：
- 业务迭代效率低：公布单元为 Broker，即便调整了一行计量逻辑，须要全量公布数千台 Broker 节点能力全网失效，导致业务翻新和迭代的速度慢。
- 稳定性危险高：计算存储一体，但大多数业务需要都是针对计算逻辑，存储节点绝对稳固，频繁的低价值公布带来了稳定性危险和运维老本；每一次因计算逻辑的批改带来的公布将引起缓存重建、生产提早、客户端异样感知等问题。
- 资源利用率低：Broker 是磁盘 IO 和内存密集型利用，对计算资源的耗费绝对较低，但两者一体后扩缩容也是一体的，无奈将计算和存储节点独自做 Serverless 弹性，整体 Broker 集群资源利用率偏低。
- 管控链路简单：因为数据和状态齐全分布式存储在 Broker 上，管控节点须要与每个 Broker 进行通信，比方一个查问操作须要命中多个 Broker 并将后果进行聚合等，导致管控链路的逻辑简单。
03 客户端与 Broker 直连
RocketMQ 以后的用户通过客户端间接与 Broker 进行通信，链路是最短化的，运维简略、提早低，但这样的设计无奈很灵便地适配网络极其简单的云环境，网络上有经典网络、VPC 网络、公网，部署环境上有 OXS 区、售卖区，为客户裸露每一个 Broker 节点带来了运维上的累赘：
- Broker 对客户端不通明，客户端感知每个 Broker 节点，Broker 的运维动作在客户端往往有显著的感知；
- Broker 间接对外提供服务，须要为每个 Broker 申请 VIP，蕴含 Classic VIP、VPC VIP 甚至公网 IP，线上运维了数千个 VIP。每个 Broker 数个 VIP，运维代价高的同时，很长一段时间 VIP 的手动申请妨碍了 RocketMQ 的自动化部署。
- 无奈反对多接入点，Broker 通过 NameServer 裸露给用户，只能裸露一个接入点，用户个别只能在经典网络、VPC 网络以及公网接入点中三选一。
基于这个大背景，阿里云音讯团队对 RocketMQ 在云上进行了云原生架构降级专项，实际存储计算拆散的新架构，同时引入基于 gRPC 的全新多语言解决方案，来减速消息中间件的云原生化。
存算拆散新思路
如何在云上实际存算拆散，如何摸索出一个适宜 RocketMQ 三位一体的新架构，是 RocketMQ 进行云原生架构降级次要思考的点，这外面有很多事实因素的考量：
- RocketMQ 在阿里团体曾经充沛验证了其架构优良的特色，是否须要适配云的需要进行存算拆散？由此带来的提早、额定的老本是否能笼罩新架构带来的新价值？
- 阿里云上多款音讯产品曾经是存算拆散的架构状态，比方音讯队列 RabbitMQ、音讯服务 MNS，新的架构怎么与这些产品架构进行交融？
对于第一个问题，实际的后果曾经通知咱们架构简略的优异性，但在云上遇到的痛点又通知咱们存算拆散势在必行，可见存储与计算要不要拆散，并不是一个非此即彼的抉择，架构上的抉择是否能都要呢？对于这个问题，咱们的解法是存储计算须要做到可分可合：
- 「分」有两层解释，首先代表了模块和职责的明显，属于计算的逻辑应该关闭在计算模块，属于存储的逻辑应该下成到存储模块；第二层是计算和存储要反对离开部署，计算齐全采纳无状态的部署形式，存储是有状态的放式，来很好地解决在云上多租户场景面临的种种问题。
- 「合」的前提是从代码设计上要先离开，至于是离开部署还是合并部署齐全是业务的抉择，新的架构必须要反对合并的部署状态，满足吞吐型的业务场景。比方，阿里团体外部超大规模的音讯流场景；又比方小规模单租户场景，不须要服务化的场景，合并部署能够疾速将 RocketMQ 投产。
对于第二个问题，在阿里云上有多个自研的不同协定规范的音讯服务，如何通过繁多架构反对多产品状态至关重要，将 RocketMQ 的外围业务音讯的能力无缝复制到多个产品，放大业务价值。
总而言之，架构层面的核心理念是以存储计算架构拆散为切入点，进一步摸索繁多架构多产品状态，以升高音讯子产品的反复建设，最终也须要实现存储与计算可分可合的部署状态，同时满足云上的运维灵活性以及开源、团体等部署简略、高性能的需要。
01 存储计算拆散架构
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 非常适合存储计算拆散架构。
02 存储计算合并架构
但从实质来讲，存储计算拆散与就近计算和就近存储的理念是抵触的。存储计算一体化的架构在云上带来了困扰，实质还是因为云上是一个多租户的环境，存储计算一体化在多租户的场景下灵活性不够。但很多场景往往都是小规格单租户，其实更适宜存储计算一体化。
- 在开源场景，开源用户更加冀望 RocketMQ 是一款开箱即用、部署简略的消息中间件，存储计算拆散架构会带来肯定的复杂度，影响开源生态的建设。
- 在团体的场景，数千台物理机的规模，存储计算拆散将带来额定的机器老本。
- 在专有云场景，很多专有云可能节点数量无限，更偏向于采纳一体化的架构。
为了云外云内都能对立技术计划，咱们更加冀望的一种机构是存储与计算可分可合的部署状态，离开部署是计算节点齐全无状态，运维迭代极其简略，合并部署时更原架构体验保持一致。
但无论采纳什么样的部署架构，存储和计算的拆散都是一种良好的模块化设计形式，在编程层面的离开是必须要进行的。
如上图所示，右边是云上一个拆散部署的状态，左边是合并部署的状态，合并部署时计算节点能够作为存储节点的 SideCar，采纳网格的思维进行部署，也能够将计算和存储揉进同一个过程进行部署。实际上，咱们在实际的过程中，通过对代码进行充沛设计，Proxy 节点能够通过结构器结构出「Local」和「Cluster」部署两种状态，别离对应合并部署和拆散部署的两种架构状态。
03 繁多架构多产品状态
《云原生时代消息中间件的演进路线》一文中提到，阿里云音讯团队目前有业界最丰盛的音讯产品矩阵，包含音讯队列 RocketMQ、音讯队列 Kafka、微音讯队列 MQTT、音讯队列 AMQP、音讯服务 MNS、事件总线 EventBridge。丰盛的产品矩阵是团队多年来践行多样性和标准化演进路线的后果，所有的音讯子产品目前都构建在 RocketMQ 存储内核之上，十分具备对立架构的前提。
通过繁多的存储计算拆散架构，反对多产品的业务状态，是云原生音讯摸索的一个重要方向。这种繁多架构多产品状态会带来诸多益处，比方计算节点共建，通过模型形象反对多业务模型，多通信协议，开释反复建设的人力。通过存储节点并池，各产品买通外部存储节点，造成资源池合并，对立运维和管控，有助于降低成本、提高效率，减速存储翻新，孵化音讯中台。
如上图所示，繁多架构多产品状态的外围先对立存储和计算，并进一步对立管控和运维，真正做到一套架构撑持多个云产品。
- 存储集群足够形象，满足通用的音讯存取需要。
- 计算集群多合一，足够的模块化，可插拔，满足多产品部署带来不同权限体系、不同协定、不同形象模型等的需要。
总结
目前，阿里云音讯队列 RocketMQ 实际存储计算彻底拆散的架构还处于第一个过渡阶段，将来的路还很长，咱们会投入至多 1 年的工夫在私有云环境全面落地存储计算拆散架构，让音讯服务更弹性、更云原生，让团队提高效率，减速业务翻新。咱们冀望新的架构能稳固服务于将来至多 5 年的业务增长，同时，存算可分可合的部署架构也可能十分好地撑持不同规模开源用户的个性化需要，让 Apache RocketMQ 开源社区可能整体收益于存算计算可分可合架构的新形态。
原文链接
本文为阿里云原创内容，未经容许不得转载。
