01、RocketMQ 实战 - RocketMQ介绍

一、为什么选择RocketMQ

在阿里孕育 RocketMQ 的雏形时期，将其用于异步通信、搜索、社交网络活动流、数据管道，贸易流程中。随着阿里的贸易业务吞吐量的上升，源自阿里的消息传递集群的压力也变得紧迫。

根据阿里的研究，随着队列和虚拟主题使用的增加，ActiveMQ IO模块达到了一个瓶颈。阿里尽力通过节流、断路器或降级来解决这个问题，但效果并不理想。于是阿里尝试了流行的消息传递解决方案Kafka。不幸的是，Kafka不能满足阿里的要求，其尤其表现在低延迟和高可靠性方面，详见下文。在这种情况下，阿里决定发明一个新的消息传递引擎来处理更广泛的消息用例，覆盖从传统的pub/sub场景到高容量的实时零误差的交易系统。

Apache RocketMQ 自诞生以来，因其架构简单、业务功能丰富、具备极强可扩展性等特点被众多企业开发者以及云厂商广泛采用。历经十余年的大规模场景打磨，RocketMQ 已经成为业内共识的金融级可靠业务消息首选方案，被广泛应用于互联网、大数据、移动互联网、物联网等领域的业务场景

二、RocketMQ5.0速览

RocketMQ已经演进到5.0了。Apache RocketMQ 5.0 的演进目标有三个： 消息基础架构的云原生化演进：充分结合云原生大潮下的基础设施和生态技术，提高资源利用和弹性能力。 集成效率的痛点升级优化：从API、SDK多方面重构设计，为开发者提供更加简单易用、轻量易集成的方案； 事件、流集成场景拓宽：我们将以当前业务集成的能力为基础进一步聚焦消息领域的后处理场景，支持消息的流式处理和轻计算，帮助用户实现消息的就近计算和分析，并将全面拥抱 Serverless 和 EDA。

新特性

1、基础架构云原生化升级

坚持简洁架构，比如元数据采用最终一致性设计，只引入了几百行代码的无状态 NameSrv 组件。随着企业上云的进一步普及以及云原生技术趋势的演进，集成的网络环境更加复杂，企业开发者对效率也有了更高的要求，我们看到当前的架构还存在一定的不足。RocketMQ 5.0 引入了全新的弹性无状态代理模式，将当前的Broker职责进行拆分，对于客户端协议适配、权限管理、消费管理等计算逻辑进行抽离，独立无状态的代理角色提供服务，Broker则继续专注于存储能力的持续优化。这套模式可以更好地实现在云环境的资源弹性调度。 值得注意的是RocketMQ 5.0的全新模式是和4.0的极简架构模式相容相通的，5.0的代理架构完全可以以Local模式运行，实现与4.0架构完全一致的效果。开发者可以根据自身的业务场景自由选择架构部署。

2、轻量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 能力。

3、事件、流处理场景集成

除了上述基础架构以及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 的大数据计算能力满足业务诉求。

三、如何升级到RocketMQ5.0

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

四、MQ对比