演讲嘉宾：林清山（花名：隆基），Apache RocketMQ 联合创始人，阿里云资深技术专家，阿里云消息产品线负责人。国际消息领域专家，致力于消息、实时计算、事件驱动等方向的研究与探索，推进 RocketMQ 云原生架构、超融合架构的演进。 本文整理于 2023 年云栖大会林清山带来的主题演讲《Apache RocketMQ 云原生统一消息引擎》 Apache RocketMQ 简介 消息队列演进趋势 操作系统、数据库、中间件是基础软件的三驾马车，而消息队列属于最经典的中间件之一，已经有 30 多年的历史。它的发展主要经历了以下几个阶段： 第一个阶段，2000 年之前。80 年代诞生了第一款消息队列是 The Information Bus，第一次提出发布订阅模式来解决软件之间的通信问题；到了 90 年代，则是国际商业软件巨头的时代，IBM、Oracle、Microsoft 纷纷推出了自己的 MQ，其中最具代表性的是 IBM MQ，价格昂贵，面向高端企业，主要是大型金融、电信等企业；这类商业 MQ 一般采用高端硬件，软硬件一体机交付，MQ 本身的软件架构是单机架构。 第二阶段，20002007 年。进入 00 年代后，初代开源消息队列崛起，诞生了 JMS、AMQP 两大标准，与之对应的两个实现分别为 ActiveMQ、RabbitMQ，他们引领了初期的开源消息队列技术。开源极大的促进了消息队列的流行、降低了使用门槛，技术普惠化，逐渐成为了企业级架构的标配。相比于今天而言，这类 MQ 主要还是面向传统企业级应用，面向小流量场景，横向扩展能力比较弱。 第三阶段，20072017 年。PC 互联网、移动互联网爆发式发展。由于传统的消息队列无法承受亿级用户的访问流量和海量数据传输，诞生了互联网消息中间件，核心能力是全面采用分布式架构、具备很强的横向扩展能力，开源典型代表有 Kafka、RocketMQ，闭源的还有淘宝 Notify。Kafka 的诞生还将消息中间件从消息领域延伸到了流领域，从分布式应用的异步解耦场景延伸到大数据领域的流存储和流计算场景。 第四阶段，2014至今。云计算、IoT、大数据引领了新的浪潮。 Apache RocketMQ 发展历程 伴随着消息队列行业的发展，Apache RocketMQ 自身也发展了十年，可分为“诞生于互联网”与“成长于云计算”两大阶段。 第一个阶段是 RocketMQ 的从 0 到 1，在阿里内部规模化落地。2012 年，为了支撑超大规模电商互联网架构，阿里中间件研发了 RocketMQ，并在产品诞生初期开源，2017 年 RocketMQ 统一了阿里消息技术体系。 第二个阶段是云计算 , 2016 年 RocketMQ 上云，这也是业界首个提供公共云 SaaS 形态的开源消息队列。2016 年，阿里把 RocketMQ 捐赠给 Apache，17 年孵化毕业，成为国内首个 TLP 的互联网中间件。在云计算和开源双轮驱动下，RocketMQ 在阿里外部完成全面规模化，帮助千行百业完成数字化转型，产品能力也得到进一步的飞跃。2022 年 5.0 正式发布，Apache RocketMQ 正式迈进云原生时代。 Apache RocketMQ 5.x 统一消息引擎 Apache RocketMQ 5.X 业务全景 为了满足云时代多样化的用户需求，RocketMQ 5.0 从原来的互联网业务消息中间件，扩展到"消息、事件、流"超融合处理平台，解锁更全面的能力。 在消息领域，全面拥抱云原生技术，更好的弹性架构和高可用能力。 在事件领域，支持 CloudEvent 规范，以事件为中心的产品新界面，助力客户建设跨业务、跨组织的数字化商业生态。 在流领域，流存储增强批量特性，大幅度提高数据吞吐量；新增逻辑队列能力，解耦逻辑资源和物理资源，在流场景也具备无缝伸缩能力；新增流数据库 RSQLDB，提供实时事件流处理、流分析能力。 RocketMQ 基于端云一体化架构实现了完整的物联网消息队列的能力，从原来的连接应用扩展到连接物联网设备。同时 RocketMQ 5.0 也继续保持极简架构的原则，能够以最低的资源消耗、运维成本搭建服务，适合边缘计算。 为什么说 Apache RocketMQ 是统一的消息引擎，主要有以下几方面的统一。 消息和流的统一 第一个统一是 Apache RocketMQ 统一了消息和流的场景。 通过这个对比图来看，消息和流的区别。常说的消息场景、队列场景侧重于业务集成，在这个场景里 RocketMQ 的主要作用是连接业务应用，解耦业务架构的上下游系统，比如交易系统的解耦。这类场景，更多的是在线业务，由用户触发某个业务流程，比如购买。为了保障用户体验，消息系统要优先保障低延迟。这个场景里和同步通信 RPC 对应，消息系统承担都是异步通信职责。在消息消费层面，更多的是基于消息数据执行对应的业务逻辑，触发下一个业务流程。每条消息的处理都是不相关的，无状态的。侧重于业务数字化场景，可类比于数据库的 OLTP，单次操作数据量少，用于在线交易。 再来看流场景的话，它主要是侧重于数据集成，连接各种数据组件，进行数据分发，解耦数据架构的上下游系统。比如日志解决方案，采集日志数据，进行ETL将日志数据分发到搜索引擎、流计算、数据仓库等。除了日志之外，数据库 Binlog 分发、页面点击流也是常见的数据源。在这种场景里里面，由于是离线业务，它对低延迟的需求较弱，更加侧重于大批量吞吐型负载。另外在消息消费阶段，不再是单条消息处理，更多的是批量转储，或者批量进行流计算。侧重于数字业务化场景，可类比于数据库的 OLAP，单次操作数据量大，用于离线分析场景。 具体来说，RocketMQ 如何实现消息和流的统一呢？ 主要体现在领域模型的 统一，包含 Producer、Consumer、Topic、Topic 逻辑分区 MessageQueue。在统一的领域模型下采用不同的访问模式来满足消息和流的不同场景。 在消息场景，客户端只感知 Topic，往 Topic 发送消息，基于订阅关系消费Topic的消息，触发对应的业务逻辑，返回消费成功或者失败，消费失败还会有重试。 而在流的场景，对于消息数据的访问模式有所不同。由于是用在数据集成的场景，对于大规模的数据集成，不可避免的要涉及到数据的分片，基于数据分片来连接上下游数据系统。在消息的读写方式上，不再是指定 Topic 读写，而是指定 Topic 分片，也就是队列进行读写操作。作为流存储系统，下游的消费通常会是一些流计算引擎，用于有状态计算。为了支撑流计算引擎的容错处理，它需要支持 checkpoint 机制，类似于为流计算引擎提供 redolog，能够按照队列位点重放消息，重新恢复流计算的状态。他也会要求分片内有序，同一个 key 的数据会 hash 到同一个分片，用于实现 keyby 的操作。 这个就是流存储访问模式跟消息访问模式的区别。在消息场景里，用户只需要关注到 topic 资源，无需了解队列、位点等概念。 在流场景里面，还有一个很重要的变化，就是数据类型的变化。 做个简单对比，业务集成场景，消息的数据承载的是业务事件，比如说订单操作、物流操作，它特点就是数据规模较小，但是它每一条数据的价值都特别高，它的访问模式是偏向于在线的，单条事务的短平快访问模式。 而在流的场景里面呢，它更多的是一些非交易型的数据。比如说用户日志，系统的监控、IoT 的一些传感器数据、网站的点击流等等。他的特点是数据规模有数量级的提升，但单条数据的价值比较低的，然后它的访问模式偏向于离线批量传输。所以在流的场景里面，RocketMQ 存储要面向高吞吐做更多的优化。 在 RocketMQ 5.0 里面， 引入了端到端的批量消息。从客户端开始，在发送阶段，消息在客户端攒批到一定数量，直接 1 个 RPC 请求里面直接发到 broker 端。broker 存储阶段，直接把整批消息存储，用批量索引的技术，一批消息只会构建一个索引，大幅度提升索引构建速度。在消费阶段，也是按照整批数据读取到消费端，先进行解包操作，最后执行消费逻辑。这样整个 Broker 的消息 TPS 可以从原来的 10 万级提升至百万级。 端和云的统一 第二个统一是端和云的统一，端指物联网设备端、移动端，云指云端服务和应用。 我们先来了解一下物联网的场景是什么，以及消息在物联网里面有什么作用。物联网肯定是最近几年最火的技术趋势之一，有大量的研究机构、行业报告都提出了物联网快速发展的态势。 物联网设备规模爆发式增长，会在 2025 年达到 200 多亿台。 物联网的数据规模，来自物联网的数据增速接近 28%，并且未来有 90% 以上的实时数据来自物联网场景。这也就意味着未来的实时流数据处理数据类型会有大量物联网数据。 重要的趋势是边缘计算，未来会有 75% 的数据在传统数据中心或者云环境之外来处理，这里的边缘指的是商店、工厂、火车等等这些离数据源更近的地方。 通过这个图能看出消息在物联网场景发挥的作用： 第一个作用是连接，承担通信的职责，支持设备和设备的通信，设备和云端应用的通信，比如传感器数据上报、云端指令下发等等这些功能，支撑 IoT 的应用架构，连接云边端。 第二个作用是数据处理，物联网设备源源不断的产生数据流，有大量需要实时流处理的场景，比如设备维护，高温预警等等。基于 MQ 的事件流存储和流计算能力，可以构建物联网场景的数据架构。 在一个完整的物联网解决方案中，会同时涉及到端和云的协同，端用于采集数据、执行设备指令，云用于存储数据、分析数据，执行复杂业务逻辑。所以在 RocketMQ 5.0 里发布了 MQTT 子产品，实现端云一体化。它有三个核心特点： 1. 采用标准的物联网协议 MQTT，该协议面向物联网弱网环境、低算力的特点设计，协议十分精简。同时有很丰富的特性，支持多种订阅模式，多种消息的 QoS，比如有最多一次，最少一次，当且仅当一次。它的领域模型设计也是 消息、 主题、发布订阅等等这些概念，和 RocketMQ 特别匹配，这为打造一个云端一体的 RocketMQ 产品形态奠定了基础。 2. 采用端云一体化的架构，因为领域模型接近、并且以 RocketMQ 作为存储层，每条消息只存一份，这份消息既能被物联网设备消费，也能被云端应用消费。另外 RocketMQ 本身是天然的流存储，流计算引擎可以无缝对 IoT 数据进行实时分析。消息可以来自各个接入场景（如服务端的 RocketMQ，设备端的 MQTT），但只会写一份存到 commitlog 里面，然后分发出多个需求场景的队列索引，比如服务端场景（RocketMQ）可以按照一级 Topic 队列进行传统的服务端消费，设备端场景可以按照 MQTT 多级 Topic 以及通配符订阅进行消费消息。这样就可以基于同一套存储引擎，同时支持服务端应用集成和 IoT 场景的消息收发，达到端云一体化。 3. 将原来 RocketMQ 的万级队列能力提升到百万级队列能力。例如 Kafka 这样的消息队列每个Topic 是独立文件，但是随着 Topic 增多消息文件数量也增多，顺序写就退化成了随机写，性能明显下降。RocketMQ 在 Kafka 的基础上进行了改进，使用了一个 Commitlog 文件来保存所有的消息内容，再使用 CQ 索引文件来表示每个 Topic 里面的消息队列，因为 CQ 索引数据比较小，文件增多对 IO 影响要小很多，所以在队列数量上可以达到十万级。但是这个终端设备队列的场景下，十万级的队列数量还是太小了， 希望进一步提升一个数量级，达到百万级队列数量，所以， 引入了 Rocksdb 引擎来进行 CQ 索引分发，实现了百万级队列。 消息和事件的统一 第三个统一是消息和事件的统一。 在这之前， 我们先了解一下什么是事件驱动。事件驱动本质上是一种软件设计模式，它能够最大化降低不同模块以及不同系统之间的耦合度。 下面是一个典型的事件驱动架构图，首先是事件生产者发送事件到 EventBroker，然后 EventBroker 会把事件路由到对应的消费者进行事件处理。事件处理能够灵活扩展，随时增减事件消费者，事件生产者对此透明。 事件驱动架构其实是个很经典的设计模式，因为早在几十年前，就出现过多种事件驱动的技术。比如桌面客户端编程框架，点击按钮就可以触发 onclick 事件，开发者编写业务逻辑响应事件；在编程语言上，也经常会采用事件驱动的代码模式，比如 callback、handler 这类的函数；进入分布式系统的时代，系统之间的通信协同也会采用事件驱动的方式。 从这个图我们可以发现事件驱动架构其实和基于消息的应用解耦差别不大，他们本质上要解决的都是解耦的问题。无论是消息的发布订阅，还是事件的生产消费都是为了进行代码解耦、系统解耦。消息队列更偏技术实现，大部分的 EventBroker 都是基于消息队列实现的，而事件驱动更偏向于架构理念。 事件驱动跟消息驱动最大的区别就是，事件是一种特殊的消息，只有消息满足了某些特征，才能把它叫做事件。 打个比方，来看上面这个图。消息就像是一个抽象类，有多种子类，最主要的就是 Command 和 Event 两种。以信号灯为例，向信号灯发送打开的消息，这就是一种 Command，信号灯接受这个 Command 并开灯。开灯后，信号灯对外发出信号灯变成绿色的消息，这个就是一种 Event。 对于 Event 来说，有四个主要的特征： 1. 它是一个不可变的，事件就是表示已经发生了的事情，已经成为事实。 2. 事件有时间概念，并且对同一个实体来说事件的发送是有序的。如信号灯按顺序发送了绿、黄、红等事件 3. 事件是无预期的，这个就是 EDA 架构之所以能够实现最大化解耦的特点，事件的产生者对于谁是事件消费者，怎么消费这个事件是不关心的 4. 由于事件驱动是彻底解耦的，并且对于下游怎么去消费事件没有预期，所以事件是具象化的，应该包括尽可能详尽的信息，让下游消费者各取所需。这就是消息和事件的区别。 走向 Serverless Serverless 大势 Serverless 被认为是下一代的云原生代表技术；云原生的本质则是通过一套技术体系和方法论，帮助客户更好的用云，充分释放云计算红利，让使用云计算的客户能够实现更高效、更低成本的数字化转型。关于云原生的技术， 听的比较多有微服务、容器化等。微服务侧重于应用架构理念的革新，用微服务来实现业务高内聚、低耦合，从而提高研发效率、协作效率、业务敏捷度；而容器化则涉及应用运维层面，用容器化来屏蔽基础设施的差异，提高可移植性，借助 K8S 平台，还能提高应用的运维效率、资源利用率。 而 Serverless 在云原生所代表的含义则是，基础技术下沉，云服务界面上移的趋势，本质上还是让客户把更多的精力聚焦在业务研发上，无需关心底层技术和物理资源。 如下面这个图，在云计算之前，用户需要自建 IDC、购买物理机、自行虚拟化、搭建中间件，然后才能进行业务研发，有大量的时间、精力、资源都花在和业务无关的项目上。进入云计算之后，越来越多的基础设施由云厂商来提供，从最早的 IaaS，直接使用云厂商的计算、存储、网络资源；再到 PaaS，无需自建数据库和中间件，直接使用托管基础软件服务；再到现在云计算演进到 Serverless 的阶段，客户完全把大部分精力聚焦在业务代码的开发上。 对云服务厂商来说，Serverless 的云产品也从最早的少数产品如对象存储、函数计算等，发展到现在的 all on Serverless，具备了完备的 Serverless 产品体系，如 Serverless 消息队列、微服务、数据库、搜索、大数据产品等。 全面 Serverless 的应用场景 进入 Serverless 时代，全面使用 Serverless 的客户会为消息队列带来哪些场景变化呢？ 如在应用侧，越来越多的应用不在部署在自行购买的 ECS 上面，直接托管在 Serverless 容器、应用引擎、函数计算上，云服务会根据其业务流量或者系统负载自动进行弹性伸缩，对应的消息服务也要能根据消息流量自行弹性伸缩。 在车联网消息解决方案场景里，汽车每天都有早晚高峰，上下行的消息流量也出现明显的波峰波谷，车联网客户无需为波峰流量预先购买消息资源，而是根据实际消息量，用多少付多少钱。 在移动 App 推送场景，也会面临更多维度的资源指标，比如需要维持大量的连接数、偶尔的峰值消息推送、极小的消息存储空间，客户无需预先购买计算、存储、网络绑定的消息实例，而是分别面向连接数、消息流量、存储空间分别付费。 除了核心的弹性能力之外，消息队列的核心架构场景“事件驱动”在 Serverless 时代成为最重要的架构模式，事件驱动架构有助于开发更加敏捷、可扩展、韧性的 Serverless 应用，事件驱动天然匹配 Serverless 研发范式。因此 Serverless 全云开发模式中，客户希望消息队列的服务界面也需要上移，具备“事件总线”的能力。客户不仅需要开箱即用的 Serverless 云服务，也需要开箱即用的事件驱动集成服务，无需像以前一样编写集成的胶水代码，研发效率进一步提升，走向 lowcode、nocode。比如云产品事件集成，OSS 文件上传事件发送到事件总线，用户订阅这个事件，并基于函数计算进行文件加工处理响应事件，驱动 Serverless 算力。 面向 Serverless 的趋势，RocketMQ 5.0 从产品形态到技术架构都做了巨大的演进。 面向 Serverless 应用的新 SDK 当应用大量使用 Serverless 技术之后，应用的实例数将会随着流量的变化动态弹性伸缩，相比于过去的场景，实例数变化将十分频繁，这就对消息收发的负载均衡提出比较大的挑战。 先来看生产链路的负载均衡，生产者通过服务发现机制，知道了 Topic 的数据分片以及对应的 Broker 地址。他的服务发现机制是比较简单的，在默认情况下采用 RoundRobin 的方式轮询发送到各个 Topic 队列，保证了 Broker 集群的流量均衡。生产者是彻底无状态的，所以无论如何弹性伸缩，都没有太多影响。 再来看下消费者的负载均衡，相对来说它会比生产者更复杂，旧模式是队列级负载均衡，消费者知道Topic的队列总数，也知道同一个 ConsumerGroup 下的实例数，就可以按照统一的分配算法，类似一致性 hash 的方式，让每个消费者实例绑定对应的队列，只消费绑定队列的消息，每个队列的消息也只会被一个消费者实例消费。这种模式最大的缺点就是负载不均衡，消费者实例要绑定队列、有临时状态。当应用实例数变化频繁的时候，这种负载不均衡会导致应用的 Serverless 扩容无效，扩容的新阶段无法分担消息的流量。如图 Topic 有 2 个分区，扩容第三个节点会出现空跑；如果 把 Topic 扩容成 3 个分区，随后消费者实例又缩容回 2 个，那么就会出现其中一个消费者实例承担三分之二的流量，出现过载。 所以在 RocketMQ 5.0 里面， 引入了消息粒度的负载均衡机制，无需绑定队列，消息在消费者集群随机分发，这样就可以保障消费者集群的负载均衡。更重要的是这种模式更加符合全链路 Serverless 化的场景，Broker 的机器数、Topic 的队列数和消费者实例数完全解耦，可以独立扩缩容。 Serverless事件驱动的挑战 在上一个章节， 提到消息和事件的统一，事件是一种包含业务语义的消息。下面结合一个典型事件驱动的案例来看看。如下图是一个基于消息队列 RocketMQ 实现的一个交易系统，采用事件驱动的架构，围绕“订单”事件完成交易业务。事件生产者是交易中心，消费者是交易的下游系统。比如发送订单创建事件，购物车响应事件，删除之前的加购商品；发生订单付款事件，会员系统响应事件，给客户增加积分，物流系统响应事件，执行后续的发货履约环节。整个交易系统是由“事件驱动”的微服务构建而成。 基于经典消息队列的事件驱动方案在一个组织内部、部门内部是一个不错的选择。但是在 Serverless 时代面临很多全新的挑战。 越来越多的商业数字化解决方案是由多个不同组织协作完成的，比如 SaaS 平台（钉钉）和它的合作伙伴，钉钉平台发布各种事件，包括视频会议、日程、通讯录、审批流、钉盘等事件，下游合作伙伴消费这些事件，研发行业应用。在这类新型数字化解决方案中，往往事件的生产者和消费者属于不同的公司，开发者无法进行密集的交流，低成本的了解“事件”定义、格式、使用方法。目前的模式过于依赖开发者之间的交流，以及公司的内部文档沉淀。 不同的公司往往会使用不同的技术体系，比如使用不同的消息队列，事件生产者使用 RocketMQ，事件消费者使用 RabbitMQ；比如使用不同的消息传输协议，HTTP 或 AMQP。 事件的消费者多样化，哪怕是同一个业务的事件，事件消费者可能只需要其中的某种子类型；哪怕是同一个事件，事件消费者也可能只能访问其中的部分字段。 缺少开箱即用的事件集成能力，客户全面用云后，需要响应各种云产品事件，比如响应 OSS 上传事件，使用函数计算对文件进行处理，这种预先集成的特性，经典的消息队列不具备。 Serverless 的事件驱动技术需要更加彻底的解耦，只关注“事件”本身，解耦技术实现细节，如传输协议、SDK、生产消费模式。 Serverless 事件驱动的设计 为了实现 Serverless 的事件驱动， 在消息队列的基础上面，将“事件驱动”场景的服务界面上移，围绕“事件”的领域模型进行重新设计。 最左边是事件源，由于事件需要具备跨平台生产消费的能力，所以采用 CNCF 的 CloudEvents 来作为事件的格式。这个是业界事件的事实标准，它标准简化了事件声明，提升事件在跨服务、跨平台的互操作性。 由于事件是有可能被跨组织消费的，所以需要一个统一的事件中心，让这些不同的事件源都注册到这个事件中心。对消费者来说就好比是一个事件商店，能够选择自己感兴趣的事件订阅。 在事件消费者开始编写消费逻辑的时候，开发者还需要对这个事件的格式有更清楚的了解，需要知道这个事件有哪些内容，有哪些字段，分别是什么含义，才能编写正确的消费业务逻辑。所以，事件总线还提供了 schema 中心，有这个 schema 中心后，消费者对于事件的格式也就一目了然，不用跟事件源的发起者进行沟通了，整个效率也得到了大幅度的提升。 再往后面看，就到了事件消费的环节，因为事件的消费者种类很多，不同消费者关注不同的事件类型，事件总线需要提供丰富的过滤规则。即便多个消费者对同一个事件感兴趣，但是可能只需要事件的部分内容，事件总线还提供了事件转换的能力。这就是 RocketMQ 5.0 对事件驱动的能力抽象。 Serverless 事件驱动的新形态 基于上面的全新设计， 以 RocketMQ 作为事件存储的内核，实现了全新的事件总线 EventBridge。在产品界面上，面向事件驱动的业务进行一层抽象，核心领域对象从消息变成 CloudEvents。基于统一事件标准来构建事件驱动的数字生态。 事件源是多样化的，可以是云产品事件、数据流事件、也可以是 SaaS 平台事件，应用自定义事件、通用的 WebHook。当然，它的事件目标也是多样化的，通过事件规则引擎把事件路由到不同的消费者，典型的消费者包括函数计算、消息系统（用于解耦生产者、消费者使用不同的消息队列技术）、存储系统、流计算引擎、通用的 webhook，甚至可以是消息通知如语音\短信\邮件。事件驱动架构更适合建设混合云、多云的数字化系统。 通过 EventBridge 实现彻底的事件驱动架构，真正做到只关心“事件”本身，生产者和消费者实现更加彻底的解耦，包括组织解耦、技术体系解耦。 面向 Serverless 消息内核的重构 前面提到的主要是面向 Serverless 应用场景，如一些 Serverless 化的应用，Serverless 化的事件驱动架构，RocketMQ 在产品形态、使用界面上做出的改变。现在我们从技术架构演进的角度来看 RocketMQ 如何实现一个 Serverless 化的消息云服务。在 Serverless 场景下，客户需要的是声明式的逻辑资源，不同逻辑资源可以解绑，分别弹性、按量服务。 面向 Serverless 的场景，RocketMQ 演进到三层存算分离的架构。 第一层是 RocketMQ proxy，它主要承载的是多协议，多领域场景的覆盖。这里面的领域场景有 RocketMQ 场景，经典的服务端应用集成；还有 MQTT，面向物联网的应用；还有 EventBridge 面向事件驱动型的应用。Proxy 可以认为是计算资源的主要载体，它是一个彻底的无状态的网关。它可以面向客户不同的连接数，不同的消息 TPS 以及不同的消息的读写的比例的变化，进行一个计算、网络资源的独立弹性。这样才可以匹配到客户在 Serverless 场景下，对多种资源解耦弹性的需求。 第二层是 RocketMQ 的存储引擎，它主要专注于消息多副本实现、多副本如何进行高可用切换。同时它也要负责本地存储跟云存储的统一抽象。由于消息的存储主要在云盘和对象存储上面，大部分的消息数据存储在对象存储，store 自身的状态被弱化了，弹性效率也得以提升。RocketMQ store 可以根据客户的消息流量特点，如消息吞吐量、TPS、消息大小、批量因素等和存储资源 IOPS、带宽、存储空间进行弹性匹配，实现消息存储和计算的解耦。 第三层是云存储层这一块，大部分的消息存储在对象存储上，这是公共云基础设施级的存储池化。通过将冷数据卸载到了对象存储，然后缩短了 RocketMQ Store 的生命周期，同时也具备一个低成本的无限消息存储空间。 现在 RocketMQ 5.0 已经具备弹性架构，采用云服务形态的 RocketMQ 能够进一步和云的基础设施深度结合，充分释放云计算红利。 在计算层面，RocketMQ 5.0 通过容器服务充分利用 ECS 弹性能力，采取弹性资源池 + HPA 相关技术支持计算能力快速弹性，同时 ACK 自带的跨可用区部署能力为云产品提供了充足的高可用保障。 在网络层面，RocketMQ 5.0 可接入了多种云原生网络能力，满足用户对多样性网络的需求，公网随开随用，支持多种私网网络形态，基于 CEN 构建了全球互通的消息网络，实现异地多活。 在存储方面，基于盘古 DFS、对象存储的多级存储架构，提供低成本的无限存储能力，冷热数据链路分离，提供更高的 SLA。 事件驱动赋能 Serverless 技术栈 最后，基于 Apache RocketMQ 打造的消息产品体系，以事件驱动 + 集成两大场景，赋能全面 Serverless 技术栈。 以上是一个典型的 Serverless 产品体系，一些头部云厂商已经实现了核心产品的全面 Serverless 化，无论是计算、存储，还是大数据分析都具备了 Serverless 服务能力，基于这些能力客户能够打造端到端的 Serverless 应用，聚焦核心业务，把降本增效做到极致。

