背景
作为一种实时数据的解决平台，音讯零碎的倒退跟业务架构的变迁始终非亲非故，那么咱们能够透过业务架构的变动来看音讯零碎的倒退历程和将来趋势。通过十多年的倒退，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 能十分好地反对在线业务的一个次要起因。
除了这两点，弹性和可扩大能力也是十分重要的，单机性能再高，不能充分利用云上的弹性资源就不能算是云原生时代的解决方案。甚至从稳定性的角度来讲，管制单机的规格和性能下限，以横向扩大的形式撑持业务的弹性需要是更稳固更衰弱的一种形式。
比照音讯零碎整个的发展趋势，认为哪些地方的设计比拟有先见之明？为什么？
这个问题咱们简要答复，后续文章能够具体再说。次要有几个方面：
- 放弃架构的简洁性：NameSrv+Broker 搞定所有需要，多正本技术能随便演进。
- 产品上的设计：轨迹、回放，都是业界独创和模拟的对象。
- 音讯——> 流的演进：单纯面向业务音讯的场景，其实 KV 存储模型更适宜，但 RocketMQ 始终保持队列存储模型，也为前面向流存储方向倒退留下了空间，同时也有了音讯模型和队列模型共存的翻新技术的诞生。
阿里云音讯队列将来的布局是什么？
在新的浪潮下，咱们认为音讯队列会往以下三个方向进一步的演进：
- 第一个趋势是 全面拥抱云原生，向上音讯产品状态演进，撑持云原生利用架构（微服务、EDA）。比方微服务、事件驱动、Serverless 等现代化架构，向下音讯零碎本身进行云原生架构演进，要通过一系列的技术改造，充沛开释云基础设施的弹性计算、弹性存储、弹性网络等能力，全方位进步音讯的技术指标，降低成本，进步弹性能力。
- 第二个趋势是 拥抱物联网。物联网技术将更宽泛的落地到各行各业，万物互联、边缘计算进一步拓展音讯的边界。面向物联网的音讯队列要海量异构设施接入，海量音讯队列存储，可能随处运行，具备云边端一体的无边界部署能力。
- 第三个趋势是 拥抱实时数据。当初企业的数字化转型又往前迈进了一步。从原来的业务数字化迈进到了数字业务化，数字化企业继续产生业务数据，对业务数据的实时洞察、实时决策，能疾速把握商机，领导业务取得更大的胜利。音讯队列也将从在线业务架构基础设施，延长到实时数据架构基础设施，事务剖析一体化。
在这个趋势的引领下，RocketMQ 以后和将来久远的布局始终是「打造音讯、事件、和流一体的超交融解决平台」，RocketMQ 5.0 对这一指标实现了初步的布局，将来会进一步强化音讯队列 RocketMQ 在这三个畛域的进一步演进。
- 在音讯畛域，全面拥抱云原生技术，弹性伸缩，开箱即用。
- 在事件畛域，产品状态全面降级，拥抱行业标准，让事件驱动架构无处不在，从繁多业务的数字化零碎，扩大到跨业务、跨组织的数字化商业生态。事件驱动架构同时也让云计算、云原生的技术可能更大规模的落地，进步云产品和用户业务的集成度，让 Serverless 技术被更大范畴的驳回，为客户降本增效。
- 在流畛域，流存储加强批量个性，大幅度提高数据吞吐量；新增逻辑队列能力，解耦逻辑资源和物理资源，在流场景也具备无缝伸缩能力；新增轻量流解决引擎，提供实时事件流解决、流剖析能力。