十问 RocketMQ：十年再出发，到底有何不同？

布景

作为一种实时数据的处理渠道，音讯体系的开展跟事务架构的变迁一向休戚相关，那么咱们可以透过事务架构的改变来看音讯体系的开展进程和未来趋势。经过十多年的开展，RocketMQ 逐步成为了一个音讯、事情和流一体的超交融处理渠道。

在音讯范畴，全面拥抱云原生技能，弹性弹性，开箱即用。在事情范畴，产品形状全面晋级，拥抱职业规范，让事情驱动架构无处不在，从单一事务的数字化体系，扩展到跨事务、跨安排的数字化商业生态。事情驱动架构一同也让云核算、云原生的技能可以更大规划的落地，进步云产品和用户事务的集成度，让 Serverless 技能被更大规划的选用，为客户降本增效。在流范畴，流存储增强批量特性，大幅度进步数据吞吐量；新增逻辑行列才能，解耦逻辑资源和物理资源，在流场景也具有无缝弹性才能；新增轻量流处理引擎，供给实时事情流处理、流剖析才能。

云原生年代，RocketMQ 全新晋级背面的原因是什么？咱们选取了十大问题，抛给阿里云 RocketMQ 团队，听听他们关于产品开展与决议计划的考虑。

十问 RocketMQ

音讯中间件有着近 30 年的职业前史，其在事务开发过程中扮演的人物发生过哪些改变？

音讯行列归于最经典的中间件之一，现已有 30 多年的前史，其开展进程可以总结为几个阶段：

• 第一阶段，2000 年之前。这个阶段的音讯行列供应商是几家商业软件巨头，比方 IBM、Oracle、Microsoft 都有自己的商业化 MQ，其间最具代表性的是 IBM MQ，价格昂贵，面向高端企业，首要是大型金融、电信等企业；这类商业 MQ 一般选用高端硬件，软硬件一体机交付，MQ 本身的软件架构是单机架构。

• 第二阶段，2000~2007 年。进入 00 年代后，初代开源音讯行列崛起，诞生了 JMS、AMQP 两大规范，与之对应的两个完成分别为 ActiveMQ、RabbitMQ，他们引领了初期的开源音讯行列技能。开源极大的促进了音讯行列的流行、降低了运用门槛，技能普惠化，逐步成为了企业级架构的标配。

• 第三阶段，2007~2017 年。PC 互联网、移动互联网爆发式开展。由于传统的音讯行列无法接受亿级用户的拜访流量和海量数据传输，诞生了互联网音讯中间件，中心才能是全面选用分布式架构、具有很强的横向扩展才能，开源典型代表有 Kafka、RocketMQ，闭源的还有淘宝 Notify。

在前两个阶段，音讯中间件在事务开发过程中，单纯地扮演着「异步解耦」的人物，归于软件架构的一种范式，事务经过引进音讯中间件来处理同步架构带来的耦合问题。进入到第三个阶段后，互联网的海浪数据是前两个阶段无法想象的，关于事务来讲单纯的异步解耦远远不够的，在互联网的流量下，音讯行列的顾客会容易被打垮，这个时候事务对音讯中间件的需求多了「堆积和削峰」，RocketMQ 便是在这个布景下诞生的，经过 RocketMQ 对流量进行削峰，让事务有时机经过平稳的流量处理海量的堆积数据，这项技能是支撑淘宝天猫每年双十一的利器。

进入互联网年代以来，音讯行列跟互联网事务相得益彰，阅历了快速开展的阶段，音讯行列在事务开发过程中也逐步从「架构层面」深入到「事务层面」。在这期间，RocketMQ 做了许多事务上的立异来满意事务的快速迭代需求，这其间最典型的便是 RocketMQ 在支撑阿里集团和阿里云用户过程中孵化出来的 「全类型事务音讯」，这些音讯可以说承担了相当于一部分的事务逻辑。

