2022年，RocketMQ 5.0的正式版发布，相比于4.0版本而言，架构走向云原生化，并且覆盖了更多的业务场景。
如何从互联网时代演进到云时代？
1. 消息队列演进史
操作系统、数据库、中间件是基础软件的三驾马车，而消息队列是其中最经典的中间件之一，已经有30多年的历史了。
- 第一阶段（1980~2000年）：其中最具代表性的为IBM MQ，价格昂贵，面相高端企业，MQ本身的软件架构是单体架构。
- 第二阶段（2000~2007年）：进入00年代后，初代开源消息队列崛起，诞生了JMS、AMQP两大标准，与之对应的初代开源消息队列的两大实现：ActiveMQ、RabbitMQ，它们共同引领了初期的开源消息队列的技术，开源也极大的促进了消息队列的流行，降低了使用的门槛，技术普惠化，逐渐成为企业级架构的标配，相比于今天而言，这一类MQ主要还是面向于传统的企业级应用场景，它们的流量一般都比较小，对横向扩展性的需求也没那么强。
- 第三阶段（2007~2017年）：就是PC互联网和移动互联网爆发的阶段了，由于传统的消息队列（ActiveMQ、RabbitMQ），它们都没办法承受亿级用户的访问流量以及海量的数据传输，于是在这个过程中就但诞生了所谓的互联网消息队列，它的核心能力是全面采用了分布式的架构，具备了很强的横向扩展能力，比较典型的开源代表有： Kafka以及RocketMQ，闭源的还有淘宝的Notify，Kafka的诞生还将消息中间件从传统的消息领域延伸到了流领域，从分布式应用的异步解耦的场景延伸到大数据的流存储跟流计算的场景。
- 第四阶段（2014~至今）：最近这几年 - 云计算、物联网（IoT）、云原生、大数据，它们又引领了新的浪潮。
互联网时代的 RocketMQ
RocketMQ的诞生背景
虽然在当时业界已经存在不少商业或开源的消息队列，比如IBM MQ、ActiveMQ、RabbitMQ，但无一例外，这些消息队列它们都诞生于传统的企业级应用的场景，它们没办法承担互联网对于高并发、无限横向扩展的苛刻要求，以RabbitMQ为例，RabbitMQ的队列流量与存储负载都是单机的，无法满足业务横向扩展的需求，它是没法根据互联网业务的爆发式发展而进行横向扩展的。
而当时另外一款采用分布式架构、具备无限横向扩展能力的消息队列是Kafka，但是它在那个时候它主要用在日志传输的场景，它在稳定性方面还未经过大规模核心业务的验证，而且它也比较偏向于简单的log型的消息队列，没办法满足互联网电商对于复杂消息功能特性的诉求，比如一些消息过滤或者一些延迟消息等；另一方面的话，传统的消息队列它没办法解决电商交易对于分布式一致性的要求。通过消息队列实现应用的异步解耦之后，电商业务还需要保证/保障不同的上下游应用，对订单的状态要能达到最终的一致，否则将会产生大量的脏数据，导致大量的业务错误。
所以对于一个大规模的电商交易系统来说，它既要高性能，又要一致性，然后传统的分布式事务技术也是束手无策。比如IBM MQ虽然可以使用XA事务来满足分布式一致性的功能诉求，但是XA带来的延迟与成本，对于海量的互联网流量难以承受。
于是为了解决电商业务对于消息队列的高性能、一致性、无限扩展等需求，自研消息队列就成了当时阿里唯一的出路，也就是在这个大背景下面，互联网消息队列RocketMQ应运而生。
为了支撑超大规模的复杂电商业务，RockteMQ主要面向四个方面进行了重点建设，形成了四大优势能力：
优势一：支撑超大规模复杂业务的能力，具备丰富的消息特性；
优势二：数据一致性，RocketMQ在一致性方面打造了多个关键的特性，最有代表性的是分布式事务消息，RocketMQ是第一个实现该种特性的消息队列，它可以保障交易的上下游业务对于订单状态达到最终的一致，于是这个方案也成为了现在异步消息一致性方案的事实标准，被多个互联网公司所采纳。除了分布式一致性之外，RocketMQ还提供了顺序消息的特性，满足顺序一致性的需求；
优势三：稳定性，稳定性可以认为是电商交易与金融场景最基本的特性，也是RocketMQ的根本同时，稳定性也不局限于数据与服务的高可用，RocketMQ从产品层面对稳定性进行了全方位的建设，如消息回溯的能力、消息轨迹的能力以及死信队列的能力（消息死信机制）；
优势四：高性能，即便是在双十一的极限流量下面，RokcetMQ的写消息的延迟也是非常低的；同时RocketMQ它采用的是Shared - noting的分布式架构，架构极简，零外部依赖；另外在吞吐量方面也具备了无限扩展的能力，万亿级吞吐保证，同时满足微服务与大数据场景；它已经连续十年支撑了双十一的万亿级消息洪峰，为百万级的客户端实例提供低延迟的消息服务。