一、消息场景 RocketMQ5.0是消息事件流一体的实时数据处理平台，是业务消息领域的事实标准，很多互联网公司在业务消息场景会使用RocketMQ。 我们反复提到的“消息、业务消息”，指的是分布式应用解耦，是RocketMQ的业务基本盘。通过本文，我们将深入了解RocketMQ5.0在业务消息场景的优势能力，了解为什么RocketMQ能够成为业务消息领域的事实标准。 RocketMQ在业务消息领域的经典场景是应用解耦，这也是RocketMQ诞生初期解决阿里电商分布式互联网架构的核心场景，主要承担分布式应用（微服务）的异步集成，达到应用解耦的效果。解耦是所有的软件架构最重要的追求。 分布式应用（微服务）采用同步RPC与异步消息的对比。比如在业务系统中，有三个上游应用与4个下游应用，采用同步RPC的方式，会有34的依赖复杂度；而采用异步消息的方式则可以化繁为简，简化为3+4的依赖复杂度，从乘法简化为加法。 通过引入消息队列实现应用的异步集成可以获得四大解耦优势。 代码解耦：极大提升业务敏捷度。如果用同步调用的方式，每次扩展业务逻辑都需要上游应用显式调用下游应用接口，代码直接耦合，上游应用要做变更发布，业务迭代互相掣肘。而通过使用消息队列扩展新的业务逻辑，只需要增加下游应用订阅某个Topic，上下游应用互相透明，业务可以保持灵活独立快速迭代。 延迟解耦：如果使用同步调用的方式，随着业务逻辑的增加，用户操作的远程调用次数会越来越多，业务响应越来越慢，性能衰减，业务发展不可持续。而使用消息队列，无论增加多少业务，上游应用只需调用一次消息队列的发送接口即可响应线上用户，延迟为常量，基本在5ms以内。 可用性解耦：如果使用同步调用的方式，任何下游业务不可用都会导致整个链路失败。该种结构下类似于串联电路，甚至在部分调用失败的情况下，还会出现状态不一致。而采用RocketMQ进行异步集成，只要RocketMQ服务可用，用户的业务操作便可用。RocketMQ服务通过多对主备组成的broker集群提供，只要有一对主备可用，则整体服务可用，作为基础软件，可用性远大于普通的业务应用，下游应用的业务推进都可以通过MQ的可靠消息投递来达成。 流量解耦：即削峰填谷。如果采用同步调用的方式，上下游的容量必须对齐，否则会出现级联不可用。容量完全对齐需要投入大量精力进行全链路压测与更多机器成本。而通过引入RocketMQ，基于RocketMQ亿级消息的堆积能力，对于实时性要求不高的下游业务，可以尽最大努力消费，既保证了系统稳定性，又降低了机器成本与研发运维成本。 二、基础特性 阿里的交易应用流程为：用户在淘宝上下单时会调用交易应用创建订单，交易应用将订单落到数据库，然后生产一条订单创建的消息到RocketMQ，返回给终端用户订单创建成功的接口。完成的交易流程推进则是依赖RocketMQ将订单创建消息投递给下游应用，会员应用收到订单消息，需要给买家赠送积分、淘金币，触发用户激励相关的业务。购物车应用则是负责删除在购物车里面的商品，避免用户重复购买。同时，支付系统与物流系统也都会基于订单状态的变更，推进支付环节与履约环节。 过去十年多年，阿里电商业务持续蓬勃发展，交易的下游应用已达数百个，并且还在不断增加。基于RocketMQ的电商架构极大提高了阿里电商业务的敏捷度，上游核心的交易系统完全无需关心哪些应用在订阅交易消息，交易应用的延迟与可用性也一直保持在很高水准，只依赖少量的核心系统与RocketMQ，不会受数百个下游应用的影响。 交易的下游业务类型不一，有大量的业务场景不需要实时消费交易数据，比如物流场景能容忍一定的延迟。通过RocketMQ的亿级堆积能力，极大降低了机器成本。RocketMQ的sharednothing架构具备无限横向扩展的能力，已经连续10年支撑了高速增长的双十一消息峰值，在几年前达到亿级TPS。 三、增强能力 经典场景下，RocketMQ相对于其他消息队列，拥有诸多差异化优势与增强。 首先，稳定性方面，稳定性交易是金融场景最重要的需求。RocketMQ的稳定性不仅限于高可用架构，而是通过全方位的产品能力来构建稳定性竞争力。比如重试队列，当下游消费者因为业务数据不ready或其他原因导致某条消息消费失败，RocketMQ不会因此阻塞消费，而是能将此消息加入到重试队列，然后按时间衰减重试。如果某条消息因为某些因素经过十几次重试始终无法消费成功，则RocketMQ会将它转到死信队列，用户可以通过其他手段来处理失败的消息，是金融行业的刚需。 同时，消费成功后如果因为代码bug导致业务不符合预期，应用可以对业务bug进行修复并重新发布，然后应用消息回溯的功能将消息拉回到之前的时间点，让业务按照正确逻辑重新处理。 RocketMQ的消费实现机制采用自适应拉模式的消费，在极端的场景下能够避免消费者被大流量打垮。同时，在消费者的SDK里，做了缓存本地的消息数量与消息内存占用的阈值保护，防止消费应用的内存风险。 其次，RocketMQ还具备优秀的可观测能力，是稳定性的重要辅助手段。RocketMQ是业界第一个提供消息消息级别可观测能力的消息队列，每条消息都可以带上业务主键，比如在交易场景，用户可以将订单ID作为消息的业务主键。当某个订单的业务需要排查，用户可以基于订单ID查询该条消息的生成时间以及消息内容。消息的可观测数据还能继续下钻，通过消息轨迹查看消息由哪台生产者机器发送、由哪些消费者机器在什么时间消费、消费状态是成功或失败等。 除此之外，它支持了几十种核心的度量数据，包括集群生产者流量分布、慢消费者排行、消费的平均延迟、消费堆积数量、消费成功率等。基于丰富的指标，用户可以搭建更加完善的监控报警体系来进一步加固稳定性。 为了支撑更灵活的应用架构，RocketMQ在生产与消费等关键接口提供了多种模式。 生产者接口：RocketMQ同时提供了同步发送接口与异步发送接口。同步发送是最常用的模式，业务流程的编排是串行的，在应用发完消息、Broker完成存储后返回成功后，应用再执行下一步逻辑。然而在某些场景下，完成业务涉及多个远程调用，应用为了进一步降低延迟、提高性能，会采用全异步化的方式，并发发出远程调用（可以是多次发消息或RPC的组合），异步收集结果推，进业务逻辑。 在消费者的接口方面也提供了两种方式： 监听器模式被动消费：这是目前使用最广泛的方式，用户无需关心客户端何时去Broker拉取消息，何时向Broker发出消费成功的确认，也无需维护消费线程池、本地消息缓存等细节。只需要写一段消息监听器的业务逻辑，根据业务执行结果返回Success或Failure。它属于全托管的模式，用户可以专注于业务逻辑的编写，而将实现细节完全委托给RocketMQ客户端。 主动消费模式：将更多的自主权交给用户，也称为Simple Consumer。在该种模式下，用户可以自己决定何时去Broker读取消息、何时发起消费确认消息。对业务逻辑的执行线程也有自主可控性，读取完消息后，可以将消费逻辑放在自定义的线程池执行。在某些场景下，不同消息的处理时长与优先级会有所不同，采用Simple Consumer的模式，用户可根据消息的属性、大小做二次分发，隔离到不同的业务线程池执行处理。该模式还提供了消息粒度消费超时时间的设定能力，针对某些消费耗时长的消息，用户能够调用change Invisible Duration接口，延长消费时间，避免超时重试。 四、总结 消息经典场景：应用解耦； RocketMQ基础特性：发布订阅、可靠消息、亿级堆积、无限扩展； 业务消息场景的增强能力：稳定性、可观测、多样化接口。 【活动】一键体验 RocketMQ 六大生产环境 免费试用+30秒一键体验，低门槛、快速、高效、易操作，带你了解“历经万亿级数据洪峰考验”的云消息队列RocketMQ！ 点击阅读原文，立即参与活动！

