ApsaraMQ Serverless 能力再升级，事件驱动架构赋能 AI 应用 ...

本文整理于 2024 年云栖大会阿里云智能集团高级技能专家金吉祥（牟羽）带来的主题演讲《ApsaraMQ Serverless 能力再升级，事件驱动架构赋能 AI 应用》

云消息队列 ApsaraMQ 全系列产物 Serverless 化，支持按量付费、自适应弹性、跨可用区容灾，资助客户降低使用和维护本钱，专注业务创新。那 ApsaraMQ 是怎样一步一步完成 Serverless 能力升级的？在智能化时代，我们的事件驱动架构又是怎样拥抱 AI、赋能 AI 的？
本次分享将从以下四个方面睁开：

• 首先，回顾 ApsaraMQ Serverless 化的完备历程，即 ApsaraMQ 从阿里内部诞生、开源，到捐赠给 Apache 进行孵化，再到完成 Serverless 化升级的不停突破、与时俱进的过程。
  
• 然后，重点先容 ApsaraMQ 的存算分离架构，这是全面 Serverless 化历程中不可或缺的条件。
  
• 接下来，会从技能层面重点解读近一年 ApsaraMQ Serverless 能力的演进升级，包罗弹性能力的升级、基于 RDMA 进一步降低存储和计算层之间的 CPU 开销，以及对无感扩缩容的优化。
  
• 末了，先容我们在面向 AI 原生应用的事件驱动架构上的探索，以及基于阿里云事件总线定向更新向量数据库，为 AI 应用融入实时最新数据的最佳实践。
  

ApsaraMQ Serverless 化历程

首先，我们来看 ApsaraMQ Serverless 化的整个发展历程。

• 2012 年，RocketMQ 在阿里巴巴内部诞生，并将代码在 Github 上开源；
  
• 2016 年，云消息队列 RocketMQ 版开启商业化的同时，阿里云将 RocketMQ 捐赠给了 Apache，进入孵化期；
  
• 2017 年，RocketMQ 以较短的时间孵化成为 Apache TLP，并快速迭代新功能特性，顺利发布 4.0 版本，支持了次序、事件、定时等特殊类型的消息；
  
• 2018 年，随着大数据、互联网技能的发展，数据量发作式增长，云消息队列 Kafka 版商业化发布；
  
• 2019 年，云消息队列 RabbitMQ 版、云消息队列 MQTT 版两款产物商业化发布，补齐了 ApsaraMQ 在 AMQP、MQTT 协议适配上的缺失；
  
• 2021 年，颠末一段时间的孵化，ApsaraMQ 家族中的另一款产物事件总线 EventBridge 开始公测，开始融合事件、消息、流处理；
  
• 2023 年，ApsaraMQ 全系列产物依托存算分离架构，完成 Serverless 化升级，打造事件、消息、流一体的融合型消息处理平台；
  
• 今年，我们专注提拔核心技能能力，包罗秒级弹性、无感发布、计算存储层之间的 RDMA 等，实现 Serverless 能力的进一步升级，并联合当下客户需求，通过事件驱动架构赋能 AI 原生应用。
  

存算分离架构全景

第二部分，我们来看 ApsaraMQ 存算分离架构的全景，这是 Serverless 化升级不可或缺的前序预备。
ApsaraMQ 存算分离架构全景：云原生时代的选择

ApsaraMQ 的存算分离架构，是云原生时代的选择。

• 从下往上看，这套架构是完全构建在云原生基础之上的，整个架构 K8s 化，充分利用 IaaS 层的资源弹性能力，同时也基于 OpenTelemetry 的标准实现了metrics、tracing 和 logging 的标准化。
  
• 再往上一层是基于阿里云飞天盘古构建的存储层，存储节点身份对等，Leaderless 化，副本数量灵活选择，可以在降低存储本钱和保证消息可靠性之间实现较好的均衡。
  
