共计 8462 个字符，预计需要花费 22 分钟才能阅读完成。
简介：明天分享的主题是云原生音讯事件流超交融平台 RocketMQ 5.0 初探，内容次要分为三个局部：首先，带大家回顾业务音讯畛域首选 RocketMQ 4 倒退历史以及 4.x 版本的演进与倒退。其次，会为大家具体介绍 RocketMQ 5.0 倒退状况以及一些新个性。最初，会为大家介绍 RocketMQ 5.0 的倒退路线图，不便社区小伙伴可能一起参加进来到 5.0 的奉献中来。
前言：本文整顿自 RocketMQ x EventMesh OpenDay 金融通演讲内容
作者 | 金融通
明天分享的主题是云原生音讯事件流超交融平台 RocketMQ 5.0 初探，内容次要分为三个局部：
首先，带大家回顾业务音讯畛域首选 RocketMQ 4 倒退历史以及 4.x 版本的演进与倒退。
其次，会为大家具体介绍 RocketMQ 5.0 倒退状况以及一些新个性。
最初，会为大家介绍 RocketMQ 5.0 的倒退路线图，不便社区小伙伴可能一起参加进来到 5.0 的奉献中来。
RocketMQ 倒退历程
RocketMQ 自诞生以来前后经验了四代架构，并随同着企业 IT 架构一直倒退，从 SOA 时代到微服务时代，再到现在的云原生时代。RocketMQ 最早诞生于阿里巴巴，阿里巴巴晚期有一些自研的音讯引擎，比方淘宝的 Notify、B2B 业务的 Napoli。但无论是 Napoli 还是 Notify，都是基于关系型数据库进行存储并带来了一些隐患。
所以在 2011 年，阿里巴巴以文件系统作为存储研发了 MetaQ。通过一直摸索，在重写 MetaQ 2.0 后，第一代 RocketMQ 正是诞生，并将其命名为 RocketMQ 3.0。2013 年，阿里巴巴对 RocketMQ 进行开源，并在 2016 年募捐给 Apache 社区。2017 年，RocketMQ 从 Apache 毕业，正式成为 Apache 基金会顶级开源我的项目。
随着 RocketMQ 进入 Apache 基金会，RocketMQ 4.x 进行疾速倒退，也公布了十分多版本，在架构多正本能力、音讯类型、音讯治理方面都有了十分微小的飞跃。与此同时，社区生态也茁壮成长，寰球 Contributor 数靠近 500 人。
随同着云原生时代到来，以及实时计算的衰亡，RocketMQ 也将进行全面降级，公布 RocketMQ 5.0。咱们和社区小伙伴们将 RocketMQ 5.0 定义为云原生的音讯、事件、流的超交融平台。
RocketMQ 4 回顾
回顾 RocketMQ 4，咱们始终在强调 RocketMQ 是业务音讯首选。十分多公司将 RocketMQ 用于外围交易链路上，甚至很多公司会搭建两套音讯零碎，一套 Kafka 进行数据分析，另一套 RocketMQ 用于业务音讯解决。
那为什么 RocketMQ 会为成为泛滥企业的统一抉择呢，从以下几点，兴许能一窥到底：
第一，RocketMQ 是金融级高牢靠的产品。相比于其余消息中间件，RocketMQ 通过超大规模验证。阿里巴巴简直所有音讯链路都是建设在 RocketMQ 之上，包含外围交易链路。比方双十一当天 RocketMQ 反对了超过数万亿条音讯的流转，与此同时，在阿里云上的音讯服务也服务了数万家企业。这些规模宏大的企业对 SLA 同样有着极高的要求。而这些本身实际以及客户服务的大量实在场景打磨对于音讯零碎的稳定性起到了至关重要的作用。
第二，RocketMQ 有着极简的架构并且易于保护，整个集群由 NameServer、Broker 两局部组成，NameServer 进行路由发现，Broker 作为理论存储数据的集群。从架构图中能够看到，RocketMQ 采纳两主两备的集群形式，从节点通过同步复制或者异步复制的形式向主节点同步数据。这样的部署模式保障了服务可能具备较高可用性。
通过部署多组 Broker，即便其中一组 Broker 的 Master 呈现不可用，也能够发送音讯给其余组 Master，Consumer 也能从 Slave 进行读取。而 NameServer 处于齐全无状态，即便 NameServer 全副宕机，因为客户端已保留路由信息，所以也不会影响存量服务。此外，RocketMQ 的运维也非常容易，扩容时只有减少 Broker 组数即可。如果一组 Broker 呈现问题，也能够将它进行禁写，路由会马上被摘掉，不会影响其余业务。
RocketMQ 部署也非常简单，JAR 部署只须要两行命令就能把 RocketMQ 进行拉起。在 K8s 上部署就更加简略，如果用了 RocketMQ Operator，用一句 kubectl apply 命令就能将整个集群拉起来。
第三，是丰盛的音讯类型，RocketMQ 反对一般音讯、程序音讯、提早音讯、重试音讯、死信音讯、事务音讯等。在音讯治理方面，RocketMQ 除了常见的订阅模式，播送模式、集群模式，还反对音讯查问，音讯回放，音讯轨迹，ACL 权限管制等。此外，RocketMQ 也是业界少有的原生反对服务端过滤的音讯产品，能够提供给用户更加丰盛的应用场景，也能够充分利用服务端计算资源。RocketMQ 不仅反对音讯的 Tag 过滤，还创新性地反对 SQL92 过滤，Tag 过滤其实曾经满足了绝大部分的过滤需要，如果特地简单的场景能够思考 SQL92 过滤形式，两个过滤形式基本上能够满足所有音讯过滤需要。相比于其余消息中间件而言，RocketMQ 的音讯类型和音讯治理是最丰盛的。
最初 RocketMQ 具备高吞吐低延时的个性。在阿里巴巴双十一中，RocketMQ 撑持万亿级洪峰并放弃毫秒级响应。
接下来，带大家回顾一下 RocketMQ 4.x 版本的倒退。在开源晚期，RocketMQ 就已反对一般音讯、程序音讯、提早音讯等不同类型音讯，根本满足大多数业务场景。
在 RocketMQ 4.3.0 版本之后，正式公布事务音讯，通过相似于两阶段的形式去解决上下游数据不统一问题。
在 RocketMQ 4.4.0 版本中，RocketMQ 减少了音讯轨迹的性能，使用户能够更好定位每一条音讯的投放接管门路，帮忙问题排查，另外还减少 ACL 权限管制，进步了 RocketMQ 的管控能力和安全性。
在 4.5.0 版本中，RocketMQ 推出了多正本，也就是 Raft 模式。在 Raft 模式下，一组 Broker 如果 Master 挂了，那么 Broker 中其余 Slave 就会从新选出主。因而 Broker 组内就领有了主动故障转移的能力，也解决了像高可用程序音讯这样的问题，进一步提高了 RocketMQ 的可用性。
在 4.6.0 版本中，咱们推出了轻量级 Pull Consumer，用户能够应用更加适宜于流计算的 API，这一版本也开始反对全新的 Request-Reply 音讯，使得 RocketMQ 具备了同步调用 RPC 的能力，RocketMQ 能够更好的突破网络隔离网络之间的调用，这个版本中 RocketMQ 也开始反对 IPV6，并且是首个反对 IPV6 的消息中间件。
在 4.7.0 版本中，RocketMQ 重构了主备同步复制流程，通过线程异步化，将同步复制和刷盘的过程 Pipeline 化，同步双写性能有将近数倍晋升。
在 4.8.0 版本中，RocketMQ Raft 模式有了一个质的晋升，包含通过异步化、批量复制等伎俩将性能晋升了数倍，在稳定性上利用 OpenChaos 实现包含宕机、杀死过程，OOM、各种各样的网络分区和提早的测试，修复了重要 Bug。在性能上，反对 Preferred Leader，从而 Broker 组内能够优先选主，也反对了批量音讯等性能。
在 4.9.0 版本，次要是晋升了可观测性，包含反对 OpenTracing，事务音讯和 Pull Consumer 反对 Trace 等性能。
能够看到 RocketMQ 在通过多年倒退，从性能、稳定性、可靠性、可观测性等方面都有了很大进步。并且在这一过程中，除了阿里之外企业在代码建设方面做出了卓越贡献，这也证实 RocketMQ 已成为多元化并凋敝倒退的社区。
除了 RocketMQ 主仓库的倒退，RocketMQ 生态我的项目倒退也令人备受鼓励，特地是与云原生热点技术的整合，比如说在云原生化部署下面，咱们有 RocketMQ Operator、RocketMQ Docker 这些我的项目。在微服务开发框架下面，RocketMQ 社区也通过构建 RocketMQ Spring Boot Starter 这种接入形式，不便开源用户的微服务零碎与 RocketMQ 音讯队列的通信能力可能实现疾速集成和买通，以此为根底 Spring Cloud Stream Binder 和 Spring Cloud Bus 的 RocketMQ 实现也被 Spring Cloud 官网收录。
在 Service Mesh 方面，RocketMQ 是最早和 Envoy 联合的音讯产品，当初也实现了 Dapr 的集成。在 Serverless 方面，包含适配 Cloud Events 以及社区开源了 RocetMQ Knative Source 仓库。
在可观测性上，RocketMQ 反对 OpenTracing、OpenTelemetry、Prometheus Exporter 等。
在 Eventing 畛域，咱们有本人的 RocketMQ Connector，能够去实现各种内部组件，比方 MySQL、ElasticSearch 与 RocketMQ 的数据交互和数据同步，也能实现 MQ 集群之间的一个数据流转。在 Streaming 畛域，RocketMQ 5.0 会公布原生的轻量级实时计算框架 RocketMQ-Streams，另一方面 RocketMQ 也踊跃和 Flink、Storm、Spark 等现有大数据框架进行集成。
咱们能够看到 RocketMQ 不仅是业务音讯的管道，也在承当着事件流转、业务数据的一些离线计算和轻量级的实时计算。通过音讯、事件、流三个方面倒退，RocketMQ 已造成残缺自闭环的生态倒退，正在逐步成为音讯、事件、流的超交融的解决平台。
RocketMQ5.0 概览
在正式介绍 RocketMQ 5.0 之前，咱们须要先答复这样一个问题：为什么咱们须要 RocketMQ 5.0，在跟泛滥贡献者沟通以及对 RocketMQ 大量运维实际后，发现这里有两大起因：
首先，开源社区的需要越发凸显，当大量企业采纳 RocketMQ 后，每个用户都有丰盛的业务场景。而 RocketMQ 4.x 次要服务于业务音讯畛域，那么如何通过 RocketMQ 进行实时数据计算去解决这些高价值数据，成为企业下一步摸索的重要方向。这也是 RocketMQ 为什么会从音讯畛域去踊跃拓展流计算畛域的起因。
其次，云音讯服务质量要求一直进步，作为 RocketMQ 深度参与者与贡献者，阿里云的音讯服务目前已服务数万家企业。随着客户企业对于服务的要求，以及阿里巴巴本身的业务倒退，这都对 RocketMQ 有了更高要求。如何做到一套架构，同时能满足不同用户不同场景需要，成为 RocketMQ 5.0 中重点解决的问题。
因而，联合宽泛的理论业务场景，RocketMQ 5.0 作为生于云、长于云的全新的架构，通过一直摸索实际，RocketMQ 5.0 次要具备以下个性：
- 高 SLA、低成本：与云统一的可用性、高性能、低成本
- 可调度：任意组件的重塑与组建适应多样性场景
- 可扩大：凋谢的丰盛生态
- 可伸缩性：极致自动化扩容 / 缩容
- 标准化：社区规范，合乎行业标准
RocketMQ 5.0 作为云原生的音讯事件流的超交融平台，基于架构图咱们一一进行解说：
1. 轻量级 SDK
RocketMQ 5.0 提供轻量级的客户端，使之具备良好的集成与被集成能力。同时，将负载平衡、逻辑位点治理这些简单逻辑都放到服务端，实现无状态化。在协定抉择方面，除了原有协定之外，全面反对云原生通信规范 gRPC 协定。
2. 极简架构
RocketMQ 5.0 仍然不会去引入任何内部依赖，放弃极低的运维累赘。同时，节点之间的涣散耦合，任意服务节点能够随时进行迁徙。RocketMQ 5.0 将会是面向失败的设计，任意的服务节点的失败和迁徙都是能够忍耐的。
3. 可分可合的存储计算拆散架构
Broker 节点会成为真正无状态的服务节点，并且没有 Topic Banding。也就是说音讯的发送和生产是能够产生在任意计算节点上，一个接入点即可代理所有流量，计算层以及存储层均可独立进行弹性扩缩。在存储计算拆散后，计算节点能够解决不同类型的协定，包含 Remoting、gRPC，MQTT、AMQP 等。此外包含 ACL、订阅关系、多租的管制等都会放在计算节点上。最重要的一点，它是可分可合的，能够反对小集群，也能够反对超大规模的集群，并且能适应多种业务的场景，升高运维的累赘。
4. 多模存储
RocketMQ Raft 模式采取三正本状态，与自身就领有三正本的云盘联合之后，相当于就失去了 9 正本。9 正本尽管带来了更高的可靠性，但也造成了重大的老本节约。所以，RocketMQ 5.0 通过多模存储解决这一问题。比方，在一般的块存储设备上，能够依据可用性需要实现两正本或三正本部署。在云上用单正本，从而更好的反对云盘输入，充分利用云上基础设施去升高运维老本。
5. 云原生基础设施的宽泛应用与整合
反对 OpenTelemetry、Prometheus 等我的项目，强化 RocketMQ 可观测能力。并更好去反对 K8s 生态，比方 RocketMQ Operator 用一条命令即可拉起 RocketMQ 集群，并且去实现向灰度公布数据的全生命周期治理，主动弹性扩缩等方面的反对。
外围个性一：可分可合的存储计算拆散架构
接下来，具体介绍一下可分可合的存储计算拆散架构。可分可合指的是 RocketMQ 能够像当初一样用同一过程去启动 Broker，也能够离开部署。离开部署之后计算节点就能真正的做到无状态，RocketMQ 对存储计算拆散的架构的引进是十分审慎的，一体化部署带来了诸多益处，比方大数据场景下，一体化部署提供就近计算能力，升高带宽老本。业务音讯场景下，一体化部署能够升高提早。与此同时，存储计算拆散也有十分多的益处，比如说扩缩容能够更加灵便，能够针对具体计算资源或存储资源进行扩缩容。
因而 RocketMQ 5.0 将会提供可分可合的存储计算拆散架构，能够适应多种场景。计算节点是齐全无状态的。包含像协定适配、流量租户等管控都会放在计算节点上实现。此外，通过 POP 生产形式把整个客户端的负载平衡逻辑位的治理回升到计算节点，无 Queue Binding，任意的计算节点都能进行收发。另外，因为无状态，能够实现秒级弹性扩缩，并且过程中是没有 Rebalance 累赘的。
与此同时，RocketMQ 5.0 会对存储集群进行了优化调整。在存储集群中咱们原生的保留了多音讯类型的存储反对，包含事务音讯、定时音讯，重试音讯、死信音讯等。在正本的抉择上，依据不同场景去提供不同反对，包含本地块设施多正本反对、云盘单正本反对。借助多模态存储性能，充分利用云上基础设施降低成本。
另一点十分重要的是多元索引的反对。当初 RocketMQ 存储是一份 CommitLog，后盾线程去散发构建 ConsumeQueue、index 这些索引。那么 RocketMQ 5.0 会对索引全面加强，反对更多样索引。比方退出批处理的索引，音讯就能够实现批量发送，批量存储，批量接管，从而晋升 RocketMQ Batch 能力。比方音讯队列只做音讯轮转，查问能力比拟弱，在 RocketMQ 5.0 中，音讯和 KV 会更好联合在一起，去构建查问索引从而加强 KV 能力。通过一份数据，多种索引，RocketMQ 5.0 能够满足不同场景。
外围个性二：流批一体的数据拜访形式
首先介绍全新的生产模式——POP 生产形式。左上角的图是 RocketMQ 4.0 现有生产端的负载平衡架构。比方当初 Topic 散布在 3 个 Broker 上，共计 9 个队列。在集群模式下，1 个生产组有 3 个消费者。依据。所以每个消费者调配到了三个队列。
但这也带来了一些问题，比如说某 Consumer 忽然 Hang 住了，这它无奈生产音讯但也没有掉线，依然放弃和 Broker 的心跳连贯，因而也不会将剔除而进行重均衡，所以这个消费者调配到的队列就会有大量的音讯沉积，这些队列的生产就会卡住。
这实质上是一个绑定关系问题，一旦 Rebalance 产生后，Consumer 和队列就实现了绑定。针对这个问题，RocketMQ 5.0 推出了一个全新的生产形式，即 POP 生产形式。它勾销了 Rebalance 造成的绑定关系，一个队列能够被任意多个 Consumer 进行生产，而后在 Broker 端通过队列锁实现并发管制。
POP 生产中，客户端会间接到每个 Broker 的队列进行申请生产，Broker 会把音讯调配返回给期待的客户端。随后客户端生产完结后返回对应的 ACK 后果告诉 Broker，Broker 再标记音讯生产后果，如果超时没响应或者生产失败，再会进行重试。
Broker 对于每次 POP 的申请，都会有以下三个操作：
- 对应的队列进行加锁，而后从 Store 层获取该队列的音讯；
- 而后写入 CK 音讯，表明获取的音讯要被 POP 生产；
- 最初提交以后位点，并开释锁。
CK 音讯实际上是记录了 POP 音讯具体位点的定时音讯，当客户端超时没响应的时候，CK 音讯就会从新被 Broker 生产，而后把 CK 音讯的位点的音讯写入重试队列。如果 Broker 收到客户端的生产后果的 ACK，删除对应的 CK 音讯，而后依据具体后果判断是否须要重试。
从整体流程可见，POP 生产并不需要 Reblance，能够防止 Rebalance 带来的生产延时，同时客户端能够生产 Broker 的所有队列，这样就能够防止机器 Hang 住而导致沉积的问题。
有了 POP、PUSH、PULL 等模式之后，RocketMQ 就能够实现流批一体的数据拜访形式。比如说在 Streaming 场景下，通过本来 PUSH 形式能够保障很好的程序生产。但批处理等对程序要求并不高的场景中，咱们能够用 POP 生产的形式对同一队列进行高并发读取，放慢数据读取速度。另一方面 POP 生产模式也使得客户端更加轻量化，大量的逻辑都在服务端，对多语言客户端的编写也是更加敌对的。
外围个性三：极致弹性扩缩
上图是 RocketMQ 现有架构，比如说咱们通过禁写操作，能够使 Broker 1001 的流量天然流入到 1002 上。但在 Streaming 畛域，下层业务个别要求存储队列始终固定的，只有这样能力保障流式数据处理的程序性和完整性，这也就要求扩缩容不会引起队列数量的变动。因而 RocketMQ 5.0 Preview 版本提供了一个逻辑队列概念，把本来的物理队列逻辑组合在一起，一个逻辑队列能够扩散到不同 Broker 下面。比方图中的一个逻辑队列，0～100 在 Broker 1001 上，100～1000 在 Broker 1002 上，1000～2000 的在 Broker 1003 上，通过组合能够把多个物理队列串联成了一个大的逻辑队列。
因为逻辑队列是一个 Binding 过程，所以是十分轻量级的操作，因而提供了一个秒级弹性裁减的一个能力，过程中齐全没有也没有数据的复制，只有一实现 Broker 扩容，实现绑定操作，流量也就实现了调拨。另外咱们也提供双模队列兼容的能力，平时默认还是原来的物理队列，只有指定单个 Topic 开启后，才会应用逻辑队列。
外围个性四：轻量级实时计算
RocketMQ 5.0 中还有一个十分重量级的个性，将会推出轻量级的实时计算框架 RocketMQ Streams。它的设计指标是帮忙用户在不依赖内部重量级计算产品的状况下，仅利用已有 RocketMQ 资源实现大多数业务场景须要的轻量级的数据处理和计算。
RocketMQ Stream 依赖少、部署简略，它利用 RocketMQ Rabalance 能力能够任意横向扩大，同时反对包含 Map、Fliter 这些常见的算子，还有 Window、Join、维表等。另外相比于其余基于音讯的实时计算平台，RocketMQ Streams 除提供原生无依赖的反对外，能够兼容 Flink SQL 规范以及提供 UDF/UDAF/UDTF 的能力。
另一方面，在实时计算生态下面，RocketMQ 也踊跃的和其余的大数据框架进行对接，包含 Flink、Spark 等。特地是基于最新规范的 RocketMQ-Flink Connector 也会近期毕业。
RcoketMQ 5.0 Landscape
RocketMQ 5.0 版本将在往年正式公布，5.0 Preview 的版本曾经在 Discuss 了，代码也放在 Github 仓库中，5.0 Preview 版本会推出逻辑队列，以及流批一体的拜访形式等重磅个性。之后咱们会正式公布实时流计算框架 RocketMQ Streams，并在 RocketMQ 5.0 反对批处理、批索引能力。在后续的里程碑中 RocketMQ 5.0 将会实现 gRPC 协定反对，全新的轻量级客户端，实现 AMQP、MQTT 协定等反对，以及可分可合的存储与计算拆散架构。
也心愿能有更多的小伙伴参加到 Apache RocketMQ 社区中来，一起打造来下一代云原生音讯引擎，打造 Messaging、Eventing、Streaming 的超交融解决平台。
原文链接
本文为阿里云原创内容，未经容许不得转载。