全类型的事务音讯固然大大进步了互联网事务的迭代速度，但互联网的规划对音讯行列的应战远不止于此，互联网事务对音讯行列的音讯处理和服务才能都有极高的要求，RocketMQ 为服务互联网事务诞生了许多抢先的音讯处理才能，比方阿里的交易音讯（Notify），订阅比到达了 1：300，但是投递比只要 15：300，SQL 过滤的才能便是用来处理这种高订阅比、低投递比的事务场景的。除此之外，RocketMQ 供给了许多的音讯管理才能，包括音讯回放、音讯重试、死信音讯等。

RocketMQ 将音讯的管理才能在容灾方面发挥到了极致，咱们都知道互联网事务对可用性有着极高的追求，阿里内部的数据库和中间件在各个商业化版别里边都供给了容灾才能，来满意互联网用户关于容灾高可用需求。

RocketMQ 立异性地经过组合流量管控和数据复制「全球音讯路由」方面的技能沉积供给了多活和灾备的处理方案。

总结下来，音讯行列在开展的过程傍边，从最初的协助事务进行「异步解耦」，到互联网年代的堆积和削峰，再到后来从架构层面深入到事务层面，经过不同的事务音讯来沉积通用的开发范式，到最后经过抢先的音讯管理和服务才能，来满意互联网事务对事务管控和多活容灾等方面的需求。可以说 RocketMQ 开展至今现已深入到了事务的架构、开发范式、运维管控、可观测性、容灾架构等方方面面。

在音讯中间件的开展前史傍边，事务开发架构有过哪些晋级，音讯体系又是怎样去适配这些改变的？

音讯的开展跟事务架构的变迁是休戚相关的，事务最开端选用的架构是「单体架构」，其开发、运维和迭代都十分简略，但受限于其扩展才能，事务很快便向「分布式架构」演进，早在 2008 年淘宝和天猫发起一次最大规划的架构晋级，启动了“五彩石”项目，把单体运用拆分成分布式运用，一同笼统淘宝、天猫的共同底座-事务中台，包括交易中心、产品中心、买家中心等。在事务中台之下，一同诞生了阿里中间件（初期三大件包括音讯、RPC、分布式数据层），RocketMQ 是其间之一。

可以说，RocketMQ 诞生于「分布式架构」阶段，在这个阶段，事务对「分布式」并没有到达共同，各个公司对单体运用的拆分方法也是形形色色的，有笔直拆分，有水平分层，有按组件拆分，也有按服务拆分，但终究微服务架构逐步成为了业界干流。但不论事务怎样去落地分布式架构，音讯体系在里边总是以「分布式通讯」的原子才能去适配这些改变的，无论分布式运用是怎样安排事务架构的，音讯体系在这个阶段总是作为「分布式运用的通讯根底设备」来助力事务架构的快速变迁，终究演进到较为理想的微服务架构。

近些年，运用的拆分粒度从「微服务」有逐步向「单个函数」演进的趋势，运用呈现出所谓的 Serverless 架构，经过函数构建的运用粒度更细，每个函数往往是单个操作，函数的编列和驱动面对着十分大的应战。音讯体系作为通道除了发挥「通讯设备」效果，在函数核算场景，会进一步承担「集成与被集成」的人物，协助函数核算编列函数，集成各类事情源，成为函数核算的驱动力。

从业界技能流行趋势来看，微服务当下仍是干流，且 Service Mesh、Dapr、Knative 等新式的技能结构让微服务的形状呈现了多样化，RocketMQ 在更好地支撑微服务架构方向上有哪些演进？

微服务架构开展至今，特别是服务网格的思维兴起后，微服务形状呈现出多样化，不论是 Dapr 仍是 Knative，这些新式的技能结构首要遵从两个关键思维：

• 将分布式的根底才能进行下沉，比方植入到 Sidecar 傍边，这些分布式的根底才能包括服务发现、负载均衡、远程调用、发布订阅（音讯中间件）。

• 对分布式才能进行笼统，新的微服务架构界说了笼统的 API，用于屏蔽分布式才能的具体完成，比方 Dapr 在其 DaprClient 中就对音讯的 Pub/Sub 进行了全新的 API 界说；Knative 也根据 Kubernetes 的可扩展 API 界说了 Subscription 概念。

简而言之，新式的微服务技能结构会将分布式运用需求的根底才能进行笼统和封装，并进一步植入到 Sidecar 或许自界说的 Runtime 傍边。音讯中间件作为分布式运用根底的通讯才能，为了适配这些技能结构，需求加强本身的「被集成」才能，RocketMQ 5.0 在这方面有两块技能演进。

