5.0 概述

为什么选择 RocketMQ 5.0​

Apache RocketMQ 自诞生以来，凭借其架构简单、业务功能丰富、可扩展性强等特点，被众多企业开发者和云厂商广泛采用。经过十多年的规模化场景打磨，RocketMQ 已成为业界公认的金融级可靠业务消息首选方案，广泛应用于互联网、大数据、移动互联网、物联网等领域的业务场景。 尽管 RocketMQ 在开源社区已经走过了十多个年头，但在企业架构云原生浪潮下，我们一直在思考 RocketMQ 的架构演进以及对上层集成的价值提升。Apache RocketMQ 5.0 的演进目标有三个： 消息基础架构的云原生化演进：充分结合云原生大潮下的基础设施和生态技术，提高资源利用率和弹性能力。 集成效率的痛点升级优化：从 API、SDK 多方面重构设计，为开发者提供更加简单易用、轻量易集成的方案； 事件、流集成场景拓宽：我们将以当前业务集成的能力为基础进一步聚焦消息领域的后处理场景，支持消息的流式处理和轻计算，帮助用户实现消息的就近计算和分析，并将全面拥抱 Serverless 和 EDA。

RocketMQ 5.0 的新特性​

基础架构云原生化升级​

RocketMQ 自诞生以来一直坚持简洁架构，例如元数据采用最终一致性设计，只引入了数百行代码的无状态 NameSrv 组件。与其他产品依赖 ZK 进行元数据管理维护相比，RocketMQ 的优势显而易见。 随着企业上云的进一步普及以及云原生技术趋势的演进，集成的网络环境更加复杂，企业开发者对效率也有了更高的要求，我们看到当前的架构还存在一定的不足。在当前架构下，存储和计算资源的灵活匹配相对困难，特别是在如今企业上云逐步普及的情况下，云厂商的计算资源和存储资源之间解耦灵活的弹性策略可以更好地实现降本提效。

RocketMQ 5.0 引入了全新的弹性无状态代理模式，将当前的 Broker 职责进行拆分，对于客户端协议适配、权限管理、消费管理等计算逻辑进行抽离，独立无状态的代理角色提供服务，Broker 则继续专注于存储能力的持续优化。这套模式可以更好地实现在云环境的资源弹性调度。 值得注意的是 RocketMQ 5.0 的全新模式是与 4.0 的极简架构模式相容相通的，5.0 的代理架构完全可以以 Local 模式运行，实现与 4.0 架构完全一致的效果。开发者可以根据自身的业务场景自由选择架构部署。

轻量 API 和多语言 SDK​

除了架构改变，RocketMQ 5.0 重新思考了面向开发者的集成界面，即 API 和 SDK 的设计。RocketMQ 4.x SDK 是比较重量级的富客户端模式，提供了诸如顺序消费、广播消费、消费者负载均衡、消息缓存、消息重试、位点管理、推拉结合、流控、诊断、故障转移、异常节点隔离等一系列能力。这些复杂能力虽然可以帮助业务集成解决实际问题，但其自身的演进和迭代却存在比较大的负担，客户端的升级和多语言普及难度较大。从 API 的简洁性和友好性方面，RocketMQ 5.0 正在做轻量化设计。

RocketMQ 5.0 推出了基于 gRPC 全新的多语言 SDK，这套 SDK 有几个重要特点： 采用全新极简的 API，拥有不可变 API 的设计，完善的错误处理，各语言 SDK API 在本地语言层面对齐，新的 API 化繁为简，更易被使用和集成。 采用云原生的 RPC 标准框架 gRPC，标准的传输层框架，更易被拦截，特别适合被 Service Mesh 集成从而赋予其更多的传输层基础能力。 客户端轻量化，以典型的「SimpleConsumer」为代表，采用全新的面向消息的无状态消费模型，整个 SDK 从代码到运行时都极为轻量。轻量化是一种非常重要的能力，如果各个中间件都采取富客户端的形式，这些中间件当被一起植入到 Sidecar 中时，也会是一个非常庞大的 Sidecar，应用框架集成的复杂度非常高。

除了 API/SDK 的设计优化，RocketMQ 5.0 还引入了一种无状态消费模型，即 Pop 机制，创新性地在队列模型之上支持了无状态的消息模型，在一个主体上同时支持两种消费模型，体现了消息和流的「二象性」。面向流场景采用高性能的队列模型进行消费；面向消息的场景，采用无状态的消息模型进行消费。业务可以只关心消息本身，通过「SimpleConsumer」提供单条消息级别的消费、重试、修改不可见时间、以及删除等 API 能力。

事件、流处理场景集成​

除了上述基础架构以及 API 集成的变化，RocketMQ 5.0 基于业务消息的基础优势，RocketMQ 5.0 进一步拓宽在消息后处理计算的场景挖掘。支持消息的流式处理和轻计算，帮助用户实现消息的就近计算和分析，并将全面拥抱 Serverless 和 EDA。

伴随企业云原生化进程的加速，计算力的构成越来越多样化，通过事件驱动架构来开发云原生应用是一件非常顺理成章的事情。RocketMQ 5.0 正是基于此技术趋势大潮开放了兼容标准 CloudEvents 协议的 RocketMQ-EventBridge 组件。EventBridge 提供丰富的跨产品、跨平台连接能力，能够促进云厂商、企业应用、SaaS 服务三者相互集成。EventBridge 的目标是以统一开放的标准链接社区活跃的生态，同时能与各个云厂商的「Hub」类产品进行集成，来达到开源和云的数据互通，助力企业客户轻松上云和下云。

在消息流式处理场景，RocketMQ 5.0 将当前的队列下沉为物理队列，上层重新抽象了逻辑队列。一个逻辑队列可以包含多个物理队列，各个物理队列都作为逻辑队列的一个片段，以此拼接出真正的流式队列。也因此可以做到更轻量，秒级扩缩，在物理节点发生变化时不涉及到存量数据复制迁移；实现数据存储的灵活调度，配合 TTL 实现无限存储能力。同时，应对流的高吞吐场景，RocketMQ 5.0 优化里存储批量处理的读写性能。

在计算框架方面，RocketMQ 5.0 引入了一套轻量级流式处理框架 RSteams。RStreams 依赖少、部署简单，可任意横向扩展，利用 RocketMQ 资源即可完成轻量级的数据处理和计算。除此以外，为了方便开发者让基于 RocketMQ 的流式计算更容易，RocketMQ 5.0 还支持了一套轻量 SQL 查询引擎 RSQLDB，为开发者提供基于 SQL 的开发体验。RSQLDB 首创性地兼容了 Flink/Blink SQL 标准以及 UDF/UDAF/UDTF，使得两个开源产品的生态可以更好地融合，开发者可以将 Flink/Blink 已有 SQL 计算任务迁移到 RocketMQ ，在 RocketMQ 内部完成轻量级的计算处理，在算力受限或者更大规模的场景下，同样可以将 RocketMQ 的实时计算任务迁移到 Flink，利用 Flink 的大数据计算能力满足业务诉求。

如何升级到 5.0​

RocketMQ 5.0 在完成上述架构升级、API 重构和新功能场景时，统一遵循了向下兼容的原则。RocketMQ 4.x 版本可以无缝升级到 5.0 版本同时保持对历史版本 SDK 的兼容。选择 5.0 版本无需担心不兼容历史版本的应用。我们建议升级服务端版本后，尽快替换使用新版本的 SDK 以获得更好的接入体验和新功能。