从互联网到云时代,Apache RocketMQ 是如何演进的?

作者:隆基

2022 年,RocketMQ 5.0 的正式版发布。相对于 4.0 版本而言,架构走向云原生化,并且覆盖了更多业务场景。

消息队列演进史

操作系统、数据库、中间件是基础软件的三驾马车,而消息队列属于最经典的中间件之一,已经有 30 多年的历史。消息队列的发展主要经历了以下几个阶段:

  • 第一阶段(1980-2000 年) 80 年代诞生了第一款消息队列 The Information Bus,第一次提出发布订阅模式来解决软件之间的通信问题;90 年代是国际商业软件巨头的时代,IBM、Oracle、Microsoft 纷纷推出自己的 MQ,其中最具代表性的为 IBM MQ,价格昂贵,面向高端企业,主要是大型金融、电信等企业。该类商业 MQ 一般采用高端硬件,软硬件一体机交付,MQ 本身的软件架构为单机架构。
  • 第二阶段(2000~2007 年)
    进入 00 年代后,初代开源消息队列崛起,诞生了 JMS、AMQP 两大标准,与之对应的两个实现分别为 ActiveMQ、RabbitMQ,他们引领了初期的开源消息队列技术。开源极大促进了消息队列的流行,降低了使用门槛,技术普惠化,逐渐成为企业级架构的标配。相比于今天而言,这类 MQ 主要面向传统企业级应用和小流量场景,横向扩展能力较弱。
  • 第三阶段(2007~2017 年) PC 互联网、移动互联网爆发式发展。由于传统的消息队列无法承受亿级用户的访问流量与海量数据传输,诞生了互联网消息中间件,核心能力是全面采用分布式架构,具备很强的横向扩展能力,开源典型代表有 Kafka、RocketMQ,闭源的有淘宝 Notify。Kafka 的诞生还将消息中间件从消息领域延伸到了流领域,从分布式应用的异步解耦场景延伸到大数据领域的流存储与流计算场景。
  • 第四阶段(2014~至今) 云计算、IoT、大数据引领了新的浪潮。

互联网时代的 RocketMQ

阿里的电商系统最初是个庞大的单体巨石应用,在研发效率、稳定性方面都无法满足淘宝和天猫飞速的发展。为了解决问题,2008 年,淘宝与天猫发起了一次最大规模的架构升级,启动了"五彩石"项目,将单体应用拆分为分布式应用,同时抽象淘宝、天猫的共同底座------业务中台,包括交易中心、商品中心、买家中心等。在业务中台之下,同时诞生了阿里中间件(初期三大件包括消息、RPC、分布式数据层),RocketMQ 是其中之一。

虽然在当时业界已经存在不少商业或开源的消息队列,比如 IBMMQ、ActiveMQ、RabbitMQ,但无一例外,它们都诞生于传统企业级应用的场景,无法承受互联网对于高并发、无限扩展的苛刻要求。以 RabbitMQ 为例,RabbitMQ 的队列流量与存储负载都为单机,无法满足业务横向扩展的需求。当时另一款具备无限横向扩展能力的消息队列是 Kafka,但其主要用于日志类场景,未经过大规模核心业务稳定性验证,而且偏向于简单的 log 型消息队列,无法满足电商对于复杂消息功能特性的诉求,比如消息过滤、延迟消息等。

另一方面,传统的消息队列无法解决电商业务对于分布式一致性的要求。通过消息队列实现应用异步解耦后,电商业务还需要保障不同上下游应用对于订单状态要达成最终一致,否则会产生大量脏数据,造成业务错误。

大规模的电商系统,既要高性能又要一致性,传统的分布式事务技术束手无策。比如IBM MQ 虽然可以使用 XA 事务来满足分布式一致性的功能诉求,但是 XA 带来的延迟与成本,对于海量的互联网流量难以承受。

为了解决电商业务对于消息队列的高性能、一致性、无限扩展等需求,自研消息队列成为了当时阿里唯一的出路,最终互联网消息队列 RocketMQ 应运而生。

为了支持超大规模的复杂电商业务,RocketMQ 面向四个方面进行了重点建设,形成了四大优势能力。