首先是轻量级 SDK，RocketMQ 5.0 推出了根据 gRPC 全新的多语言 SDK，这套 SDK 有几个重要特色：

• 选用全新极简的 API，拥有不可变 API 的规划，完善的错误处理，各语言 SDK API 在本地语言层面对齐，新的 API 化繁为简，更易被运用和集成。

• 选用云原生的 RPC 规范结构 gRPC，规范的传输层结构，更易被阻拦，特别适合被 Service Mesh 集成然后赋予其更多的传输层根底才能。

• 客户端轻量化，以典型的「SimpleConsumer」为代表，选用全新的面向音讯的无状况消费模型，整个 SDK 从代码到运行时都极为轻量。轻量化是一种十分重要才能，如果各个中间件都采用富客户端的方法，这些中间件当被一同植入到 Sidecar 中时，也会是一个十分庞大的 Sidecar，运用结构集成的杂乱度十分高。

另一块便是无状况的消费模型，RocketMQ 5.0 引进了 Pop 机制，立异性地在行列模型之上支撑了无状况的音讯模型，在一个主体上一同支撑两种消费模型，表现了音讯和流的「二象性」，面向流场景选用高功能的行列模型进行消费，面向音讯的场景，选用无状况的音讯模型进行消费，事务可以只关怀音讯本身，经过「SimpleConsumer」供给单条音讯等级的消费、重试、修正不可见时间、以及删去等 API 才能。

总结下来，RocketMQ 5.0 在面对多样化的微服务生态时，经过强化本身被集成的才能，来更好的支撑微服务技能架构的立异和演进。

近两年，包括中间件、数据库等各类云产品都声称完成了云原生晋级，站在云厂商的视角，事务运用应该怎样进行云原生晋级？

业界关于云原生的界说也是议论纷纷，关于软件来讲，咱们以为「生于云，善于云」，经过云的根底设备来构建本身的软件可以称之为云原生软件。从这个视点来看，RocketMQ 作为业界第一个供给公有云服务的开源音讯行列可以说是最云原生的音讯行列。RocketMQ 5.0 全面走向多样化、规范化一级云原生化，一同在 IoT、边缘核算、事情驱动等新趋势都有相应的布局和落地完成。

RocketMQ 自上云以来，一向依靠阿里云的根底设备强化产品的竞争力，充沛地使用云的弹性才能，撬动云的核算、存储和网络的池化资源，以支撑事务完成云原生的改造。RocketMQ 5.0 商业版在核算、存储、和网络三个方面都有重大的云原生改造晋级：

• 在核算层面，RocketMQ 5.0 经过 ACK 充沛使用 ECS 弹性才能，采用弹性资源池 + HPA 相关技能支撑核算才能快速弹性，一同 ACK 自带的跨可用区布置才能为云产品供给了足够的高可用保证。

• 在网络层面，RocketMQ 接入了阿里云的多种网络才能，满意用户对多样性网络的需求，公网随开随用，支撑多种私网网络形状，根据 CEN 构建了全球互通的音讯网络。

• 在存储方面，经过推出多级存储产品化的才能，充沛使用 OSS 存储的弹性才能，存储计费走向按量付费，一同支撑冷热数据分离，为用户供给共同的冷读 SLA。

从 RocketMQ 本身的阅历来看，云产品的云原生化的目标是充沛使用云的根底设备才能，使用云的弹性才能，完成云原生技能的普惠，可以说根据云产品构建的运用便是云原生化的运用，经过对运用进行云原生化的改造，任何一个企业用户背面都有着阿里云超大规划资源池的支撑，能满意事务爆发式增长的需求。

完成云原生晋级的运用构成成分愈加杂乱，以前多个微服务 + 数据库可能就组合成了一个运用，核算在微服务，存储在数据库。但云原生化后，核算的形状有许多种，比方可能隐藏在一个 API 网关后边，或许是一个函数核算的形状，又或许是一个容器服务的 Job。数据也散落存储在各个地方，中间件、数据库、大数据、目标存储等各个范畴都供给了数据的存储与拜访才能。显而易见的是，云原生化的运用虽然可以充沛撬动云的才能，但对研制团队来讲，整个运用生命周期的各个环节的都需求有新的工具和流程来进行规范化出产。