• 再往上一层是在本次架构升级中独立抽出来的计算层，即无状态消息代理层，负责访问控制、模子抽象、协议适配、消息治理等。比较关键的点是，它是无状态的，可独立于存储层进行弹性。
  
• 在用户接入层，我们基于云原生的通讯标准 gRPC 开发了一个全新的轻量级 SDK，与之前的富客户端形成了很好的互补。
  

“Proxy” 必要代理什么？

接下来我们重点看下这套架构里的核心点，即独立抽出来的 Proxy。
它是一层代理，那到底必要代理什么呢？
在之前的架构中，客户端与 Broker/NameServer 是直连模式，我们必要在中心插入一个代理层，由原先的二层酿成三层。然后，将原先客户端侧部分业务逻辑下移，Broker、Namesrv 的部分业务逻辑上移，至中心的代理层，并始终坚持一个原则：往代理层迁移的能力必须是无状态的。
从这张图中，我们将原先客户端里面比较重的负载均衡、流量治理（小黑屋机制）以及 Push/Pull 的消费模子下移至了 Proxy，将原先 Broker 和 Namesrv 侧的访问控制（ACL）、客户端治理、消息路由等无状态能力上移至了 Proxy。然后在 Proxy 上进行模块化计划，抽象出访问控制、多协议适配、通用业务能力、流量治理以及通用的可观测性。
ApsaraMQ 存算分离的技能架构

接下来看 ApsaraMQ 存算分离的技能架构，在原先的架构基础上剥离出了无状态Proxy 组件，承接客户端侧所有的哀求和流量；将无状态 Broker，即消息存储引擎和共享存储层进行剥离，让存储引擎的职责更加聚焦和收敛的同时，充分发挥共享存储层的冷热数据分离、跨可用区容灾的核心上风。
这个架构中无状态 Proxy 承担的职责包罗：
1. 多协议适配： 可以或许辨认多种协议的哀求，包罗 remoting、gRPC 以及 Http 等协议，然后同一翻译成 Proxy 到 Broker、Namesrv 的 remoting 协议。
2. 流量治理、分发： Proxy 具备按照差别维度去辨认客户端流量的能力，然后根据分发规则将客户端的流量导到后端正确的 Broker 集群上。
3. 通用业务能力扩展： 包罗但不限于访问控制、消息的 Tracing 以及可观测性等。
4. Topic 路由代理： Proxy 还代理了 Namesrv 的 TopicRoute 功能，客户端可以向 Proxy 问询某个 topic 的具体路由信息。
5. 消费模子升级： 使用 Pop 模式来制止单客户端消费卡住导致消息堆积的历史题目。
无状态 Broker，即消息存储引擎的职责更加的聚焦和收敛，包罗：
1. 核心存储能力的迭代： 专注消息存储能力的演进，包罗消息缓存、索引的构建、消费状态的维护以及高可用的切换等。
2. 存储模子的抽象： 负责冷热存储的模子同一抽象。
共享存储为无状态 Broker 交付了核心的消息读写的能力，包罗：
1. 热存储 EBS： 热存储 EBS，提供高性能、高可用存储能力。
2. 冷存储 OSS： 将冷数据卸载到对象存储 OSS，获取无限低本钱存储空间。
3. 跨可用区容灾： 基于 OSS 的同城冗余、Regional EBS 的核心能力构建跨可用区容灾，交付一写多读的消息存储能力。
基于云存储的存算分离架构，分身消息可靠性和本钱

