云原生消息、事件、流超融合平台——RocketMQ 5.0 初探

今天分享的主题是云原生消息事件流超融合平台 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 除了常见的订阅模式，广播模式、集群模式，还支持消息查询，消息回放