云原生的运用架构看起来愈加碎片化，是否违背了开发结构应当尽最大可能让用户专心事务逻辑的初衷？

恰恰相反！ 云原生的运用架构，更容易让开发者专心本身的事务逻辑。咱们将构建一个分布式运用的杂乱度分为「实质杂乱度」和「次要杂乱度」，在没有云原生之前，次要杂乱度占了一个分布式运用的很大比例，开发者需求关怀：

• 运用本身需求多少 Server 进行布置，弹性和本钱怎样取舍？Server 宕机后怎样处理？
• 各个组件运行时状况怎样搜集和查询？可观测性目标怎样建立？
• 依靠的软件，比方中间件和数据库，怎样进行布置，安稳性怎样保证？容量评估怎样做？
• 存储的数据怎样规划生命周期？怎样进行归档？
• …

云原生的运用，经过引进音讯行列、函数核算、云原生数据库、目标存储等云原生的服务，可以很大程度上卸载这些次要杂乱度，开发者真正有时机做到很朴实地专心本身的事务逻辑。

但云原生的运用由于依靠了许多云产品，不可避免构成的成分杂乱了许多，所以音讯行列在其间起到的**「通道」和「粘合」**的效果就至关重要了。

如上图所示，一个云原生的运用不可避免地需求运用音讯行列来作为分布式组件之间的异步通讯中间件，比方衔接不同的微服务。一同，由于引进了许多云上的存储和核算资源，这些资源要发挥核算的力量需求被驱动起来，阿里云给的处理方案是经过事情驱动引擎「EventBridge」作为云原生核算的驱动力，一同作为衔接型产品经过衔接各个云产品，便利用户更好地用云。

云原生的确给事情驱动架构带来了更多的关键，事情驱动是一个来源很早的概念。其实 RocketMQ 的 PushConsumer 供给的 API 其实便是一种事情驱动的编程范式，但在微服务运用架构傍边，集成与通讯才是刚需，事情驱动的价值并没有那么显着。

在云原生年代，核算力的构成越来越多样化，经过事情驱动架构来开发云原生运用是一件十分水到渠成的事情。阿里云大概在两年前就上线了全新的事情驱动型产品：事情总线 EventBridge。现在该产品作为 RocketMQ 5.0 的重要组成部分现已完成了开源。

阿里云打造全新的云产品 EventBridge 首要是为了兑现三大事务价值：

• 一致事情纽带。阿里云的云产品，从 IaaS 到 PaaS，每天都有数以亿计的事情发生，但却没有一种简略和一致的方法来触达这些事情；这线事情也十分独立，无法形成规划效应，很难挖掘出有用的事务价值，只要充沛发挥数据的规划效应，建立起数据的血缘关系，咱们才能更好的发掘出数据的价值；所以 EventBridge 要处理的第一个问题便是一致阿里云上的事情规范，作为中心化的纽带为云用户供给一站式的事情中心。

• 事情驱动引擎。当 EventBridge 具有了海量的事情源后，合作根据 RocketMQ 开发的事情驱动引擎，经过毫秒级的触发才能，加快企业进行 EDA/Serverless 的架构晋级。

• 敞开与集成。以事情的方法来 「Connect Everything」是一种愈加松耦合的架构，EventBridge 供给丰富的跨产品、跨渠道衔接才能，可以促进云产品、运用程序、SaaS 服务三者相互集成。

阿里云将 EventBridge 开源至 RocketMQ 社区，也是希望开源社区能有相似的根底设备，可以集成和整合开源生态，一同能与各个云厂商的「Hub」类产品进行集成，来到达开源和云互通的效果，让用户可以随意上云，也能随意下云。

跟职业比照，从可用性和可靠性上来看，RocketMQ 多副本机制有哪些特别之处？