存算分离架构中的存储层是完全构建在阿里云飞天盘古存储体系之上的。基于这套架构，我们可以或许灵活控制消息的副本数量，在保证消息可靠性和降低存储本钱之间做到一个比较好的均衡。
左图是存算分离存储架构中上传和读取的流程。可以看到，我们是在 CommitLog 异步构建 consumeQueue 和 Index 的过程中额外添加了按照 topic 拆分上传到对象存储的过程；在读取过程中智能辨认读取消息的存储 Level，然后进行定向化读取。
基于云存储的架构，我们提供了 ApsaraMQ 的核心能力，包罗：
1. 超长时间定时消息： 超过一定时间的定时消息所在的时间轮会保存至对象存储上，快到期时时间轮再拉回到当地进行秒级精准定时。
2. 集群缩容主动接管： 消息数据实时同步到对象存储，对象存储的数据可以或许动态挂载到任意 Broker，实现彻底存算分离，Broker 的无状态化。
3. 按需设置 TTL 本钱优化： 支持按需设置消息 TTL，差别重要程度的消息可设置差别的 TTL，满意消息保存时长需求的同时分身本钱控制。
4. 冷热消息分离、分段预取： 热数据的读取掷中当地存储，速率快；冷数据的读取掷中远端存储，速率恒定且不会影响热数据的读取。
5. 动态调控云存储的比例： 动态调控 EBS 和 OSS 的比例，大比例的 EBS 可以或许具备更高的稳定性，应对 OSS 负载过高的背压，提拔 EBS 作为 OSS 的前置容灾的能力；小比例的 EBS 则是可以最大化降低消息单位存储本钱，让团体的存储本钱趋同于 OSS 存储本钱。
Serverless 能力再升级

有了存算分离架构的铺垫，ApsaraMQ 全系列产物 Serverless 化就更加顺畅了。接下来睁开先容 ApsaraMQ Serverless 能力的升级。
消息场景下的 Serverless 化

在消息场景下通常会有两个角色：消息服务的使用方和提供方。
在传统架构中通常是如许的流程：使用方会给提供方提需求：我要大促了，你保障下；提供方说给你摆设 10 台够不够，使用方说好的；结果真到大促那一刻，真实流量比预估的要大很多倍，整个消息服务被击穿，硬生生挂了半小时。
在 Serverless 化改造前，仍需提前规划容量；但相比传统架构的提拔点是，依托 IaaS 层的快速扩容能力，可以或许极大缩短扩容时间；再演进到当前的 Serverless 架构，我们期望消息服务提供方是可以或许非常淡定地应对大促。
Serverless 现在已经成为了一个趋势和云的发展方向。ApsaraMQ 全线产物实现弹性灵活的 Serverless 架构，既彰显了技能架构的先进性，也提拔了客户的安全感。业务部分减少了容量评估的沟通本钱，用多少付多少，更省本钱；运维部分免去了容量规划，实现主动弹性扩缩，降低运维人员投入的同时，大大提拔了资源的利用率。
Serverless 方案的 Why / What / How

Serverless 化预期到达的收益是：省心——秒级弹性，免容量规划；省钱——用多少付多少；省力——少运维、免运维。
要办理的痛点是：用户使用容量模子比较难做精准预估；运维侧手动扩容，是一个非常耗时耗力的过程。
核心目的是：

• 弹性要快： 特别是针对一些脉冲型的秒杀业务，必要具备秒级万 TPS 的弹性能力。
  
• 缩容无感： 应对 MQ 客户端与服务侧 TCP 长连接的特性，缩容、服务端发布时要无感。
  
• 本钱要低： 极致的性能优化，才华进一步降低用户侧的单位 TPS 本钱。
  

通过如下几个关键路径构建 ApsaraMQ Serverless 核心能力：

• 多租、安全隔离、业务流量隔离： 是构建 Serverless 核心能力的基础。
  
• 物理预弹&逻辑弹性： 物理预弹和逻辑弹性联合的极致弹性方案，通过镜像加速、元数据批量创建、主动路由更新等核心技能加速物理弹性，联合逻辑弹性终极交付秒级万 TPS 的极致弹性能力。
  
• RDMA： 在存储和计算层之间引入 RDMA 技能，充分利用 RDMA 的零拷贝、内核旁路、CPU 卸载等特性进一步降低计算层与存储层之间的通讯开销。
  
• 优雅上下线： 依托 gRPC 协议的 GOAWAY 以及 Remoting 协议的扩展实现 TCP 长连接的优雅上下线。
  