2022年，RocketMQ5.0的正式版发布。相对于4.0版本而言，架构走向云原生化，并且覆盖了更多业务场景。 一、消息队列演进史 操作系统、数据库、中间件是基础软件的三驾马车，而消息队列属于最经典的中间件之一，已经有30多年的历史。消息队列的发展主要经历了以下几个阶段： 第一阶段（19802000年）：80年代诞生了第一款消息队列The Information Bus，第一次提出发布订阅模式来解决软件之间的通信问题；90年代是国际商业软件巨头的时代，IBM、Oracle、Microsoft纷纷推出自己的MQ，其中最具代表性的为IBM MQ，价格昂贵，面向高端企业，主要是大型金融、电信等企业。该类商业MQ一般采用高端硬件，软硬件一体机交付，MQ本身的软件架构为单机架构。 第二阶段（2000~2007年）：进入00年代后，初代开源消息队列崛起，诞生了JMS、AMQP两大标准，与之对应的两个实现分别为ActiveMQ、RabbitMQ，他们引领了初期的开源消息队列技术。开源极大促进了消息队列的流行，降低了使用门槛，技术普惠化，逐渐成为企业级架构的标配。相比于今天而言，这类MQ主要面向传统企业级应用和小流量场景，横向扩展能力较弱。 第三阶段（2007~2017年）：PC互联网、移动互联网爆发式发展。由于传统的消息队列无法承受亿级用户的访问流量与海量数据传输，诞生了互联网消息中间件，核心能力是全面采用分布式架构，具备很强的横向扩展能力，开源典型代表有Kafka、RocketMQ，闭源的有淘宝Notify。Kafka的诞生还将消息中间件从消息领域延伸到了流领域，从分布式应用的异步解耦场景延伸到大数据领域的流存储与流计算场景。 第四阶段（2014~至今）：云计算、IoT、大数据引领了新的浪潮。 二、互联网时代的RocketMQ 阿里的电商系统最初是个庞大的单体巨石应用，在研发效率、稳定性方面都无法满足淘宝和天猫飞速的发展。为了解决问题，2008年，淘宝与天猫发起了一次最大规模的架构升级，启动了“五彩石”项目，将单体应用拆分为分布式应用，同时抽象淘宝、天猫的共同底座——业务中台，包括交易中心、商品中心、买家中心等。在业务中台之下，同时诞生了阿里中间件（初期三大件包括消息、RPC、分布式数据层），RocketMQ是其中之一。 虽然在当时业界已经存在不少商业或开源的消息队列，比如IBMMQ、ActiveMQ、RabbitMQ，但无一例外，它们都诞生于传统企业级应用的场景，无法承受互联网对于高并发、无限扩展的苛刻要求。以RabbitMQ为例，RabbitMQ的队列流量与存储负载都为单机，无法满足业务横向扩展的需求。当时另一款具备无限横向扩展能力的消息队列是Kafka，但其主要用于日志类场景，未经过大规模核心业务稳定性验证，而且偏向于简单的log型消息队列，无法满足电商对于复杂消息功能特性的诉求，比如消息过滤、延迟消息等。 另一方面，传统的消息队列无法解决电商业务对于分布式一致性的要求。通过消息队列实现应用异步解耦后，电商业务还需要保障不同上下游应用对于订单状态要达成最终一致，否则会产生大量脏数据，造成业务错误。 大规模的电商系统，既要高性能又要一致性，传统的分布式事务技术束手无策。比如IBM MQ虽然可以使用XA事务来满足分布式一致性的功能诉求，但是XA带来的延迟与成本，对于海量的互联网流量难以承受。 为了解决电商业务对于消息队列的高性能、一致性、无限扩展等需求，自研消息队列成为了当时阿里唯一的出路，最终互联网消息队列RocketMQ应运而生。 为了支持超大规模的复杂电商业务，RocketMQ面向四个方面进行了重点建设，形成了四大优势能力。 ① 支撑超大规模复杂业务的能力，具备丰富的消息特性。 每一个大型互联网公司都会有主营业务（比如阿里是交易、蚂蚁是支付、饿了么是外卖），以主营业务为中心扩展业务能力，阿里电商是围绕交易事件建设的电商操作系统，每笔交易事件都会触发不同的业务，不同细分业务会关注不同类型的交易事件，比如垂直市场只关注某个类目的交易事件、天猫超市只关注某个卖家的交易事件、购物车只关注下单成功的交易事件等。 RocketMQ的SQL订阅提供灵活的消息过滤能力，能够满足下游消费者按照不同的业务维度进行消息过滤的诉求。 在大型互联网业务中，还会有各种定时事件触发场景，最典型的是交易超时关闭机制，阿里交易或者12306订票都有类似的机制。RocketMQ的定时消息能够很方便的满足这类诉求。 ② 一致性。 无论是阿里交易还是蚂蚁支付，都天然对数据一致性有着极高要求，RocketMQ在一致性方面也打造了多个关键特性。最具代表性的是分布式事务消息，RocketMQ是第一个实现该种特性的消息队列，能够保障交易的上下游对于订单状态达到最终一致。该方案也成为异步消息一致性方案的事实标准，被多个互联网公司所采纳，甚至也有公司将移植到定制版的Kafka种。除了分布式一致性之外，RocketMQ还提供了顺序消息的特性，满足顺序一致性的需求。 ③ 稳定性。 稳定性是交易与金融场景的基石特性，也是RocketMQ的根本。RocketMQ除了具备核心服务的HA之外，还具备了全局高可用能力，在阿里内部支持同城多活、异地多活、中心容灾等高阶HA能力。同时，稳定性也不局限于数据与服务的高可用，RocketMQ从产品层面对稳定性进行了全方位的建设，如消息轨迹、消息回溯、消息死信机制。 ④ 高性能。 在双十一的极限流量下，RocketMQ写消息延迟4个9在1ms内，100%在100ms内。RocketMQ采用sharednothing分布式架构，在吞吐量方面也具备无限扩展的能力，已经连续10年支持了双十一万亿级消息洪峰，为百万级的应用实例提供低延迟消息服务。互联网的故事还在进行，云计算规模化落地的时代悄然而来。 三、云计算时代的RocketMQ5.0 2015年，RocketMQ的首个云消息服务在阿里云上线，开启了大规模的云计算实践的序幕。同时RocketMQ也是业界第一个提供公有云服务的开源消息队列。 在大规模的云计算业务场景下，RocketMQ面临着全新的挑战与机遇。 多样性：它不再仅服务于某一家公司的内部业务，不再局限于互联网或金融企业，需要实现全行业、全场景的覆盖。 标准化：对于服务企业内部的自研消息队列而言，无需考虑协议或API的标准化。但是对于云消息服务而言，因为服务对象是外部企业客户，据信通院统计，80%以上的企业客户已经采纳开源技术和标准技术。因此，作为一款云消息服务，需要提供对业界的事实标准协议、接口、SDK的兼容，才能保证客户平滑上云，同时打消客户技术绑定的担忧。 云原生：云原生理念深入人心，消息队列要更好地帮助客户实现云原生应用架构，为业务降本提效。 新趋势：各种新技术的兴起，包括IoT、5G、边缘计算、事件驱动，还有事件流技术。面向技术的新趋势与多样化的业务需求，RocketMQ进行了自我进化，演进到5.0版本。 为了充分释放云的技术红利，RocketMQ5.0在技术架构上进行了云原生的演进。从客户端到服务端都进行了全方位的改造，更高弹性、可用性、更低成本。 客户端采用轻量SDK设计理念，将原来富客户端的逻辑下沉到Broker，满足现代化应用轻量化、Serverless的趋势。 Broker彻底进行弹性架构改造，分离RocketMQ Proxy与Store层，其中Proxy是完全无状态的计算节点，专注多协议、多领域场景覆盖，可以面向不同工作负载独立弹性，如物联网、微服务、大数据不同场景有不同的资源诉求。Store层则专注消息的高可用存储，包括副本复制、主备切换与云存储集成。同时对RocketMQ的Topic资源进行三层解耦，面向消息的Topic、面向流的Topic逻辑分片、面向底层存储的Topic物理分片，每一层都可以独立弹性。 在存储层引入了Leaderless的高可用架构，Store节点身份对等，Leaderless化，0外部依赖。多副本策略可定制，可用性+可靠性+成本灵活组合，面向多可用区、多region组建Geo高可用能力。 为了满足云时代多样化的用户需求，RocketMQ5.0从原来的互联网业务消息中间件扩展到"消息、事件、流"超融合处理平台，解锁更全面的能力。 在消息领域，全面拥抱云原生技术，更好的弹性架构与高可用能力。 在事件领域，支持CloudEvent规范，以事件为中心的产品新界面，助力客户建设跨业务、跨组织的数字化商业生态。 在流领域，流存储增强批量特性，大幅度提高数据吞吐量；新增逻辑队列能力，解耦逻辑资源与物理资源，在流场景也具备无缝伸缩能力；新增流数据库RSQLDB，提供实时事件流处理、流分析能力。 RocketMQ基于端云一体化架构实现了完整的物联网消息队列的能力，从原来的连接应用扩展到连接物联网设备。同时RocketMQ5.0也继续保持极简架构的原则，能够以最低的资源消耗、运维成本搭建服务，适合边缘计算。 除了的产品核心能力之外，RocketMQ5.0积极建设开源生态。 一方面是应用架构生态的建设，既有经典的开源项目、规范的集成，比如JMS、AMQP等，也有云原生技术生态的集成，比如CloudEvents、Dapr、Envoy。同时RocketMQ也会进一步发力数据架构生态，全链路集成大数据的摄入、数据存储、数据处理、数据分析组件，从离线大数据到实时大数据。 【活动】一键体验 RocketMQ 六大生产环境 免费试用+30秒一键体验，低门槛、快速、高效、易操作，带你了解“历经万亿级数据洪峰考验”的云消息队列RocketMQ！ 点击阅读原文，立即参与活动！

