简介： 在阿里云上，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 开源社区能过整体收益于存算核算可分可合架构的新形状。