• 控制资源水位： 通过智能化的集群流量调理以及平滑 Topic 迁移方案，进一步控制单个集群的资源水位在一个合理的值。
  

这套 Serverless 方案可以同时满意如下几种场景：

• 第一种是平稳型：流量上升到一定水位后会平稳运行。
  
• 第二种是稳中有“进”型：流量平稳运行的同时，偶尔会有一些小脉冲。
  
• 第三种是周期性“脉冲型”：流量会周期性地变化。
  

计算、存储与网络：充分利用云的弹性能力

我们前面也有提到，这套架构是完全构建在云原生基础设施之上的，我们在计算、存储、网络上都充分利用了云的弹性能力，具体来看：

• 在计算侧，通过 K8s 充分利用 ECS 的弹性能力，通过弹性资源池、HPA 等核心技能支持计算层的快速弹性，并通过跨可用区摆设提拔可用性。
  
• 在存储侧，充分利用飞天盘古存储的弹性能力，支持自界说消息的存储时长，冷热数据分离，额外保障冷读的 SLA。
  
• 在网络侧，公网随开随用，安全和方便兼具，支持多种私网形态接入，并基于 CEN 构建环球互通的消息网络。
  

在这之上，联合 SRE 平台的智能集群流量调理、集群水位监控、物理预弹性等核心能力，终极交付了一套完备的 ApsaraMQ Serverless 化物理弹性能力。
秒级万 TPS 的极致弹性能力保障

依托于上面的基础物理资源的弹性能力，来看下我们是怎样保障秒级万 TPS 的极致弹性能力的？
从两个维度来看用户视角的弹性：

• 从限流维度看： 在无损弹性上限以内的 TPS，都不会触发限流；超过无损弹性 TPS 上限后，会有秒级别的限流，通过逻辑弹性调整实例级别的限流阈值后，即可实现终极的 TPS 弹性。
  
• 从付费角度看： 在预留规格内按规格进行预付费；超过预留规格的上限 TPS，超过部分按量付费，即用多少付多少。
  

为了满意用户视角的秒级弹性能力，我们通过物理弹性和逻辑弹性相联合的方式来进行保障：

• 物理弹性是预弹的机制，弹性时间在分钟级，用户侧无任何感知，由服务侧来 Cover 本钱。
  
• 逻辑弹性是实时生效的，弹性时间在秒级，同时在触发无损弹性 TPS 上限时，用户侧是会有秒级别的限流感知的，另一方面，用户是必要为弹出来的那部分流量进行按量付费的。
  

两者的关系是：物理弹性是逻辑弹性的支撑，逻辑弹性依赖物理弹性。从弹性流程上看，当用户的流量触发无损弹性上限时，优先判断物理资源是否富足，富足的话就进行秒级逻辑弹性，不富足的话就等待物理资源扩容后再进行逻辑弹性。当然这里会有个预弹的机制，尽量保障逻辑弹性时物理资源都是富足的。
从物理弹性加速来看，通过以下几个方面进行加速：

• 计算、存储层按需弹性： 计算层更关注 CPU、客户端连接数等核心指标；存储层更关注内存、磁盘 IO 等性能指标。
  
• 镜像下载加速： 通过 PlaceHolder + 镜像缓存组件加速新节点的扩容。
  
• 新增元数据批量创建的机制： 新增存储节点创建 5000 级别的 Topic 下降至 3 秒。
  
• 新增主动路由更新机制： 降低存储节点物理扩容后承接读写流量的延迟。
  

我们的系统计划细密，旨在确保用户体验到极致的弹性能力，特别是实现每秒万次事件处理（TPS）的秒级弹性扩展。这一能力的保障策略围绕两个核心维度睁开，并深度融合物理与逻辑弹性机制，确保在高吞吐需求下的无缝相应与本钱服从。
ApsaraMQ on RDMA：降低计算与存储层之间通讯开销