背景 RocketMQ 5.0版本引入了Proxy模块、无状态pop消费机制和gRPC协议等创新功能，同时还推出了一种全新的客户端类型：SimpleConsumer。SimpleConsumer客户端采用了无状态的pop机制，彻底解决了在客户端发布消息、上下线时可能出现的负载均衡问题。然而，这种新机制也带来了一个新的挑战：当客户端数量较少且消息数量较少时，可能会出现消息消费延时的情况。。 在当前的消息产品中，消费普通使用了长轮询机制，即客户端向服务端发送一个超时时间相对较长的请求，该请求会一直挂起，除非队列中存在消息或该请求到达设定的长轮询时间。 然而，在引入Proxy之后，目前的长轮询机制出现了一个问题。客户端层面的长轮询和Proxy与Broker内部的长轮询之间互相耦合，也就是说，一次客户端对Proxy的长轮询只对应一次Proxy对Broker的长轮询。因此，在以下情况下会出现问题：当客户端数量较少且后端存在多个可用的Broker时，如果请求到达了没有消息的Broker，就会触发长轮询挂起逻辑。此时，即使另一台Broker存在消息，由于请求挂在了另一个Broker上，也无法拉取到消息。这导致客户端无法实时接收到消息，即false empty response。 这种情况可能导致以下现象：用户发送一条消息后，再次发起消费请求，但该请求却无法实时拉取到消息。这种情况对于消息传递的实时性和可靠性产生了不利影响。 AWS的文档里也有描述此等现象，他们的解决方案是通过查询是所有的后端服务，减少false empty response。 其他产品 在设计方案时，首先是需要目前存在的消息商业化产品是如何处理该问题的。 MNS采取了以下策略，主要是将长轮询时间切割为多个短轮询时间片，以尽可能覆盖所有的Broker。 首先，在长轮询时间内，会对后端的Broker进行多次请求。其次，当未超过短轮询配额时，优先使用短轮询消费请求来与Broker进行通信，否则将使用长轮询，其时间等于客户端的长轮询时间。此外，考虑到过多的短轮询可能会导致CPU和网络资源消耗过多的问题，因此在短轮询超过一定数量且剩余时间充足时，最后一次请求将转为长轮询。 然而，上述策略虽以尽可能轮询完所有的Broker为目标，但并不能解决所有问题。当轮询时间较短或Broker数量较多时，无法轮询完所有的Broker。即使时间足够充足的情况下，也有可能出现时间错位的情况，即在短轮询请求结束后，才有消息在该Broker上就绪，导致无法及时取回该消息。 解法 技术方案 首先，需要明确该问题的范围和条件。该问题只会在客户端数量较少且请求较少的情况下出现。当客户端数量较多且具备充足的请求能力时，该问题不会出现。因此，理想情况是设计一个自适应的方案，能够在客户端数量较多时不引入额外成本来解决该问题。 为了解决该问题，关键在于将前端的客户端长轮询和后端的Broker长轮询解耦，并赋予Proxy感知后端消息个数的能力，使其能够优先选择有消息的Broker，避免false empty response。 考虑到Pop消费本身的无状态属性，期望设计方案的逻辑与Pop一致，而不在代理中引入额外的状态来处理该问题。 另外，简洁性是非常重要的，因此期望该方案能够保持简单可靠，不引入过多的复杂性。 1. 为了解决该问题，本质上是要将前端的客户端长轮询和后端的Broker长轮询解耦开来，并赋予Proxy感知后端消息个数的能力，能够优先选择有消息的Broker，避免false empty response。 2. 由于Pop消费本身的无状态属性，因此期望该方案的设计逻辑和Pop一致，而不在Proxy引入额外的状态来处理这个事情。 3. Simplicity is ALL，因此期望这个方案简单可靠。 我们使用了NOTIFICATION，可以获取到后端是否有尚未消费的消息。拥有了上述后端消息情况的信息，就能够更加智能地指导Proxy侧的消息拉取。 通过重构NOTIFICATION，我们对其进行了一些改进，以更好地适应这个方案的要求。 pop with notify 一个客户端的请求可以被抽象为一个长轮询任务，该轮询任务由通知任务和请求任务组成。 通知任务的目的是获取Broker是否存在可消费的消息，对应的是Notification请求；而请求任务的目的是消费Broker上的消息，对应的是Pop请求。 首先，长轮询任务会执行一次Pop请求，以确保在消息积压的情况下能够高效处理。如果成功获取到消息，则会正常返回结果并结束任务。如果没有获取到消息，并且还有剩余的轮询时间，则会向每个Broker提交一个异步通知任务。 在任务通知返回时，如果不存在任何消息，长轮询任务将被标记为已完成状态。然而，如果相关的Broker存在消息，该结果将被添加到队列中，并且消费任务将被启动。该队列的目的在于缓存多个返回结果，以备将来的重试之需。对于单机代理而言，只要存在一个通知结果返回消息，Proxy即可进行消息拉取操作。然而，在实际的分布式环境中，可能会存在多个代理，因此即使通知结果返回消息存在，也不能保证客户端能够成功拉取消息。因此，该队列的设计旨在避免发生这种情况。 消费任务会从上述队列中获取结果，若无结果，则直接返回。这是因为只有在通知任务返回该Broker存在消息时，消费任务才会被触发。因此，若消费任务无法获取结果，可推断其他并发的消费任务已经处理了该消息。 消费任务从队列获取到结果后，会进行加锁，以确保一个长轮询任务只有一个正在进行的消费任务，以避免额外的未被处理的消息。 如果获取到消息或长轮询时间结束，该任务会被标记完成并返回结果。但如果没有获取到消息（可能是其他客户端的并发操作），则会继续发起该路由所对应的异步通知任务，并尝试进行消费。 自适应切换 考虑到当请求较多时，无需采用pop with notify机制，可使用原先的pop长轮询broker方案，但是需要考虑的是，如何在两者之间进行自适应切换。目前是基于当前Proxy统计的pop请求数做判断，当请求数少于某一值时，则认为当前请求较少，使用pop with notify；反之则使用pop长轮询。 由于上述方案基于的均为单机视角，因此当消费请求在proxy侧不均衡时，可能会导致判断条件结果有所偏差。 Metric 为了之后进一步调优长轮询和观察长轮询的效果，我们设计了一组metric指标，来记录并观测实时长轮询的表现和损耗。 1. 客户端发起的长轮询次数 (is_long_polling) 2. pop with notify次数 (通过现有rpc metric统计) 3. 首次pop请求命中消息次数 (未触发notify) (is_short_polling_hit) 总结 通过如上方案，我们成功设计了一套基于无状态消费方式的实时消费方案，在做到客户端无状态消费的同时，还能够避免false empty response，保证消费的实时性，同时，相较于原先PushConsumer的长轮询方案，能够大量减少用户侧无效请求数量，降低网络开销， 产品侧 需明确长轮询和短轮询的区分，可以参考AWS的定义，当轮询时间大于0时，长轮询生效。 且需明确一个长轮询最小时间，因为长轮询时间过小时无意义，AWS的最小值采取了1s，我们是否需要follow，还是采取一个更大的值。