跟职业比照，从可用性和可靠性上来看，RocketMQ 也有多副本机制，并阅历了多个版别的演进，跟着 RocketMQ 面向的场景的改变而改变，也便是说 RocketMQ 的多副本技能是服务于事务的改变的，并不是一成不变的，这其实也表现了 RocketMQ 架构上的灵活性。这也是跟职业比较最大的不同，职业的大部分多副本处理方案跟架构耦合比较深，基本上是一成不变的。

• RocketMQ 最开端采用的 Master-Slave 架构，该架构服务于阿里内部淘系事务多年，当时事务上架构的诉求其实便是数据冷备，那个阶段包括数据库都是 Master-Slave 的架构。

• 到上云的阶段，云的年代单点毛病频发，云产品需求完全面向失利而规划，故 RocketMQ 开发了根据 ZK 的 HA 架构，该架构从未开源，归于商业上的版别，依托于 Zookeeper 的分布式锁和通知机制，引进 Controller 组件负责 Broker 状况的监控以及主备状况机转换，在主不可用时，备主动切换为主。

• 再到后来，事务除了重视可用性，也越来越多地重视“毛病恢复时间”，也便是 RTO 目标，根据 ZK 或许开源根据 Raft 的多副本版别 RTO 时间都较长，为了处理这个问题，商业上针对事务音讯，规划了“秒级 RTO”多副本架构，包括无切换规划、节点对等、灵活 ACK、特别音讯毛病转移等规划可以将集群毛病恢复时间降低到秒级。

• 到 RocketMQ 5.0，需求一同面向音讯和流的场景，对多副本技能有了十分高的要求，一方面在事务音讯希望集群有超短的毛病转移时间，另一方面流要求分区永不下线，根据这个布景，在 5.0 这个大版别傍边，将商业上的秒级 RTO 架构与开源的 Dledger Controller 进行了交融，一致了音讯和流的多副本方案。

为什么有各种各样的 MQ？

前面也讲过音讯行列的前史，近几年可谓说是蓬勃开展了，的确呈现了许多音讯行列处理方案，但其实去剖析每种音讯行列，会发现他们诞生的布景和要针对性处理的问题是不一样的。

• RabbitMQ诞生于规范化与开源，打破了商业化音讯行列的技能壁垒，但运用场景其实没变，定位为异步与解耦；

• Kafka诞生的布景是大数据，以批量，高吞吐等中心才能抢占了大数据管道的心智，随后十分自然地定位到 Streaming 范畴；

• EMQ重点聚集的范畴在物联网，物联网的应战跟其他范畴是大相径庭的，超大规划的设备与衔接数，规则引擎，甚者边缘段需求有一整套完整的处理方案；

• Pulsar作为后起之秀尝试在多个范畴发力，包括 Messaging、Function、Streaming 等多范畴都有相应布局。

回到 RocketMQ，咱们能从近两年 RocketMQ 在社区的一系列动作中发现，RocketMQ 一同在音讯、事情、流三个范畴都有发力，逐步演进至一个超交融处理渠道。 作为一个交融的数据处理渠道，RocketMQ 当时在开源的布局看起来是与业界多个 MQ 趋同，咱们并非是为了做成多个 MQ 的超集，在 RocketMQ 开源的背面其实是商业上实在的需求驱动，许多场景和技能现已在内部现已孵化多年。

• 在音讯范畴，RocketMQ 4.0 商业上做了许多事务音讯范畴的立异与探究，并继续反哺至开源社区。

• 在流范畴，RocketMQ Streams 也是诞生于内部事务，当事务音讯到达一定的规划后，低本钱和轻量级的核算需求就呼之欲出了。

• 在事情范畴，云原生年代带来了激烈的事情驱动需求，咱们在云上孵化了全新的 EventBridge 产品并进行了开源。

从功能上来讲，推迟、吞吐量等这些，比照职业来说，是个什么水准，有没有相关基准测试数据？

一般讲功能，其实便是吞吐量和推迟两个目标。