RDMA（全称长途内存直接访问）是一种高性能的网络通讯技能，相比 TCP/IP 的网络模式，具有零拷贝、内核旁路、CPU 卸载等核心上风。ApsaraMQ Serverless 化架构具备存算分离的特点，非常适合在计算层和存储层之间引入 RDMA 技能，进一步降低内部组件之间的数据通讯开销。
具体来看，计算层 Proxy 在接收到客户端各种协议的消息收发哀求以后，通过内置的 Remoting Client 和存储层 Broker 进行数据互换。在原先的 TCP/IP 网络模式中，这些数据是必要从操作系统的用户态拷贝到内核态后，再经由网卡和对端进行交互。依托 RDMA 内核旁路特性，通过实现 RdmaEventLoop 的适配器，消息直接由用户态到 RDMA 网卡和对端进行交互。
从终极 BenchMark 的测试效果来看，引入 RDMA 技能后，存储层 Broker 的 CPU 资源斲丧下降了 26.7%，计算层 Proxy 的 CPU 资源斲丧下降了 10.1%，计算到存储的发送 RT 下降了 23.8%。
优雅上下线：ApsaraMQ Serverless 弹性如丝般顺滑

在 Serverless 场景下，物理资源的程度弹性扩缩是一个常态化的过程，同时联合 MQ 客户端和计算层 Proxy TCP 长连接的特点，在 Proxy 上下线过程中是比较轻易出现连接断开的感知，比如客户端刚发出一个接收消息的哀求，连接就被服务侧强行关闭了，是非常轻易造成单次哀求超时的异常的。
因此，我们通过 gRPC 协议 Http2 的 Go Away 机制以及 Remoting 协议层的扩展，联合 SLB 连接优雅终端的能力来实现 ApsaraMQ 在扩容态、缩容态、以及发布态的无感。
右图展示了缩容态下单台 Proxy 优雅下线的过程：

• 当收到 Proxy-0 必要下线的指令后，SLB 会将 Proxy-0 摘除，保障新的连接不再建立到 Proxy-0 上，同时 Proxy-0 进入 Draining 状态，旧连接进行会话保持。
  
• Proxy-0 上收到新的哀求后，返回的 Response Code 都更新为 Go Away；同时客户单收到 Go Away 的 Response 后，断开原先的连接，向 SLB 发起新建连接的哀求。
  
• SLB 收到新建连接的哀求，会导流至 Proxy-1。
  
• 等待一段时间后 Proxy-0 上的连接会自然消亡，终极到达无感下线的目的。
  

事件驱动架构赋能 AI 应用

接下来，将叙述面向 AI 原生应用的事件驱动架构怎样拥抱 AI，赋能 AI 应用发达发展。

• 面向 AI 应用的实时处理，具备实时 Embedding 至向量数据库、更新私有数据存储的能力，全面提拔 AI 应用实时性、个性化和准确度。
  
• 面向 AI 应用的异步解耦，解耦 AI 推理链路的快慢服务，加快应用相应速率。
  
• 面向 AI 应用的消息负载，ApsaraMQ 支持主动 Pop 消费模式，允许动态设置每一条消息的个性化消费时长. 同时也支持优先级队列，满意卑鄙多个大模子服务的优先级调理。
  
• 面向 AI 应用的消息弹性，ApsaraMQ 提供全模式的 Serverless 弹性能力，支持纯按量和预留+弹性、定时弹性等多种流量配置模子；
  

末了，让我们来看下阿里云事件总线 EventBridge 是怎样实现数据实时向量化，提拔 AI 应用的实时性和准确度的？
阿里云事件总线的 Event Streaming 事件流处理框架，具备监听多样化数据源，然后颠末多次 Transform 之后再投递给卑鄙数据目的的原子能力；依托这个框架，我们是很轻易去实现数据的实时向量化的，从 RocketMQ、Kafka、OSS 等多个源监听到实时数据流入之后，颠末文本化、切片、向量化等操作，终极存入向量数据库，作为 AI 应用实时问答的多维度数据检索的依据，终极提拔了 AI 应用的实时性和准确度。
点击此处，观看本场直播回放。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。