设计总览 RocketMQ 多级存储旨在不影响热数据读写的前提下将数据卸载到其他存储介质中，适用于两种场景： 1. 冷热数据分离：RocketMQ 新近产生的消息会缓存在 page cache 中，我们称之为热数据；当缓存超过了内存的容量就会有热数据被换出成为冷数据。如果有少许消费者尝试消费冷数据就会从硬盘中重新加载冷数据到 page cache，这会导致读写 IO 竞争并挤压 page cache 的空间。而将冷数据的读取链路切换为多级存储就可以避免这个问题； 2. 延长消息保留时间：将消息卸载到更大更便宜的存储介质中，可以用较低的成本实现更长的消息保存时间。同时多级存储支持为 topic 指定不同的消息保留时间，可以根据业务需要灵活配置消息 TTL。 RocketMQ 多级存储对比 Kafka 和 Pulsar 的实现最大的不同是我们使用准实时的方式上传消息，而不是等一个 CommitLog 写满后再上传，主要基于以下几点考虑： 1. 均摊成本：RocketMQ 多级存储需要将全局 CommitLog 转换为 topic 维度并重新构建消息索引，一次性处理整个 CommitLog 文件会带来性能毛刺； 2. 对小规格实例更友好：小规格实例往往配置较小的内存，这意味着热数据会更快换出成为冷数据，等待 CommitLog 写满再上传本身就有冷读风险。采取准实时上传的方式既能规避消息上传时的冷读风险，又能尽快使得冷数据可以从多级存储读取。 Quick Start 多级存储在设计上希望降低用户心智负担：用户无需变更客户端就能实现无感切换冷热数据读写链路，通过简单的修改服务端配置即可具备多级存储的能力，只需以下两步： 1. 修改 Broker 配置，指定使用 org.apache.rocketmq.tieredstore.TieredMessageStore 作为 messageStorePlugIn 2. 配置你想使用的储存介质，以卸载消息到其他硬盘为例：配置 tieredBackendServiceProvider 为 org.apache.rocketmq.tieredstore.provider.posix.PosixFileSegment，同时指定新储存的文件路径：tieredStoreFilepath 可选项：支持修改 tieredMetadataServiceProvider 切换元数据存储的实现，默认是基于 json 的文件存储 更多使用说明和配置项可以在 GitHub 上查看多级存储的 技术架构 architecture 接入层：TieredMessageStore/TieredDispatcher/TieredMessageFetcher 接入层实现 MessageStore 中的部分读写接口，并为他们增加了异步语意。TieredDispatcher 和 TieredMessageFetcher 分别实现了多级存储的上传/下载逻辑，相比于底层接口这里做了较多的性能优化：包括使用独立的线程池，避免慢 IO 阻塞访问热数据；使用预读缓存优化性能等。 容器层：TieredCommitLog/TieredConsumeQueue/TieredIndexFile/TieredFileQueue 容器层实现了和 DefaultMessageStore 类似的逻辑文件抽象，同样将文件划分为 CommitLog、ConsumeQueue、IndexFile，并且每种逻辑文件类型都通过 FileQueue 持有底层物理文件的引用。有所不同的是多级存储的 CommitLog 改为 queue 维度。 驱动层：TieredFileSegment 驱动层负责维护逻辑文件到物理文件的映射，通过实现 TieredStoreProvider 对接底层文件系统读写接口(Posix、S3、OSS、MinIO 等)。目前提供了 PosixFileSegment 的实现，可以将数据转移到其他硬盘或通过 fuse 挂载的对象存储上。 消息上传 RocketMQ 多级存储的消息上传是由 dispatch 机制触发的：初始化多级存储时会将 TieredDispatcher 注册为 CommitLog 的 dispacher。这样每当有消息发送到 Broker 会调用 TieredDispatcher 进行消息分发，TieredDispatcher 将该消息写入到 upload buffer 后立即返回成功。整个 dispatch 流程中不会有任何阻塞逻辑，确保不会影响本地 ConsumeQueue 的构建。 TieredDispatcher TieredDispatcher 写入 upload buffer 的内容仅为消息的引用，不会将消息的 body 读入内存。因为多级储存以 queue 维度构建 CommitLog，此时需要重新生成 commitLog offset 字段 upload buffer 触发 upload buffer 上传时读取到每条消息的 commitLog offset 字段时采用拼接的方式将新的 offset 嵌入到原消息中 上传进度控制 每个队列都会有两个关键位点控制上传进度： 1. dispatch offset：已经写入缓存但是未上传的消息位点 2. commit offset：已上传的消息位点 upload progress 类比消费者，dispatch offset 相当于拉取消息的位点，commit offset 相当于确认消费的位点。commit offset 到 dispatch offset 之间的部分相当于已拉取未消费的消息 消息读取 TieredMessageStore 实现了 MessageStore 中的消息读取相关接口，通过请求中的逻辑位点（queue offset）判断是否从多级存储中读取消息，根据配置（tieredStorageLevel）有四种策略： DISABLE：禁止从多级存储中读取消息； NOT_IN_DISK：不在 DefaultMessageStore 中的消息从多级存储中读取； NOT_IN_MEM：不在 page cache 中的消息即冷数据从多级存储读取； FORCE：强制所有消息从多级存储中读取，目前仅供测试使用。 ${a} 需要从多级存储中读取的消息会交由 TieredMessageFetcher 处理：首先校验参数是否合法，然后按照逻辑位点（queue offset）发起拉取请求。TieredConsumeQueue/TieredCommitLog 将逻辑位点换算为对应文件的物理位点从 TieredFileSegment 读取消息。 ${b} TieredFileSegment 维护每个储存在文件系统中的物理文件位点，并通过为不同存储介质实现的接口从中读取所需的数据。 ${c} 预读缓存 TieredMessageFetcher 读取消息时会预读一部分消息供下次使用，这些消息暂存在预读缓存中 ${d} 预读缓存的设计参考了 TCP Tahoe 拥塞控制算法，每次预读的消息量类似拥塞窗口采用加法增、乘法减的机制控制： 加法增：从最小窗口开始，每次增加等同于客户端 batchSize 的消息量。 乘法减：当缓存的消息超过了缓存过期时间仍未被全部拉取，在清理缓存的同时会将下次预读消息量减半。 预读缓存支持在读取消息量较大时分片并发请求，以取得更大带宽和更小的延迟。 某个 topic 消息的预读缓存由消费这个 topic 的所有 group 共享，缓存失效策略为： 1. 所有订阅这个 topic 的 group 都访问了缓存 2. 到达缓存过期时间 故障恢复 上文中我们介绍上传进度由 commit offset 和 dispatch offset 控制。多级存储会为每个 topic、queue、fileSegment 创建元数据并持久化这两种位点。当 Broker 重启后会从元数据中恢复，继续从 commit offset 开始上传消息，之前缓存的消息会重新上传并不会丢失。 开发计划 面向云原生的存储系统要最大化利用云上存储的价值，而对象存储正是云计算红利的体现。 RocketMQ 多级存储希望一方面利用对象存储低成本的优势延长消息存储时间、拓展数据的价值；另一方面利用其共享存储的特性在多副本架构中兼得成本和数据可靠性，以及未来向 Serverless 架构演进。 tag 过滤 多级存储拉取消息时没有计算消息的 tag 是否匹配，tag 过滤交给客户端处理。这样会带来额外的网络开销，计划后续在服务端增加 tag 过滤能力。 广播消费以及多个消费进度不同的消费者 预读缓存失效需要所有订阅这个 topic 的 group 都访问了缓存，这在多个 group 消费进度不一致的情况下很难触发，导致无用的消息在缓存中堆积。 需要计算出每个 group 的消费 qps 来估算某个 group 能否在缓存失效前用上缓存的消息。如果缓存的消息预期在失效前都不会被再次访问，那么它应该被立即过期。相应的对于广播消费，消息的过期策略应被优化为所有 Client 都读取这条消息后才失效。 和高可用架构的融合 目前主要面临以下三个问题： 1. 元数据同步：如何可靠的在多个节点间同步元数据，slave 晋升时如何校准和补全缺失的元数据； 2. 禁止上传超过 confirm offset 的消息：为了避免消息回退，上传的最大 offset 不能超过 confirm offset； 3. slave 晋升时快速启动多级存储：只有 master 节点具有写权限，在 slave 节点晋升后需要快速拉起多级存储断点续传。