① 支撑超大规模复杂业务的能力,具备丰富的消息特性

每一个大型互联网公司都会有主营业务(比如阿里是交易、蚂蚁是支付、饿了么是外卖),以主营业务为中心扩展业务能力,阿里电商是围绕交易事件建设的电商操作系统,每笔交易事件都会触发不同的业务,不同细分业务会关注不同类型的交易事件,比如垂直市场只关注某个类目的交易事件、天猫超市只关注某个卖家的交易事件、购物车只关注下单成功的交易事件等。

RocketMQ 的 SQL 订阅提供灵活的消息过滤能力,能够满足下游消费者按照不同的业务维度进行消息过滤的诉求。

在大型互联网业务中,还会有各种定时事件触发场景,最典型的是交易超时关闭机制,阿里交易或者 12306 订票都有类似的机制。RocketMQ 的定时消息能够很方便的满足这类诉求。

② 一致性

无论是阿里交易还是蚂蚁支付,都天然对数据一致性有着极高要求,RocketMQ 在一致性方面也打造了多个关键特性。最具代表性的是分布式事务消息,RocketMQ 是第一个实现该种特性的消息队列,能够保障交易的上下游对于订单状态达到最终一致。该方案也成为异步消息一致性方案的事实标准,被多个互联网公司所采纳,甚至也有公司将移植到定制版的 Kafka 种。除了分布式一致性之外,RocketMQ 还提供了顺序消息的特性,满足顺序一致性的需求。

③ 稳定性

稳定性是交易与金融场景的基石特性,也是 RocketMQ 的根本。RocketMQ 除了具备核心服务的 HA 之外,还具备了全局高可用能力,在阿里内部支持同城多活、异地多活、中心容灾等高阶 HA 能力。同时,稳定性也不局限于数据与服务的高可用,RocketMQ 从产品层面对稳定性进行了全方位的建设,如消息轨迹、消息回溯、消息死信机制。

④ 高性能

在双十一的极限流量下,RocketMQ 写消息延迟 4 个 9 在 1ms 内,100% 在 100ms 内。RocketMQ 采用 shared-nothing 分布式架构,在吞吐量方面也具备无限扩展的能力,已经连续 10 年支持了双十一万亿级消息洪峰,为百万级的应用实例提供低延迟消息服务。

互联网的故事还在进行,云计算规模化落地的时代悄然而来。

云计算时代的 RocketMQ 5.0

2015 年,RocketMQ 的首个云消息服务在阿里云上线,开启了大规模的云计算实践的序幕。同时 RocketMQ 也是业界第一个提供公有云服务的开源消息队列。

在大规模的云计算业务场景下,RocketMQ 面临着全新的挑战与机遇。

  • 多样性: 它不再仅服务于某一家公司的内部业务,不再局限于互联网或金融企业,需要实现全行业、全场景的覆盖。
  • 标准化: 对于服务企业内部的自研消息队列而言,无需考虑协议或 API 的标准化。但是对于云消息服务而言,因为服务对象是外部企业客户,据信通院统计,80% 以上的企业客户已经采纳开源技术和标准技术。因此,作为一款云消息服务,需要提供对业界的事实标准协议、接口、SDK 的兼容,才能保证客户平滑上云,同时打消客户技术绑定的担忧。
  • 云原生: 云原生理念深入人心,消息队列要更好地帮助客户实现云原生应用架构,为业务降本提效。
  • 新趋势: 各种新技术的兴起,包括 IoT、5G、边缘计算、事件驱动,还有事件流技术。面向技术的新趋势与多样化的业务需求,RocketMQ 进行了自我进化,演进到 5.0 版本。