关于吞吐量来讲，RocketMQ 在 2017 年就能优化到单机 50W 的 TPS，后续在内部甚至能摸高到 100W TPS，这个仍是单条的功能（非批量），但实际上从出产环境的安稳性，以及事务音讯的重要性来讲，咱们从来没有在出产环境布置过这么高 TPS 的负载。如果是在批量的场景，职业各个音讯行列我相信都能容易地打满网络带宽或许磁盘资源。换句话说，功能是很难作为一个产品的中心竞争力的，除非是架构层面有约束，一般情况下差异都不大。RocketMQ 当时的功能是足够用的，即便是以高功能著称的 Kafka，在阿里云上 RocketMQ 都能作为其内核支撑阿里云 Kafka 的事务场景。

推迟便是一个十分重要的目标了，在推迟这个目标后边长尾推迟，也便是常说的毛刺更是重中之中，在线事务关于是 2ms 延时和 5ms 延时基本上都能接受，但十分难以接受的是经常性有秒级的毛刺。RocketMQ 曾经在内部双十一场景被诟病最多的便是毛刺，在 2016 年咱们耗费了很大的精力打造了低推迟的存储引擎，十分顺滑地支撑了这么多年的双十一，这也是 RocketMQ 能十分好地支撑在线事务的一个首要原因。

除了这两点，弹性和可扩展才能也是十分重要的，单机功能再高，不能充沛使用云上的弹性资源就不能算是云原生年代的处理方案。甚至从安稳性的视点来讲，操控单机的规格和功能上限，以横向扩展的方法支撑事务的弹性需求是更安稳更健康的一种方法。

比照音讯体系整个的开展趋势，以为哪些地方的规划比较有先见之明？为什么？

这个问题咱们简要答复，后续文章可以详细再说。首要有几个方面：

1. 坚持架构的简洁性：NameSrv+Broker 搞定全部需求，多副本技能能随意演进。
2. 产品上的规划：轨道、回放，都是业界创始和仿照的目标。
3. 音讯——>流的演进：单纯面向事务音讯的场景，其实KV存储模型更适合，但 RocketMQ 一向坚持行列存储模型，也为后边向流存储方向开展留下了空间，一同也有了音讯模型和行列模型共存的立异技能的诞生。

阿里云音讯行列未来的规划是什么？

在新的浪潮下，咱们以为音讯行列会往以下三个方向进一步的演进：

• 第一个趋势是全面拥抱云原生，向上音讯产品形状演进，支撑云原生运用架构（微服务、EDA）。比方微服务、事情驱动、Serverless 等现代化架构，向下音讯体系本身进行云原生架构演进，要经过一系列的技能改造，充沛释放云根底设备的弹性核算、弹性存储、弹性网络等才能，全方位进步音讯的技能目标，降低本钱，进步弹性才能。

• 第二个趋势是拥抱物联网。物联网技能将更广泛的落地到各行各业，万物互联、边缘核算进一步拓展音讯的鸿沟。面向物联网的音讯行列要海量异构设备接入，海量音讯行列存储，可以到处运行，具有云边端一体的无鸿沟布置才能。

• 第三个趋势是拥抱实时数据。现在企业的数字化转型又往前跨进了一步。从原来的事务数字化跨进到了数字事务化，数字化企业继续发生事务数据，对事务数据的实时洞悉、实时决议计划，能快速掌握商机，辅导事务获得更大的成功。音讯行列也将从在线事务架构根底设备，延伸到实时数据架构根底设备，事务剖析一体化。

在这个趋势的引领下，RocketMQ 当时和未来久远的规划一向是「打造音讯、事情、和流一体的超交融处理渠道」，RocketMQ 5.0 对这一目标完成了初步的布局，未来会进一步强化音讯行列 RocketMQ 在这三个范畴的进一步演进。

• 在音讯范畴，全面拥抱云原生技能，弹性弹性，开箱即用。

• 在事情范畴，产品形状全面晋级，拥抱职业规范，让事情驱动架构无处不在，从单一事务的数字化体系，扩展到跨事务、跨安排的数字化商业生态。事情驱动架构一同也让云核算、云原生的技能可以更大规划的落地，进步云产品和用户事务的集成度，让 Serverless 技能被更大规划的选用，为客户降本增效。

• 在流范畴，流存储增强批量特性，大幅度进步数据吞吐量；新增逻辑行列才能，解耦逻辑资源和物理资源，在流场景也具有无缝弹性才能；新增轻量流处理引擎，供给实时事情流处理、流剖析才能。