作者简介：艾阳坤，Apache RocketMQ PMC Member/Committer，CNCF OpenTelemetry Member，CNCF Envoy contributor。 在分布式系统中，多个服务之间的交互涉及到复杂的网络通信和数据传输，其中每个服务可能由不同的团队或组织负责维护和开发。因此，在这样的环境下，当一个请求被发出并经过多个服务的处理后，如果出现了问题或错误，很难快速定位到根因。分布式全链路追踪技术则可以帮助我们解决这个问题，它能够跟踪和记录请求在系统中的传输过程，并提供详细的性能和日志信息，使得开发人员能够快速诊断和定位问题。对于分布式系统的可靠性、性能和可维护性起到了非常重要的作用。 RocketMQ 5.0 与分布式全链路追踪 Apache RocketMQ 5.0 版本作为近几年来最大的一次迭代，在整个可观测性上也进行了诸多改进。其中，支持标准化的分布式全链路追踪就是一个重要的特性。 RocketMQ 5.0 可观测 而由 Google、Microsoft、Uber 和 LightStep 联合发起的 CNCF OpenTelemetry 作为 OpenTracing 和 OpenCensus 的官方继任者，已经成为可观测领域的事实标准，RocketMQ 的分布式全链路追踪也围绕 OpenTelemetry 进行展开。 分布式链路追踪系统的起源可以追溯到 2007 年 Google 发布的论文。这篇论文详细介绍了 Google 内部使用的链路追踪系统 Dapper，其中使用的 span 概念被广泛采用，并成为后来开源链路追踪系统中的基础概念之一。 Dapper Trace Tree 在 Dapper 中，每个请求或事务被追踪时都会创建一个 span，记录整个请求或事务处理过程中的各个组件和操作的时间和状态信息。这些 span 可以嵌套，形成一个树形结构，用于表示整个请求或事务处理过程中各个组件之间的依赖关系和调用关系。后来，很多开源链路追踪系统，如 Zipkin 和 OpenTracing，也采用了类似的 span 概念来描述分布式系统中的链路追踪信息。现在，合并了 OpenTracing 和 OpenCensus 的 CNCF OpenTelemetry 自然也一样采用了 span 概念，并在此基础上进行了进一步发展。 OpenTelemetry 为 messaging 相关的 span 定义了，旨在制定一套与特定消息系统无关的 specification，而 OpenTelmetry 自身的开发其实也都是由 specification 驱动进行展开。 Specification Driven Development Messaging Span 定义 Specifaition 中描述了 messaging span 的拓扑关系，包括代表消息发送、接收和处理的不同 span 之间的父子和链接关系。关于具体的定义可以参考：。对应到 RocketMQ 中，有三种不同的 span： | Span | Description | | | | | send | 消息的发送过程。span 以一次发送行为开始，成功或者失败/抛异常结束。消息发送的内部重试会被记录成多条 span。 | | receive | 消费者中接收消息的长轮询过程，与长轮询的生命周期保持一致。 | | process | 对应 PushConsumer 里 MessageListener 中对消息的处理过程，span 以进入 MessageListener 为开始，离开 MessageListener 为结束。 | 特别地，默认情况下，receive span 是不启用的。在 receive span 启用和不启用的两种情况下，span 之间的组织关系是不同的： 启用 receive span 前后的 span 关系 在没有启用 receive span 的情况下，process span 会作为 send span 的 child；而当 receive span 启用的情况下，process span 会作为 receive span 的 child，同时 link 到 send span。 Messaging Attributes 定义 语义约定中规定了随 span 携带的通用属性的统一名称，这包括但不限于： messaging.message.id: 消息的唯一标识符。 messaging.destination：消息发送的目的地，通常是一个队列或主题名称。 messaging.operation：对消息的操作类型，例如发送、接收、确认等。 具体可以查看 。 特别地，不同的消息系统可能会有自己特定的行为和属性，，这包括： | Attribute | Type | Description | | | | | | messaging.rocketmq.namespace | string | RocketMQ 资源命名空间，暂未启用 | | messaging.rocketmq.client_group | string | RocketMQ producer/consumer 负载均衡组，5.0 只对 consumer 生效 | | messaging.rocketmq.client_id | string | 客户端唯一标识符 | | messaging.rocketmq.message.delivery_timestamp | int | 定时消息定时时间，只对 5.0 生效 | | messaging.rocketmq.message.delay_time_level | int | 定时消息定时级别，只对 4.0 生效 | | messaging.rocketmq.message.group | string | 顺序消息分组，只对 5.0 生效 | | messaging.rocketmq.message.type | string | 消息类型，可能为 normal/fifo/delay/transaction，只对 5.0 生效 | | messaging.rocketmq.message.tag | string | 消息 tag | | messaging.rocketmq.message.keys | string[] | 消息 keys，可以有多个 | | messaging.rocketmq.consumption_model | string | 消息消费模型，可能为 clustering/broadcasting，5.0 broadcasting 被废弃 | 快速开始 在 OpenTelemetry 中有两种不同的方式可以为应用程序添加可观测信息： Automatic Instrumentation：无需编写任何代码，只需进行简单的配置即可自动生成可观测信息，包括应用程序中使用的类库和框架，这样可以更方便地获取基本的性能和行为数据。 Manual Instrumentation：需要编写代码来创建和管理可观测数据，并通过 exporter 导出到指定的目标。这样可以更灵活自由地控制用户想要观测的逻辑和功能。 在 Java 类库中，前者是一种更为常见的使用形式。RocketMQ 5.0 客户端的 trace 也依托于 automatic instrumentation 进行实现。在 Java 程序中，automatic instrumentation 的表现形式为挂载 Java agent。在过去的一年里，我们将 推入了 OpenTelemetry 官方社区。现在，只需要在 Java 程序运行时挂载上 OpenTelemetry agent，即可实现对应用程序透明的分布式全链路追踪。 除此之外，Automatic Instrumentation 和 Manual Instrumentation 并不冲突，Automatic Instrumentation 中所使用的关键对象会被注册成全局对象，在 Manual Instrumentation 的使用方式中也可以非常方便的获取。实现两个 Instrumentation 共用一套配置，非常灵活和方便。 首先准备好 RocketMQ 5.0 Java 客户端，可以参考 进行消息的收发。关于 RocketMQ 5.0 的更多细节，欢迎大家参考和关注 和 。 然后准备好 OpenTelemetry agent jar，可以从 OpenTelemetry 官方，在应用程序启动时增加 javaagent:yourpath/opentelemetryjavaagent.jar 即可。可以通过设置 OTEL_EXPORTER_OTLP_ENDPOINT 环境变量来设置 OpenTelemetry collector 的接入点。 默认情况下，按照 OpenTelemetry 中关于 messaging 的规范，只有 send 和 process 的 span 会被启用，receive 的 span 是默认不启用的，如果想要启用 receive span，需要手动设置 Dotel.instrumentation.messaging.experimental.receivetelemetry.enabled=true。 场景最佳实践 目前，主流的云服务供应商都为 OpenTelemetry 提供了良好的支持，阿里云上的 SLS 和 ARMS 两款可观测产品都提供了基于 OpenTelemetry 的分布式全链路追踪服务。 为了更好地展示分布式全链路追踪的过程，这里提供了一个代码示例： 。在这个代码示例中，会启动三个不同的进程，涉及三种不同类库和业务逻辑之间的相互调用，展示了一个在分布式环境较复杂中间件之间进行交互的典型案例。 请求首先会从 gRPC 客户端发往 gRPC 服务端，在 gRPC 服务端收到请求之后，会向 RocketMQ 5.0 的 Producer 往服务端发送一条消息，然后再回复对应的 response 给客户端。在 RocketMQ 5.0 的 PushConsumer 接受到消息之后，会在 MessageListener 中使用 Apache HttpClient 往淘宝网发送一条 GET 请求。 示例代码调用链路 特别地，gRPC 客户端在发起具体的调用是在一个上游业务 span 的生命周期之内进行的，这个 span 我们称之为 ExampleUpstreamSpan，RocketMQ 5.0 PushConsumer 在收到消息之后，也会在 MessageListener 里执行其他的业务操作，也会有对应的 span，我们称之为 ExampleDownstreamSpan。那么默认在 receive span 没有启用的情况下，按照开始时间的顺序，会先后存在 7 个 span。分别是： ExampleUpstreamSpan。 gRPC 客户端请求 span。 gRPC 服务端响应 span。 RocketMQ 5.0 Producer 的 send span。 RocketMQ 5.0 Producer 的 process span。 HTTP 请求 span。 ExampleDownstreamSpan。 RocketMQ 5.0 对接 SLS Trace 服务 首先在阿里云日志服务中创建 Trace 服务。然后获取接入点，项目和实例名称等信息，具体可以参考。 在补充好信息之后完成接入之后，稍等一会就可以看到对应的 Trace 信息已经被上传到 SLS trace 服务中： SLS Trace 服务分布式全链路展示 Trace 服务其实是将相关数据存储到日志中，因此这些数据也可以通过 SLS 的 SQL 语法查询得到。 通过 Trace 数据，我们可以很方便知道用户的操作系统环境，Java 版本等一系列基础信息。消息的发送延时，失败与否，消息是否准时投递到了客户端，以及客户端本地消费耗时，消费失败与否等一系列有效信息，可以帮助我们十分有效地进行问题排查。 除此之外，SLS Trace 服务的 demo 页也提供了基于 RocketMQ 5.0 定制的消息中间件大盘，生动展示了利用 Trace 数据得到的发送成功率，端到端延时等一系列指标。 ：展示利用 Trace 数据得到的包括发送延时、发送成功率、消费成功率、端到端延时在内的一系列指标。 ：可以根据上一步得到的差错长 message id 进行进一步的细粒度查询。 消息中间件分析 RocketMQ 5.0 对接应用实时监控服务（ARMS） 首先进入应用实时监控服务 ARMS 控制台，点击接入中心中的 OpenTelemetry，选择 java 应用程序下的自动探测，获取启动参数并修改至自己的 java 应用程序，具体可以参考。 配置好参数之后，启动自己的相关应用程序，稍等一会儿，就可以在 ARMS Trace Explorer 里看到对应的数据了。 Trace Explorer 还可以查看 span 之间的时序关系。 ARMS Trace Explorer 分布式全链路追踪展示 具体地，可以点进每个 span 查看详细的 attributes/resources/events 等信息。除此之外，ARMS 还支持通过使用 OpenTelemetry Collector 转发的形式来收集应用程序的 Trace 数据。 趋势与思考 随着现代应用程序架构的不断演进，可观测性的重要性日益凸显。它不仅可以帮助我们快速发现和解决系统中的问题，还提高应用程序的可靠性和性能，同时也是实现 DevOps 的关键部分。在相关领域，也陆续诞生了像 DataDog 和 Dynatrace 这样的明星公司。 近年来涌现了一些新兴技术，如 eBPF（Extended Berkeley Packet Filter）和 Service Mesh 也为可观测领域提供了一些新的思路： eBPF 可以在内核层面运行，通过动态注入代码来监控系统的行为。它被广泛应用于实时网络和系统性能监控、安全审计和调试等任务，并且性能影响很小，未来也可以作为 continuous profiling 的一种选择。Service Mesh 则通过在应用程序之间注入代理层实现流量管理、安全和可观测性等功能。代理层可以收集和报告有关流量的各种指标和元数据，从而帮助我们了解系统中各个组件的行为和性能。 Service Mesh 中反映出的技术趋势很大一部分已经在 RocketMQ 5.0 proxy 中得到了应用，我们也在更多地将可观测指标往 proxy 进行收敛。当前的 Trace 链路未来也在考虑和服务端一起进行关联，并打造用户侧，运维侧，跨多应用的全方位链路追踪体系。除此之外还可以将 Trace 数据与 Metrics 数据通过 Exemplars 等技术进行联动。实现面到线，线到点的终极排查效果。 在可观测领域，RocketMQ 也在不断探索和摸索更加领先的可观测手段，以帮助开发者和客户更快更省心地发现系统中的隐患。 特别感谢阿里云 SLS 团队的千乘同学和 ARMS 团队的垆皓同学在接入过程提供的帮助和支持！ 相关链接 RocketMQ 5.0 客户端： OpenTelemetry Instrumentation for RocketMQ 5.0： RocketMQ OpenTelemetry 示例：