为了充分释放云的技术红利,RocketMQ 5.0 在技术架构上进行了云原生的演进。从客户端到服务端都进行了全方位的改造,更高弹性、可用性、更低成本。

  • 客户端采用轻量 SDK 设计理念,将原来富客户端的逻辑下沉到 Broker,满足现代化应用轻量化、Serverless 的趋势。
  • Broker 彻底进行弹性架构改造,分离 RocketMQ Proxy 与 Store 层,其中 Proxy 是完全无状态的计算节点,专注多协议、多领域场景覆盖,可以面向不同工作负载独立弹性,如物联网、微服务、大数据不同场景有不同的资源诉求。Store 层则专注消息的高可用存储,包括副本复制、主备切换与云存储集成。同时对 RocketMQ 的 Topic 资源进行三层解耦,面向消息的Topic、面向流的 Topic 逻辑分片、面向底层存储的 Topic 物理分片,每一层都可以独立弹性。
  • 在存储层引入了 Leaderless 的高可用架构,Store 节点身份对等,Leaderless 化,0 外部依赖。多副本策略可定制,可用性+可靠性+成本灵活组合,面向多可用区、多 region 组建 Geo 高可用能力。

为了满足云时代多样化的用户需求,RocketMQ 5.0 从原来的互联网业务消息中间件扩展到"消息、事件、流"超融合处理平台,解锁更全面的能力。

在消息领域, 全面拥抱云原生技术,更好的弹性架构与高可用能力。

在事件领域, 支持 CloudEvent 规范,以事件为中心的产品新界面,助力客户建设跨业务、跨组织的数字化商业生态。

在流领域, 流存储增强批量特性,大幅度提高数据吞吐量;新增逻辑队列能力,解耦逻辑资源与物理资源,在流场景也具备无缝伸缩能力;新增流数据库 RSQLDB,提供实时事件流处理、流分析能力。

RocketMQ 基于端云一体化架构实现了完整的物联网消息队列的能力,从原来的连接应用扩展到连接物联网设备。同时 RocketMQ 5.0 也继续保持极简架构的原则,能够以最低的资源消耗、运维成本搭建服务,适合边缘计算。

除了的产品核心能力之外,RocketMQ 5.0 积极建设开源生态。

一方面是应用架构生态的建设,既有经典的开源项目、规范的集成,比如 JMS、AMQP 等,也有云原生技术生态的集成,比如 CloudEvents、Dapr、Envoy。同时 RocketMQ 也会进一步发力数据架构生态,全链路集成大数据的摄入、数据存储、数据处理、数据分析组件,从离线大数据到实时大数据。

RocketMQ 学习社区体验地址

RocketMQ 学习社区重磅上线!AI 互动,一秒了解 RocketMQ 功能源码。RocketMQ 学习社区是国内首个基于AIGC提供的知识服务社区,旨在成为 RocketMQ 学习路上的"贴身小二"。

PS:RocketMQ 社区以 RocketMQ 5.0 资料为主要训练内容,持续优化迭代中,回答内容均由人工智能模型生成,其准确性和完整性无法保证,且不代表 RocketMQ 学习社区的态度或观点。

立即体验 RocketMQ 学习社区(建议 PC 端体验完整功能):

https://rocketmq-learning.com/

相关推荐
Smile丶凉轩几秒前
微服务即时通讯系统的实现(客户端)----(1)
微服务·云原生·架构
南慕小白3 分钟前
云原生后端
云原生
小安运维日记2 小时前
CKA认证 | Day3 K8s管理应用生命周期(上)
运维·云原生·容器·kubernetes·云计算·k8s
politeboy3 小时前
关于k8s中镜像的服务端口被拒绝的问题
云原生·容器·kubernetes
weixin_438197383 小时前
K8S创建云主机配置docker仓库
linux·云原生·容器·eureka·kubernetes
巨大八爪鱼5 小时前
XP系统下用mod_jk 1.2.40整合apache2.2.16和tomcat 6.0.29,让apache可以同时访问php和jsp页面
java·tomcat·apache·mod_jk
ggaofeng14 小时前
通过命令学习k8s
云原生·容器·kubernetes
qq_道可道17 小时前
K8S升级到1.24后,切换运行时导致 dind 构建镜像慢根因定位与解决
云原生·容器·kubernetes
郝同学的测开笔记20 小时前
云原生探索系列(十二):Go 语言接口详解
后端·云原生·go
mit6.82421 小时前
[Docker#5] 镜像仓库 | 命令 | 实验:搭建Nginx | 创建私有仓库
linux·后端·docker·云原生