本文整理于 2023 年云栖大会林清山带来的主题讲演《Apache RocketMQ 云原生一致音讯引擎》
讲演嘉宾：
林清山（诨名：隆基），Apache RocketMQ 联合创始人，阿里云资深技能专家，阿里云音讯产品线负责人。国际音讯范畴专家，致力于音讯、实时核算、事情驱动等方向的研讨与探索，推动 RocketMQ 云原生架构、超融合架构的演进。
Apache RocketMQ 简介
音讯行列演进趋势
操作系统、数据库、中间件是根底软件的三驾马车，而音讯行列属于最经典的中间件之一，现已有30 多年的前史。他的开展首要经历了以下几个阶段：
第一个阶段，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、大数据引领了新的浪潮。
Apache RocketMQ 开展历程
伴跟着音讯行列职业的开展，Apache RocketMQ 本身也开展了十年，可分为“诞生于互联网”与“成善于云核算”两大阶段。
第一个阶段是 RocketMQ 的从 0 到 1，在阿里内部规划化落地。2012 年，为了支撑超大规划电商互联网架构，阿里中间件研制了 RocketMQ，并在产品诞生初期开源，2017 年 RocketMQ 一致了阿里音讯技能系统。
第二个阶段是云核算，2016 年 RocketMQ 上云，这也是业界首个供给公共云 SaaS 形状的开源音讯行列。2016 年，阿里把 RocketMQ 捐赠给 Apache，17 年孵化结业，成为国内首个 TLP 的互联网中间件。在云核算和开源双轮驱动下，RocketMQ 在阿里外部完成全面规划化，协助千行百业完成数字化转型，产品才能也得到进一步的腾跃。2022 年 5.0 正式发布，Apache RocketMQ 正式跨进云原生年代。
Apache RocketMQ 5.x 一致音讯引擎
Apache RocketMQ 5.X 事务全景
为了满意云年代多样化的用户需求，RocketMQ 5.0 从本来的互联网事务音讯中间件，扩展到”音讯、事情、流”超融合处理渠道，解锁更全面的才能。
在音讯范畴，全面拥抱云原生技能，更好的弹性架构和高可用才能。
在事情范畴，支撑 CloudEvent 规范，以事情为中心的产品新界面，助力客户建造跨事务、跨安排的数字化商业生态。
在流范畴，流存储增强批量特性，大幅度进步数据吞吐量；新增逻辑行列才能，解耦逻辑资源和物理资源，在流场景也具有无缝弹性才能；新增流数据库 RSQLDB，供给实时事情流处理、流剖析才能。
RocketMQ 依据端云一体化架构完成了完好的物联网音讯行列的才能，从本来的衔接运用扩展到衔接物联网设备。一起 RocketMQ 5.0 也继续坚持极简架构的原则，可以以最低的资源耗费、运维本钱建立服务，适合边际核算。
音讯和流的一致
为什么说 Apache RocketMQ 是一致的音讯引擎，首要有以下几方面的一致：
第一个一致是 Apache RocketMQ 一致了音讯和流的场景。经过这个比照图来看，音讯和流的差异。常说的音讯场景、行列场景侧重于事务集成，在这个场景里 RocketMQ 的首要效果是衔接事务运用，解耦事务架构的上下流系统，比方买卖系统的解耦。这类场景，更多的是在线事务，由用户触发某个事务流程，比方购买。
为了确保用户体验，音讯系统要优先确保低延迟。这个场景里和同步通讯 RPC 对应，音讯系统承当都是异步通讯责任。在音讯消费层面，更多的是依据音讯数据履行对应的事务逻辑，触发下一个事务流程。每条音讯的处理都是不相关的，无状况的。侧重于事务数字化场景，可类比于数据库的 OLTP，单次操作数据量少，用于在线买卖。
再来看流场景的话，它首要是侧重于数据集成，衔接各种数据组件，进行数据分发，解耦数据架构的上下流系统。比方日志解决方案，收集日志数据，进行 ETL 将日志数据分发到查找引擎、流核算、数据仓库等。除了日志之外，数据库 Binlog 分发、页面点击流也是常见的数据源。在这种场景里里边，由所以离线事务，它对低延迟的需求较弱，愈加侧重于大批量吞吐型负载。别的在音讯消费阶段，不再是单条音讯处理，更多的是批量转储，或许批量进行流核算。侧重于数字事务化场景，可类比于数据库的 OLAP，单次操作数据量大，用于离线剖析场景。
具体来说，RocketMQ 怎么完成音讯和流的一致呢？
首要体现在范畴模型的一致，包含 Producer、Consumer、Topic、Topic 逻辑分区 MessageQueue。在一致的范畴模型下选用不同的拜访形式来满意音讯和流的不同场景。
在音讯场景，客户端只感知 Topic，往 Topic 发送音讯，依据订阅关系消费 Topic 的音讯，触发对应的事务逻辑，回来消费成功或许失利，消费失利还会有重试。
而在流的场景，关于音讯数据的拜访形式有所不同。由所以用在数据集成的场景，关于大规划的数据集成，不可避免的要触及到数据的分片，依据数据分片来衔接上下流数据系统。在音讯的读写方式上，不再是指定 Topic 读写，而是指定 Topic 分片，也便是行列进行读写操作。作为流存储系统，下流的消费通常会是一些流核算引擎，用于有状况核算。为了支撑流核算引擎的容错处理，它需求支撑 checkpoint 机制，类似于为流核算引擎供给 redolog，可以依照行列位点重放音讯，从头恢复流核算的状况。他也会要求分片内有序，同一个 key 的数据会 hash 到同一个分片，用于完成 keyby 的操作。
这个便是流存储拜访形式跟音讯拜访形式的差异。在音讯场景里，用户只需求重视到 topic 资源，无需了解行列、位点等概念。
在流场景里边，还有一个很重要的改动，便是数据类型的改动。做个简略比照，事务集成场景，音讯的数据承载的是事务事情，比方说订单操作、物流操作，它特色便是数据规划较小，可是它每一条数据的价值都特别高，它的拜访形式是倾向于在线的，单条事务的短平快拜访形式。
而在流的场景里边呢，它更多的是一些非买卖型的数据。比方说用户日志，系统的监控、IoT 的一些传感器数据、网站的点击流等等。他的特色是数据规划有数量级的进步，但单条数据的价值比较低的，然后它的拜访形式倾向于离线批量传输。所以在流的场景里边，RocketMQ 存储要面向高吞吐做更多的优化。
在 RocketMQ 5.0 里边， 引入了端到端的批量音讯。从客户端开端，在发送阶段，音讯在客户端攒批到一定数量，直接 1 个 RPC 请求里边直接发到 broker 端。broker 存储阶段，直接把整批音讯存储，用批量索引的技能，一批音讯只会构建一个索引，大幅度进步索引构建速度。在消费阶段，也是依照整批数据读取到消费端，先进行解包操作，最终履行消费逻辑。这样整个 Broker 的音讯 TPS 可以从本来的 10 万级进步至百万级。
端和云的一致
第二个一致是端和云的一致，端指物联网设备端、移动端，云指云端服务和运用。
咱们先来了解一下物联网的场景是什么，以及音讯在物联网里边有什么效果。
物联网肯定是最近几年最火的技能趋势之一，有许多的研讨机构、职业陈述都提出了物联网快速开展的态势。
- 物联网设备规划爆发式增长，会在 2025 年达到 200 多亿台。
- 物联网的数据规划，来自物联网的数据增速挨近 28%，而且未来有 90% 以上的实时数据来自物联网场景。这也就意味着未来的实时流数据处理数据类型会有许多物联网数据。
- 重要的趋势是边际核算，未来会有 75% 的数据在传统数据中心或许云环境之外来处理，这里的边际指的是商铺、工厂、火车等等这些离数据源更近的当地。
经过这个图能看出音讯在物联网场景发挥的效果：
第一个效果是衔接， 承当通讯的责任，支撑设备和设备的通讯，设备和云端运用的通讯，比方传感器数据上报、云端指令下发等等这些功用，支撑 IoT 的运用架构，衔接云边端。
第二个效果是数据处理， 物联网设备源源不断的产生数据流，有许多需求实时流处理的场景，比方设备保护，高温预警等等。依据 MQ 的事情流存储和流核算才能，可以构建物联网场景的数据架构。
在一个完好的物联网解决方案中，会一起触及到端和云的协同，端用于收集数据、履行设备指令，云用于存储数据、剖析数据，履行杂乱事务逻辑。所以在 RocketMQ 5.0 里发布了 MQTT 子产品，完成端云一体化。它有 3 个中心特色：
- 选用规范的物联网协议 MQTT，该协议面向物联网弱网环境、低算力的特色规划，协议十分精简。一起有很丰厚的特性，支撑多种订阅形式，多种音讯的 QoS，比方有最多一次，最少一次，当且仅当一次。它的范畴模型规划也是 音讯、 主题、发布订阅等等这些概念，和 RocketMQ 特别匹配，这为打造一个云端一体的 RocketMQ 产品形状奠定了根底。
- 选用端云一体化的架构，由于范畴模型挨近、而且以 RocketMQ 作为存储层，每条音讯只存一份，这份音讯既能被物联网设备消费，也能被云端运用消费。别的 RocketMQ 本身是天然的流存储，流核算引擎可以无缝对 IoT 数据进行实时剖析。音讯可以来自各个接入场景（如服务端的 RocketMQ，设备端的 MQTT），但只会写一份存到 commitlog 里边，然后分宣布多个需求场景的行列索引，比方服务端场景（RocketMQ）可以依照一级 Topic 行列进行传统的服务端消费，设备端场景可以依照 MQTT 多级 Topic 以及通配符订阅进行消费音讯。这样就可以依据同一套存储引擎，一起支撑服务端运用集成和 IoT 场景的音讯收发，达到端云一体化。
- 将本来 RocketMQ 的万级行列才能进步到百万级行列才能。例如 Kafka 这样的音讯行列每个 Topic 是独立文件，可是跟着 Topic 增多音讯文件数量也增多，次序写就退化成了随机写，性能显着下降。RocketMQ 在 Kafka 的根底上进行了改进，运用了一个 Commitlog 文件来保存所有的音讯内容，再运用 CQ 索引文件来表明每个 Topic 里边的音讯行列，由于 CQ 索引数据比较小，文件增多对 IO 影响要小许多，所以在行列数量上可以达到十万级。可是这个终端设备行列的场景下，十万级的行列数量仍是太小了，希望进一步进步一个数量级，达到百万级行列数量，所以，引入了 Rocksdb 引擎来进行 CQ 索引分发，完成了百万级行列。
音讯和事情的一致
还有第三个一致是音讯和事情的一致。
在这之前， 咱们先了解一下什么是事情驱动。事情驱动本质上是一种软件规划形式，它可以最大化降低不同模块以及不同系统之间的耦合度。
下面是一个典型的事情驱动架构图，首先是事情出产者发送事情到 EventBroker，然后 EventBroker 会把事情路由到对应的顾客进行事情处理。事情处理可以灵敏扩展，随时增减事情顾客，事情出产者对此透明。
事情驱动架构其实是个很经典的规划形式，由于早在几十年前，就呈现过多种事情驱动的技能。比方桌面客户端编程结构，点击按钮就可以触发 onclick 事情，开发者编写事务逻辑呼应事情；在编程语言上，也经常会选用事情驱动的代码形式，比方 callback、handler 这类的函数；进入分布式系统的年代，系统之间的通讯协同也会选用事情驱动的方式。
从这个图咱们可以发现事情驱动架构其实和依据音讯的运用解耦差别不大，他们本质上要解决的都是解耦的问题。无论是音讯的发布订阅，仍是事情的出产消费都是为了进行代码解耦、系统解耦。音讯行列更偏技能完成，大部分的 EventBroker 都是依据音讯行列完成的，而事情驱动更倾向于架构理念。
事情驱动跟音讯驱动最大的差异便是，事情是一种特别的音讯，只有音讯满意了某些特征，才能把它叫做事情。
打个比方，来看上面这个图。音讯就像是一个笼统类，有多种子类，最首要的便是 Command 和 Event 两种。以信号灯为例，向信号灯发送翻开的音讯，这便是一种 Command，信号灯接受这个 Command 并开灯。开灯后，信号灯对外宣布信号灯变成绿色的音讯，这个便是一种 Event。
关于 Event 来说，有四个首要的特征：
- 它是一个不可变的，事情便是表明现已产生了的事情，现已成为事实。
- 事情有时间概念，而且对同一个实体来说事情的发送是有序的。如信号灯按次序发送了绿、黄、红等事情。
- 事情是无预期的，这个便是 EDA 架构之所以可以完成最大化解耦的特色，事情的产生者关于谁是事情顾客，怎么消费这个事情是不关怀的。
- 由于事情驱动是完全解耦的，而且关于下流怎么去消费事情没有预期，所以事情是具象化的，应该包含尽或许翔实的信息，让下流顾客各取所需。这便是音讯和事情的差异。
走向 Serverless
Serverless 大势
Serverless 被认为是下一代的云原生代表技能；云原生的本质则是经过一套技能系统和方法论，协助客户更好的用云，充分释放云核算盈利，让运用云核算的客户可以完成更高效、更低本钱的数字化转型。关于云原生的技能， 听的比较多有微服务、容器化等。微服务侧重于运用架构理念的改造，用微服务来完成事务高内聚、低耦合，然后进步研制功率、协作功率、事务灵敏度；而容器化则触及运用运维层面，用容器化来屏蔽根底设施的差异，进步可移植性，凭借 K8s 渠道，还能进步运用的运维功率、资源利用率。
而 Serverless 在云原生所代表的意义则是，根底技能下沉，云服务界面上移的趋势，本质上仍是让客户把更多的精力聚集在事务研制上，无需关怀底层技能和物理资源。
如下面这个图，在云核算之前，用户需求自建 IDC、购买物理机、自行虚拟化、建立中间件，然后才能进职事务研制，有许多的时间、精力、资源都花在和事务无关的项目上。进入云核算之后，越来越多的根底设施由云厂商来供给，从最早的 IaaS，直接运用云厂商的核算、存储、网络资源；再到 PaaS，无需自建数据库和中间件，直接运用保管根底软件服务；再到现在云核算演进到 Serverless 的阶段，客户完全把大部分精力聚集在事务代码的开发上。
对云服务厂商来说，Serverless 的云产品也从最早的少量产品如目标存储、函数核算等，开展到现在的 all on Serverless，具有了齐备的 Serverless 产品系统，如 Serverless 音讯行列、微服务、数据库、查找、大数据产品等。
全面 Serverless 的运用场景
进入 Serverless 年代，全面运用 Serverless 的客户会为音讯行列带来哪些场景改动呢？
- 如在运用侧，越来越多的运用不在布置在自行购买的 ECS 上面，直接保管在 Serverless 容器、运用引擎、函数核算上，云服务会依据其事务流量或许系统负载主动进行弹性弹性，对应的音讯服务也要能依据音讯流量自行弹性弹性；
- 在车联网音讯解决方案场景里，轿车每天都有迟早顶峰，上下行的音讯流量也呈现显着的波峰波谷，车联网客户无需为波峰流量预先购买音讯资源，而是依据实际音讯量，用多少付多少钱；
- 在移动 App 推送场景，也会面对更多维度的资源指标，比方需求维持许多的衔接数、偶尔的峰值音讯推送、极小的音讯存储空间，客户无需预先购买核算、存储、网络绑定的音讯实例，而是别离面向衔接数、音讯流量、存储空间别离付费。
- 除了中心的弹性才能之外，音讯行列的中心架构场景“事情驱动”在 Serverless 年代成为最重要的架构形式，事情驱动架构有助于开发愈加灵敏、可扩展、韧性的 Serverless 运用，事情驱动天然匹配 Serverless 研制范式。因而 Serverless 全云开发形式中，客户希望音讯行列的服务界面也需求上移，具有“事情总线”的才能。客户不只需求开箱即用的 Serverless 云服务，也需求开箱即用的事情驱动集成服务，无需像以前一样编写集成的胶水代码，研制功率进一步进步，走向 lowcode、nocode。比方云产品事情集成，OSS 文件上传事情发送到事情总线，用户订阅这个事情，并依据函数核算进行文件加工处理呼应事情，驱动 Serverless 算力。
面向 Serverless 的趋势，RocketMQ 5.0 从产品形状到技能架构都做了巨大的演进。
面向 Serverless 运用的新 SDK
当运用许多运用 Serverless 技能之后，运用的实例数将会跟着流量的改动动态弹性弹性，比较于过去的场景，实例数改动将十分频频，这就对音讯收发的负载均衡提出比较大的应战。
先来看出产链路的负载均衡，出产者经过服务发现机制，知道了 Topic 的数据分片以及对应的 Broker 地址。他的服务发现机制是比较简略的，在默认情况下选用 RoundRobin 的方式轮询发送到各个 Topic 行列，确保了 Broker 集群的流量均衡。出产者是完全无状况的，所以无论怎么弹性弹性，都没有太多影响。
再来看下顾客的负载均衡，相对来说它会比出产者更杂乱，旧形式是行列级负载均衡，顾客知道 Topic 的行列总数，也知道同一个 ConsumerGroup 下的实例数，就可以依照一致的分配算法，类似一致性 hash 的方式，让每个顾客实例绑定对应的行列，只消费绑定行列的音讯，每个行列的音讯也只会被一个顾客实例消费。这种形式最大的缺陷便是负载不均衡，顾客实例要绑定行列、有暂时状况。当运用实例数改动频频的时候，这种负载不均衡会导致运用的 Serverless 扩容无效，扩容的新阶段无法分管音讯的流量。如图 Topic 有 2 个分区，扩容第三个节点会呈现空跑；如果把 Topic 扩容成 3 个分区，随后顾客实例又缩容回 2 个，那么就会呈现其间一个顾客实例承当三分之二的流量，呈现过载。
所以在 RocketMQ5.0 里边， 引入了音讯粒度的负载均衡机制，无需绑定行列，音讯在顾客集群随机分发，这样就可以确保顾客集群的负载均衡。更重要的是这种形式愈加符合全链路 Serverless 化的场景，Broker 的机器数、Topic 的行列数和顾客实例数完全解耦，可以独立扩缩容。
Serverless 事情驱动的应战
在上一个章节， 提到音讯和事情的一致，事情是一种包含事务语义的音讯。下面结合一个典型事情驱动的事例来看看。
如下图是一个依据音讯行列 RocketMQ 完成的一个买卖系统，选用事情驱动的架构，围绕“订单”事情完成买卖事务。事情出产者是买卖中心，顾客是买卖的下流系统。比方发送订单创立事情，购物车呼应事情，删除之前的加购产品；产生订单付款事情，会员系统呼应事情，给客户添加积分，物流系统呼应事情，履行后续的发货履约环节。整个买卖系统是由“事情驱动”的微服务构建而成。
依据经典音讯行列的事情驱动方案在一个安排内部、部分内部是一个不错的挑选。可是在 Serverless 年代面对许多全新的应战。
- 越来越多的商业数字化解决方案是由多个不同安排协作完成的，比方 SaaS 渠道（钉钉）和它的合作伙伴，钉钉渠道发布各种事情，包含视频会议、日程、通讯录、审批流、钉盘等事情，下流合作伙伴消费这些事情，研制职业运用。在这类新式数字化解决方案中，往往事情的出产者和顾客属于不同的公司，开发者无法进行密布的交流，低本钱的了解“事情”界说、格局、运用方法。现在的形式过于依靠开发者之间的交流，以及公司的内部文档沉淀。
- 不同的公司往往会运用不同的技能系统，比方运用不同的音讯行列，事情出产者运用 RocketMQ，事情顾客运用 RabbitMQ；比方运用不同的音讯传输协议，HTTP 或 AMQP。
- 事情的顾客多样化，哪怕是同一个事务的事情，事情顾客或许只需求其间的某种子类型；哪怕是同一个事情，事情顾客也或许只能拜访其间的部分字段。
- 缺少开箱即用的事情集成才能，客户全面用云后，需求呼应各种云产品事情，比方呼应 OSS 上传事情，运用函数核算对文件进行处理，这种预先集成的特性，经典的音讯行列不具有。
Serverless 的事情驱动技能需求愈加完全的解耦，只重视“事情”本身，解耦技能完成细节，如传输协议、SDK、出产消费形式。
Serverless 事情驱动的规划
为了完成 Serverless 的事情驱动， 在音讯行列的根底上面，将“事情驱动”场景的服务界面上移，围绕“事情”的范畴模型进行从头规划。
最左面是事情源，由于事情需求具有跨渠道出产消费的才能，所以选用 CNCF 的 CloudEvents 来作为事情的格局。这个是业界事情的事实规范，它规范简化了事情声明，进步事情在跨服务、跨渠道的互操作性。
由于事情是有或许被跨安排消费的，所以需求一个一致的事情中心，让这些不同的事情源都注册到这个事情中心。对顾客来说就好比是一个事情商铺，可以挑选自己感兴趣的事情订阅。
在事情顾客开端编写消费逻辑的时候，开发者还需求对这个事情的格局有更清楚的了解，需求知道这个事情有哪些内容，有哪些字段，别离是什么意义，才能编写正确的消费事务逻辑。所以，事情总线还供给了 schema 中心，有这个 schema 中心后，顾客关于事情的格局也就一望而知，不必跟事情源的发起者进行沟通了，整个功率也得到了大幅度的进步。
再往后边看，就到了事情消费的环节，由于事情的顾客品种许多，不同顾客重视不同的事情类型，事情总线需求供给丰厚的过滤规矩。即便多个顾客对同一个事情感兴趣，可是或许只需求事情的部分内容，事情总线还供给了事情转换的才能。这便是 RocketMQ5.0 对事情驱动的才能笼统。
Serverless 事情驱动的新形状
依据上面的全新规划，以 RocketMQ 作为事情存储的内核，完成了全新的事情总线 EventBridge。
在产品界面上，面向事情驱动的事务进行一层笼统，中心范畴目标从音讯变成 CloudEvents。依据一致事情规范来构建事情驱动的数字生态。
事情源是多样化的，可所以云产品事情、数据流事情、也可所以 SaaS 渠道事情，运用自界说事情、通用的 WebHook。当然，它的事情目标也是多样化的，经过事情规矩引擎把事情路由到不同的顾客，典型的顾客包含函数核算、音讯系统（用于解耦出产者、顾客运用不同的音讯行列技能）、存储系统、流核算引擎、通用的 webhook，乃至可所以音讯通知如语音短信邮件。事情驱动架构更适合建造混合云、多云的数字化系统。
经过 EventBridge 完成完全的事情驱动架构，真正做到只关怀“事情”本身，出产者和顾客完成愈加完全的解耦，包含安排解耦、技能系统解耦。
面向 Serverless 音讯内核的重构
前面提到的首要是面向 Serverless 运用场景，如一些 Serverless 化的运用，Serverless 化的事情驱动架构，RocketMQ 在产品形状、运用界面上做出的改动。现在咱们从技能架构演进的视点来看 RocketMQ 怎么完成一个 Serverless 化的音讯云服务。在 Serverless 场景下，客户需求的是声明式的逻辑资源，不同逻辑资源可以解绑，别离弹性、按量服务。
面向 Serverless 的场景，RocketMQ 演进到三层存算别离的架构。
- 第一层是 RocketMQ proxy，它首要承载的是多协议，多范畴场景的掩盖。这里边的范畴场景有 RocketMQ 场景，经典的服务端运用集成；还有 MQTT，面向物联网的运用；还有 EventBridge 面向事情驱动型的运用。Proxy 可以认为是核算资源的首要载体，它是一个完全的无状况的网关。它可以面向客户不同的衔接数，不同的音讯 TPS 以及不同的音讯的读写的比例的改动，进行一个核算、网络资源的独立弹性。这样才可以匹配到客户在 Serverless 场景下，对多种资源解耦弹性的需求。
- 第二层是 RocketMQ 的存储引擎，它首要专注于音讯多副本完成、多副本怎么进行高可用切换。一起它也要负责本地存储跟云存储的一致笼统。由于音讯的存储首要在云盘和目标存储上面，大部分的音讯数据存储在目标存储，store 本身的状况被弱化了，弹性功率也得以进步。RocketMQ store 可以依据客户的音讯流量特色，如音讯吞吐量、TPS、音讯巨细、批量要素等和存储资源 IOPS、带宽、存储空间进行弹性匹配，完成音讯存储和核算的解耦。
- 第三层是云存储层这一块，大部分的音讯存储在目标存储上，这是公共云根底设施级的存储池化。经过将冷数据卸载到了目标存储，然后缩短了 RocketMQ Store 的生命周期，一起也具有一个低本钱的无限音讯存储空间。
现在 RocketMQ5.0 现已具有弹性架构，选用云服务形状的 RocketMQ 可以进一步和云的根底设施深度结合，充分释放云核算盈利。
在核算层面，RocketMQ 5.0 经过容器服务充分利用 ECS 弹性才能，采取弹性资源池 HPA 相关技能支撑核算才能快速弹性，一起 ACK 自带的跨可用区布置才能为云产品供给了充足的高可用确保。
在网络层面，RocketMQ 5.0 可接入了多种云原生网络才能，满意用户对多样性网络的需求，公网随开随用，支撑多种私网网络形状，依据 CEN 构建了全球互通的音讯网络，完成异地多活。
在存储方面，依据盘古 DFS、目标存储的多级存储架构，供给低本钱的无限存储才能，冷热数据链路别离，供给更高的 SLA。
事情驱动赋能 Serverless 技能栈
最终，依据 Apache RocketMQ 打造的音讯产品系统，以事情驱动 集成两大场景，赋能全面 Serverless 技能栈。
以上是一个典型的 Serverless 产品系统，一些头部云厂商现已完成了中心产品的全面 Serverless 化，无论是核算、存储，仍是大数据剖析都具有了 Serverless 服务才能，依据这些才能客户可以打造端到端的 Serverless 运用，聚集中心事务，把降本增效做到极致。
加入 Apache RocketMQ 社区
十年铸剑，Apache RocketMQ 的生长离不开全球 800 多位开发者的积极参与贡献，相信在下个版本你便是 Apache RocketMQ 的贡献者，在社区不只可以结识社区大牛，进步技能水平，也可以进步个人影响力，促进本身生长。