阿里云消息队列 RocketMQ 版是阿里云基于 Apache RocketMQ 构建的低延迟、高并发、高可用、高可靠的分布式“消息、事件、流”统一处理平台，面向互联网分布式应用场景提供微服务异步解耦、流式数据处理、事件驱动处理等核心能力。其自诞生以来一直为阿里集团提供稳定可靠的消息服务，历经多年双十一万亿级流量洪峰的验证。 随着业务需求场景日渐丰富，在多年经验积累后，阿里云 RocketMQ 也迎来了革命性的更新，正式发布了阿里云消息队列 RocketMQ 版 5.0，在架构、网络、负载均衡、存储等诸多方面进行了显著优化。其定位不再局限于消息解耦场景，将全新布局事件驱动和消息流式处理场景。 阿里云 EventBridge 作为云上事件枢纽一直以来都保持着对云上事件、数据的友好生态支持。随着 RocketMQ 5.0版本的用户日渐增多，EventBridge 在近期对 RocketMQ Connector 进行了全面升级。升级之后的 RocketMQ Connector 不仅可以支持RocketMQ 5.0 版本，同时也能支持云上自建 RocketMQ 实例。除此之外，基于成熟的事件流能力，用户使用 EventBridge 也能轻松构建消息路由能力，实现对灾备、数据同步的需求。 本文将从业务架构和 API 使用等方面讲解如何使用 EventBridge 创建阿里云 RocketMQ 4.0、5.0 版本，开源自建版本以及消息路由的相关任务。 EventBridgeRocketMQ 4.0 业务架构 RocketMQ 4.0 版本使用较为经典的 clientnameserverbroker 架构，整个应用主要由生产者、消费者、NameServer 和 Broker 组成。 Name Server：是一个几乎无状态节点，可集群部署，在消息队列 RocketMQ 版中提供命名服务，更新和发现 Broker 服务。 Broker：消息中转角色，负责存储消息，转发消息。分为 Master Broker 和 Slave Broker，一个 Master Broker 可以对应多个 Slave Broker，但是一个 Slave Broker 只能对应一个 Master Broker。Broker 启动后需要完成一次将自己注册至 Name Server 的操作；随后每隔 30s 定期向 Name Server 上报 Topic 路由信息。 生产者：与 Name Server 集群中的其中一个节点（随机）建立长连接（Keepalive），定期从 Name Server 读取 Topic 路由信息，并向提供 Topic 服务的 Master Broker 建立长连接，且定时向 Master Broker 发送心跳。 消费者：与 Name Server 集群中的其中一个节点（随机）建立长连接，定期从  Name Server 拉取 Topic 路由信息，并向提供 Topic 服务的 Master Broker、Slave Broker 建立长连接，且定时向 Master Broker、Slave Broker 发送心跳。Consumer 既可以从 Master Broker 订阅消息，也可以从 Slave Broker 订阅消息，订阅规则由 Broker 配置决定。 EventBridge在获取用户授权之后，利用生成的 sts 临时授权对客户的  RocketMQ 实例进行消息读取或写入。 API 使用 在 API 介绍方面，我们以创建「自定义总线自定义事件源」为例，事件目标以及事件流中的API基本一致。 基于 EventBridge 创建 RocketMQ 4.0 任务的 API 和之前基本保持了一致。具体参数如下 版本：代表阿里云消息队列 RocketMQ 版本，可选择 4.x 或 5.x； RocketMQ 实例：RocketMQ 对应的实例 ID。用户在阿里云 RocketMQ控制台每创建一个实例都会有一个对应的实例 ID，如MQ_INST_123456789_BX6zY7ah； Topic：RocketMQ Topic。选择此 topic 作为事件源的读取对象或者事件目标的写入对象； Tag：RocketMQ 消费 Tag，用于消费者过滤消息使用； Group ID：RocketMQ 消费组，标识一组特定的消费者，仅事件源有此参数； 消费位点：初始消费位点。可选择最新位点、最早位点、或者指定时间戳。 EventBridgeRocketMQ 5.0 业务架构 RocketMQ 5.0 版将通用的存储逻辑下沉，集中解决消息存储的多副本、低延迟、海量队列分区等技术问题，将上层的消息处理剥离出完全的无状态计算层，主要完成协议适配、权限管理、消费状态、可观测运维体系支持，Broker 则继续专注于存储能力的持续优化。存算分离的架构设计，使得从 SDK 接入到线上运维全链路带来全面提升： 1. 轻量版 SDK 的开放和全链路可观测系统的提升：同时支持 4.x 通信协议和全新的 gRPC 通信协议，并内置 OpenTelemetry 埋点支持，新版本 SDK 新增了 10 余个指标埋点。 2. 消息级负载均衡：新版本 SDK 不再参与实际存储队列的负载均衡，消息负载均衡将更加轻量，以单条消息为调度最小单元。 3. 多网络访问支持：新版本支持单一实例同时暴露公网、内网等访问形式，方便客户多网络接入访问。 4. 海量分级存储：新版本开放分级存储历史消息保存能力，消息低成本无大小限制，最长保存 30 天。冷热数据进行分离设计，极大降低消费历史消息对实例的性能影响。 RocketMQ 5.0 版本 可以支持 VPC 内部安全识别，用户上云无需修改代码。在用户授予 EventBridge 网络和 RocketMQ 相关权限之后，用户在 EventBridge 创建 MQ 5.0 Source&Sink 任务的时，EventBridge 会根据 RocketMQ 5.0 实例的 VPC 信息，调用网络组件获取相应代理信息。MQ sdk 侧通过配置代理实现消息的收发。 API 使用 相比于 4.0 实例，5.0 实例多了 VPC、交换机和安全组 3 个参数。 5.0 实例新增了 VPC 属性，用户需要在对应 vpc 内去访问 MQ 5.0 实例。EventBridge 在获得用户授权之后，也是经由 5.0 实例对应的 VPC 内进行消息的收发。创建任务时前端会自动填充好实例的 vpc 和交换机信息。 安全组参数限制了 EventBridge 在 vpc 内的访问策略，用户可以选择使用已有安全组也可以选择快速创建，让 EventBridge 快速创建一个安全组供任务使用。安全组策略推荐使用默认的安全组策略。使用上推荐第一次在此vpc内创建任务时，使用 EventBridge 自动创建一个安全组，后续在此 VPC 内再创建其他任务时，在使用已有中选择 EventBridge 创建的安全组。 EventBridge自建 Apache RocketMQ 针对用户在阿里云自建 Apache RocketMQ 集群的场景，EventBridge 也支持了消息导出能力。用户通过配置接入点、topic、groupID、VPC 等信息，即可将自建集群中的消息导入 EventBridge，进而对接 EventBridge 目前支持的大量下游生态。 业务架构 抽象来看，EventBridge 访问自建 MQ 实例的链路和阿里云 5.0 版本基本一致，都是从用户 vpc 发起对 MQ 实例的访问。区别在于接入点的不同，前者是用户自建 MQ 集群的nameserver，而后者为阿里云 RocketMQ 提供的接入点，不需要感知真实的 MQ 集群是部署在用户 vpc 还是阿里云 RocketMQ 自身的生产环境。 API 使用 在 API 使用方面，自建集群的大部分参数需要用户手动填入。 接入点：nameserver 地址。后续会支持 proxy 地址； Topic：RocketMQ Topic。选择此 topic 作为事件源的读取对象或者事件目标的写入对象； Tag：RocketMQ 消费 Tag，用于消费者过滤消息使用； Group ID：RocketMQ 消费组，标识一组特定的消费者，仅事件源有此参数； FilterType：过滤模式，目前支持 Tag 过滤； 认证模式：如果开启 ACL 鉴权，可在此配置鉴权信息； 消费位点：初始消费位点； VPC：自建 MQ 集群对应的 VPC 参数信息； 交换机：自建 MQ 集群对应的交换机信息； 安全组：EventBridge使用此安全组访问用户自建 MQ 集群，安全组规定了 EventBridge 在此 vpc 内的访问策略。 RocketMQ 消息路由 当用户有灾备或者消息同步的需求时，可能就会需要消息路由能力，即将 A region 下某实例 topic 的消息同步到 B region 的某 topic 中。 对于 EventBridge 而言，消息路由并非单独的一个产品能力，用户通过使用事件流即可实现消息路由。 针对非跨境场景的消息路由，如从北京同步消息到上海，跨 region 网络打通能力由 EventBridge 来实现，用户无需关注过多实现细节。 针对跨境场景，如北京同步消息到新加坡，EventBridge 使用的是公网链路完成对目标实例的写入，使用的是目标 MQ 实例的公网接入点。消息出公网的能力需要用户提供，即需要用户提供 VPC、交换机和安全组配置，此VPC须带有NAT等访问公网能力， EventBridge 使用此 VPC 实现写入目标端公网接入点。 在 API 使用方面，创建消息路由任务本质上是创建事件流，API 参数和上面各类型 RocketMQ 实例任务一致，这里以创建一个青岛到呼和浩特的 RocketMQ 消息路由为例。 1.进入 EventBridge 控制台，regionBar 选择到呼和浩特，点击左侧“事件流”，然后选择“创建事件流”。 2.在事件源页面，事件提供方选择“消息队列 RocketMQ 版”，地域选择青岛，剩余 RocketMQ 相关参数按需求选择。 3.规则页面按需填写，这里选择默认内容。 4.在“目标”页面，服务类型选择“消息队列 RocketMQ 版”，剩余参数按需填写。 5.点击“创建”，等待事件流任务启动即可。 总结 本文介绍了 EventBridge 对接各类型 RocketMQ 实例的基本原理与对应的 API 使用说明，便于已经使用了 RocketMQ 5.0 版本和自建 MQ 实例的用户可以借助 EventBridge 的能力实现事件驱动业务架构的搭建。同时针对灾备和业务消息同步的场景，本文也基于事件流讲解了如何基于 EventBridge 创建 RocketMQ 消息路由任务。

引言 事件总线 EventBridge 是阿里云提供的一款无服务器事件总线服务，支持阿里云服务、自定义应用、SaaS 应用以标准化、中心化的方式接入，并能够以标准化的 CloudEvents 1.0 协议在这些应用之间路由事件，帮助您轻松构建松耦合、分布式的事件驱动架构。事件驱动架构是一种松耦合、分布式的驱动架构，收集到某应用产生的事件后实时对事件采取必要的处理后路由至下游系统，无需等待系统响应。使用事件总线 EventBridge 可以构建各种简单或复杂的事件驱动架构，以标准化的 CloudEvents 1.0 协议连接云产品和应用、应用和应用等。 目前 HTTP 的不足有以下几点： HTTP 的能力较弱，比如：授权方式单一、只支持 Body 传参、网络互通能力未对齐。只能满足客户最简单的场景。 用户无法基于 API 来统一管理（修改/下线）Target，用户体验交叉口； 对于基于 HTTP 实现的 SaaS API，无法简单快捷的引入到 EB 中，作为 Target 给用户使用。 本次新增集成中心（Integration Center）是负责 EventBridge 与外界系统对接的模块，通过抽象与配置快速获取第三方事件并将事件集成到第三方系统。并且优化现有 HTTP Sink 集成方案，为用户下游集成创造更多适配场景。 集成中心重点服务对象包括但不限于 SaaS 系统，对标 IPaaS 平台的能力提供完整的全面的通用系统集成方案。 集成源（Integration Source）：指集成到 EventBridge 的第三方源； API 端点（API Destination ）：指被集成到 EventBridge 的第三方 API 端点； 连接配置（Connection）：是 API 端点模块的子集，与API 端点的平级资源，主要负责记录连接及配置信息，连接配置可被任意 API 端点复用。 针对市场上其他云厂商服务，EventBridge 发布了 API 端点 Sink 能力，主要作用在于承接 EventBridge 下游端数据，帮助用户快速完成下游数据集成。提供简单且易于集成的三方事件推送 ，帮助客户更加高效、便捷地实现业务上云。 API 端点 Sink 概述 接入 EventBridge 应用有多种情况：用户自定义应用、阿里云服务、其他云厂商服务或者其他 DB 产品。 具体而言，API 端点 Sink 事件目标是 EventBridge 支持的事件目标的一种，是通过 EventBridge 将数据投递至指定 Web Server 中。 API 端点 Sink 基本使用 首先现阶段 API 端点的 Sink 支持三种鉴权方式： 同时网络支持公网和专有网络（后续支持）。 1、创建 Connection 添加连接配置基本信息，并配置鉴权。 链接配置支持三种鉴权方式 ： Basic 鉴权方式 ： OAuth 2.0 鉴权方式： 添加授权接入点、授权请求方式、Client ID、ClientSecret 和授权相关的 Http 请求参数。 API Key 鉴权方式： 2、创建 ApiDestination API 端点配置 ：配置需要访问 API 的 URL 地址和 HTTP 调用类型。 添加请求地址和请求方式： 在创建 API 端点时可以直接创建连接配置也可以选择已有的连接配置，例如上面已经创建成功的连接配置。 3、创建 Rule 创建事件规则，用于将事件投递到具体的 API 端点中。 步骤一 ：点击事件规则并创建事件规则 步骤二 ：是选择事件源，可以选择阿里云官方的或者选择自定义事件源，这里选择的是自定义事件源 步骤三 ：第三步是选择 API 端点事件目标 支持自定义创建和使用已有，同时可以添加请求 HTTP 参数。 使用已有 使用选择已有的以后只需要添加请求 HTTP 参数即可： 选择已有的 API 端点来自于集成中心下面的 API 端点： 最佳实践 常见场景案例，比如： 用户可以把 RocketMQ 或者 RabbitMQ 的消息产品的消息动态投递到不同的 Web Server 中，这样可以让不同的 web 平台处理消息数据，实现了跨平台或者跨语言的消息流通。 用户可以把日志服务 SLS 数据投递到指定的 Web Server 或者 ELK 中，方便业务部门或者大数据平台对日志数据处理，可以更好的完善用户画像和用户行为分析，方便给用户打标签，从而可以进一步完善大数据个性化用户推荐系统。 例如下面是访问的国内外 SaaS 生态： 典型场景 ：与 Buildkite 集成 场景介绍 ：利用 EventBridge 丰富的云产品事件源和目标集成能力，快速与 Buildkite 的持续集成和持续交付（CI / CD）平台进行集成。 集成产品背景描述 ：Buildkite 是大型持续集成和持续交付（CI / CD）平台会有各种管理的变更、构建和作业等任务，运维人员需要快速感知、处理这些变更，以便决赛风险。 用户痛点 ：构建的事件收集困难，需要手动触发构建和手动创建管道。 方案优势 ：EventBridge 支持集成 Buildkite 的持续集成和持续交付平台，用户只需要简单配置即可创建和处理平台的事件。 举例介绍：可以通过 API 文档中提供的接口实现动态的创建管道、创建构建和重试作业等。 文档地址 ： 创建 API 端点 创建规则 发布事件，发布完成以后可以到事件轨迹查询详情 典型场景 ：与 Freshdesk 集成 场景介绍 ：利用 EventBridge 丰富的云产品事件源和目标集成能力，快速与 CRM（Freshdesk）进行集成。 集成产品背景描述 ：不同的平台都需要对接 CRM（Freshdesk）管理系统。 用户痛点 ：不同的平台的事件收集困难，需要用户自定义实现。 方案优势 ：EventBridge 支持集成 CRM（Freshdesk）平台，用户只需要简单配置即可实现动态的创建会话、创建联系人和创建技能等事件。 举例介绍：可以通过 API 文档中提供的接口实现动态的创建会话、创建联系人和创建技能等。 文档地址 ： 创建 API 端点 创建事件规则 发布事件，发布完成以后可以到事件轨迹查询详情 典型场景 ：与有成财务集成 场景介绍 ：利用 EventBridge 丰富的云产品事件源和目标集成能力，快速与有成财务进行集成 集成产品背景描述 ：不同的 HR 系统或者 OA 系统需要对接有成财务时 用户痛点 ：不同的系统的事件收集困难，需要用户自定义实现 方案优势 ：EventBridge 支持集成有成财务平台，用户只需要简单配置即可实现动态生成报销科目和财务凭证等事件 举例介绍：比如用户想把 mns 的消息或者其他消息产品，同步到钉钉产品等接口中，或者也可以利用消息生成报销单据，可以生成报销科目和财务凭证等 地址 ： 创建 API 端点 创建规则 发布事件，发布完成以后可以到事件轨迹查询详情。

本文主要向大家介绍如何利用 RocketMQ 可观测体系中的指标监控，对生产环境中典型场景：消息堆积、消息收发失败等场景配置合理的监控预警，快速发现问题，定位问题。 RocketMQ 可观测体系 作为一款典型的分布式中间件产品，RocketMQ 被广泛应用于业务核心链路中，每条消息都关联着核心业务数据的变化。业务链路有其明显的复杂性： 生产者、消费者多对多：业务调用链路网状结构，上下游梳理困难 上下游解耦、异步链路：异步化调用，信息收集不完整 消息是状态数据：未消费成功、定时中等状态增加排查的复杂度 消息链路耦合复杂的业务处理逻辑：无法快速定位问题边界 鉴于消息链路耦合业务系统，复杂带状态，RocketMQ 通过强大的可观测系统和经验支撑，及时发现问题、定位问题、解决问题有助于提升运维效率，对于业务运行是一项重要的保障能力。 RocketMQ 的可观测体系主要由指标（Metrics）、轨迹（Tracing）和日志（Logging）组成。 指标 RocketMQ中定义了详细的Metrics指标，这些指标覆盖生产者、消费者、服务端及消息收发关键接口和流程的统计数据，并支持从实例、Topic和Group等多个维度进行聚合展示，帮助您实时监控消息业务或RocketMQ服务的运行状态。和4.x版本相比，RocketMQ服务端5.x版本增加了消息堆积场景相关指标、关键接口的耗时指标、错误分布指标、存储读写流量等指标，帮助您更好地监控异常场景。 消息轨迹 在分布式应用中，RocketMQ作为全链路中异步解耦的关键服务，提供的Tracing数据可有效将业务上下游信息串联起来，帮助您更好地排查异常，定位问题。和4.x版本相比，RocketMQ服务端5.x版本支持OpenTelemetry开源标准，提供更加丰富的轨迹指标，针对消费场景、高级消息类型场景等细化轨迹内容，为问题定位提供更多关键信息。 日志 RocketMQ为不同的异常情况定义唯一的错误码及错误信息，并划分不同的错误级别，您可以根据客户端返回的错误码信息快速获取异常原因。和4.x版本相比，RocketMQ服务端5.x版本统一了ErrorCode和ErrorMessage，异常日志中增加了RequestID、资源信息，细化了错误信息，保证日志内容明确靠。 RocketMQ 监控告警介绍 RocketMQ 联合阿里云云监控提供了开箱即用且免费的监控报警服务，可帮助您解决如下问题： 实例规格水位监控预警 若您实际使用的指标值超过实例的规格限制，RocketMQ会进行强制限流。提前配置实例规格水位告警可以提前发现规格超限风险并及时升配，避免因限流导致的业务故障。 业务逻辑错误监控预警 您在消息收发时可能会收到异常报错，配置调用错误告警可以提前在业务反馈前发现异常，帮助您提前判断异常来源并及时修复。 业务性能指标监控预警 如果您的消息链路有相关性能指标要求，例如RT耗时、消息延迟等，提前配置业务指标告警可以帮助您提前治理业务风险。 RocketMQ 版提供了丰富的 Metric 指标和告警监控项。各监控项可分为运行水位、收发性能、异常错误事件三类告警。根据大量生产环境实践经验，建议您根据以下原则配置如下告警 接下来重点通过消息堆积和消息收发失败这两个典型场景来阐述基于可观测体系中的指标（Metrics），RocketMQ 如何通过云监控创建监控规则，将关键的 Metrics 指标作为告警项，帮助您自动监控服务的运行状态，并自动发送报警通知， 便于您及时预警服务的异常信息，提高运维效率。 应用场景1：消息堆积问题 消息堆积指标及监控配置 业界通用指标：使用消息堆积量（ready + inflight）来度量消费健康度，表示未处理完成的消息量；部分产品额外增加已就绪消息量来度量消息拉取的及时性；使用上述 2 个指标直接来配置报警有以下缺点： 有误报或无法触发报警的问题 及时性的间接指标，不直观 RocketMQ 指标：额外支持延时时间来度量消费健康度，涵盖了所有业务场景，根据业务容忍延迟度直接配置时间告警阈值。 消息处理延迟时间：表示业务处理完成及时度 已就绪消息排队时间：表示拉取消息及时度 建议对消息堆积敏感的用户，都在 RocketMQ 实例页的监控报警，添加如下报警指标，并设置符合业务需求的阈值。 如何定位和处理堆积问题 假如收到堆积报警，确认消息出现堆积情况，可参考以下措施进行定位和处理。 1. 判断消息堆积在 RocketMQ 服务端还是客户端 查看客户端本地日志文件 ons.log，搜索是否出现如下信息：the cached message count exceeds the threshold 出现相关日志信息，说明客户端本地缓冲队列已满，消息堆积在客户端，请执行步骤2。 若未出现相关日志，说明消息堆积不在客户端，若出现这种特殊情况，请直接提交工单联系阿里云技术支持。 2. 确认消息的消费耗时是否合理 若查看到消费耗时较长，则需要查看客户端堆栈信息排查具体业务逻辑，请执行步骤3。 若查看到消费耗时正常，则有可能是因为消费并发度不够导致消息堆积，需要逐步调大消费线程或扩容节点来解决。 消息的消费耗时可以通过以下方式查看： 查看消费者状态，在客户端连接信息中查看业务处理时间，获取消费耗时的平均值。 3. 查看客户端堆栈信息。只需要关注线程名为 ConsumeMessageThread 的线程，这些都是业务消费消息的逻辑。 客户端堆栈信息可以通过以下方式获取：查看消费者状态，在客户端连接信息中查看 Java 客户端堆栈信息 使用 Jstack 工具打印堆栈信息。 常见的异常堆栈信息如下： 消费逻辑有抢锁休眠等待等情况。消费线程阻塞在内部的一个睡眠等待上，导致消费缓慢。 示例一： 消费逻辑操作数据库等外部存储卡住。消费线程阻塞在外部的 HTTP 调用上，导致消费缓慢。 示例二： 4. 针对某些特殊业务场景，如果消息堆积已经影响到业务运行，且堆积的消息本身可以跳过不消费，您可以通过重置消费位点跳过这些堆积的消息从最新位点开始消费，快速恢复业务。 如何避免消息堆积 为了避免在业务使用时出现非预期的消息堆积和延迟问题，需要在前期设计阶段对整个业务逻辑进行完善的排查和梳理。整理出正常业务运行场景下的性能基线，才能在故障场景下迅速定位到阻塞点。其中最重要的就是梳理消息的消费耗时和消息消费的并发度。 梳理消息的消费耗时通过压测获取消息的消费耗时，并对耗时较高的操作的代码逻辑进行分析。梳理消息的消费耗时需要关注以下信息： 消息消费逻辑的计算复杂度是否过高，代码是否存在无限循环和递归等缺陷。 消息消费逻辑中的 I/O 操作（如：外部调用、读写存储等）是否是必须的，能否用本地缓存等方案规避。外部 I/O 操作通常包括如下业务逻辑： 读写外部数据库，例如 MySQL 数据库读写。 读写外部缓存等系统，例如 Redis 读写。 下游系统调用，例如 Dubbo 调用或者下游 HTTP 接口调用。 消费逻辑中的复杂耗时的操作是否可以做异步化处理，如果可以是否会造成逻辑错乱（消费完成但异步操作未完成）。 设置消息的消费并发度 逐步调大线程的单个节点的线程数，并观测节点的系统指标，得到单个节点最优的消费线程数和消息吞吐量。 得到单个节点的最优线程数和消息吞吐量后，根据上下游链路的流量峰值计算出需要设置的节点数，节点数=流量峰值/单线程消息吞吐量。 应用场景2：消息收发失败问题 消息收发的核心流程 从上图中可以看出消息收发都要先从 NameServer 返回路由，再通过 broker 的鉴权以及实例规格是否超限的判断，才能进行正常收发消息。根据经验检消息收发失败的原因有如下情况： API 请求频率是否超过实例规格限制 查网络是否正常 服务端是否是有重启造成的短期收发失败 操作资源是否有权限 常见的消息收发失败异常 在无论开发阶段还是生产运行阶段，遇到收发失败问题，我们都可以从客户端日志出发进行排查。以下列举下常见的消息收发失败异常场景： 1. 在客户端日志中出现ClusterName consumer groupId consumer topic messages flow control, flow limit threshold is , remainMs 异常信息 原因：RocketMQ 每个实例都明确了消息收发 API 调用 TPS，例如，标准版实例支持每秒 5000 次 API 调用，若实例消息收发 API 调用频率超过规格限制，会导致实例被限流。实例被限流后，导致部分消息收发请求失败。 建议措施： 1. 配置实例 API 调用频率监控告警 建议设置为规格上限的 70%。例如，您购买的实例消息收发 TPS 上限为 10000，则告警阈值建议设置为 7000。 1. 配置限流次数告警 RocketMQ 支持将指定实例触发限流的事件作为监控项，通过对限流次数的监控，可以帮助您了解当前业务的受损情况。 2. 在客户端日志中出现RemotingConnectException: connect to failed 或者 RemotingTimeoutException 等异常信息。 可能有如下原因： MQ 服务升级过程中 , 会出现短暂的网络闪断，查看官网公告看是否在服务升级窗口 检查应用服务器到broker的网络是否通畅，是否有网络延迟 检查应用的网络带宽情况，是否被打满 确认下应用是否出现 FGC 现象，FGC 会造成一定的网络延迟 3. 在客户端日志当中出现 system busy, start flow control for a while 或者 broker busy, start flow control for a while等异常信息。 可能原因：共享集群 broker（出现网络，磁盘，IO 等抖动）压力大，造成消息收发出现排队现象；若是偶尔短暂抖动，此类错误 SDK 会自动重试，但建议在自己的业务代码做好异常处理，当自动重试次数超限仍失败情况下，业务根据需要做好容灾。若长时间持续出现，可以提工单让技术人员跟进排查。

以“深入数字经济·洞见技术价值”为主题的【InfoQ 2022 中国技术力量年终榜单】正式公布获奖名单。其中，Apache RocketMQ以其卓越的易用性、社区活跃性、成熟度、产品优越性、代码健康度等荣获【2022 年度十大开源新锐项目】。 作为主流的分布式消息中间件，RocketMQ于 2012 年开源，并在 2017 年正式成为 Apache 顶级项目，持续迸发出旺盛的生命力。 伴随着云原生时代的到来以及实时计算的兴起， 生于云、长于云的 RocketMQ 5.0 应运而生，全新升级为云原生消息、事件、流融合处理平台，帮助用户更容易地构建下一代事件驱动和流处理应用。RocketMQ 5.0 专注于消息基础架构的云原生化演进，聚焦在消息领域的后处理场景，支持消息的流式处理和轻计算，帮助用户实现消息的就近计算和分析，并全面拥抱 Serverless 和 EDA。 在技术迎来重要革新的同时，回顾 Apache RocketMQ 社区这些年的成长历程。目前，全球 Apache RocketMQ Contributors  700+，促进整个社区长期和健康发展。同时，为了帮助社区开发者更好地找到感兴趣的技术方向，快速参与到社区并推动相关特性优化的快速演进，RocketMQ 还成立内核、批处理、Connect、Streaming、多语言客户端、RocketMQFlink、Operator、Exporter 等不同兴趣小组。 为更好聚集本地开发者，我们在北京、深圳、苏州等城市相继成立当地社区，定期举行线下活动，共同讨论 RocketMQ 相关的落地实践与新特性需求，大量创新从社区的各类活动中产生并且落地。除此之外，RocketMQ 还非常重视社区间的合作，先后与 Apache DolphinScheduler，Apache Hudi 等社区组织了多次联合 Meetup，在打造 RocketMQ 上下游生态的同时，也为不同社区开发者近距离讨论提供了平台。 在社区成员以及众多的开发者共同推动下，全球超过数万家企业在使用 Apache RocketMQ，这其中不仅有字节跳动、快手、小米、滴滴、同城艺龙等互联网头部企业，还有众多银行、券商、保险，基金公司等金融公司。经过多年发展，RocketMQ 已成为微服务领域业务消息首选。 本次获奖离不开全体社区成员的共同努力，是全体社区成员的共同荣誉！社区将再接再厉，不忘初心，持续促进  Apache RocketMQ 项目和社区的持续发展。