消息中间件作为消息通信的基础软件，已在业界诸多 IT 系统中被广泛使用。近年来，随着移动云业务的持续高速发展，基于开源技术生态构建的消息中间件云产品体系越来越受到市场的青睐。移动云在消息中间件领域的技术演进与发展方向上一直坚持着自研和开源融合的发展路线，在做好自研的基础上积极拥抱开源生态。
在刚刚落幕的 CommunityOverCode Asia 2023 开源盛会上，中国移动云能力中心消息中间件领域技术专家、移动云消息队列团队负责人胡宗棠向大家介绍了移动云消息队列产品矩阵在开源领域与产品商业化的发展历程、作为云基础设施领域的探索与实践，以及未来的创新计划。
移动云为云端用户提供了多元化的消息队列产品矩阵（包括 RocketMQ、MQTT、RabbitMQ 和 Kafka）。RocketMQ，作为互联网新兴业务领域首选的消息通信产品，可为用户提供金融交易级的消息可靠性保障能力；MQTT，作为移动互联网、物联网和边缘计算的数据流转产品，可为用户提供丰富的消息终端接入能力；Kafka，作为大数据首选的数据通道类产品，可为用户提供数据加工和批流一体计算能力；RabbitMQ，作为传统业务领域的消息管道类产品，为用户提供稳定高效的消息并发访问能力。
移动云消息队列产品矩阵完全构建在移动云基础设施上（包括计算、存储和网络等基础设施部分），基本实现了应用场景全覆盖，包括微服务解耦、互联网 SaaS 应用、IOT 物联网、大数据流计算或日志收集生态，同时也在内部覆盖了移动云端的所有业务，在云上为企业客户提供了优质的消息服务。
移动云消息队列产品的商业化历程主要经历了几个阶段。在 2015 至 2018 年，消息中间件以组件的形式完成了生产环境的大规模部署与实践，实现了中国移动信令传输等场景的落地与应用。在 2019 至 2021 年，RocketMQ/Kafka/MQTT 以云服务的形式，在移动公有云上完成了正式商用上线 年，自研的 AMQP 消息中间件完成了移动云生产环境所有 Region 的替换上线，成为业界首家在 OpenStack 基础设施领域完成自研消息中间件超大规模实践的云厂商shadowrocket节点信息在哪。从当前至未来，我们会继续探索软硬一体化设计的技术演进路线，构建面向数字基础设施的通信新基座能力。
在 2020 至 2022 年，团队与 StreamNative 联合发起开源 AMQP on Pulsar 项目，该项目是业界首个面向 OpenStack 基础设施领域的开源消息中间件的解决方案。从 2023 年开始，团队在欧拉社区牵头创建了消息中间件 sig 组，致力于将移动云多年来在消息中间件领域的积累开源并贡献给业界。
随着 OpenStack 在中国移动公有云端的部署规模越来越大，消息并发量也呈现指数级增长，在大量连接数、多 Queue 队列和高 TPS 流量峰值的场景下，开源 RabbitMQ 的系统架构设计存在着一定的限制，主要有以下问题：
开源 RabbitMQ（3.8.9 版本） 集群在开启镜像队列后性能较低。1KB 大小的消息，TPS 在 2 万 / 秒左右，当消息堆积量增大后会导致集群性能明显下降。
借助 Pulsar 算存分离的云原生技术架构，通过自研的 AMQP 协议转换组件、元数据存储方案、自适应的多 bundle 负载均衡算法和冷热分离存储方案，我们推出了 Aop（AMQP on Pulsar） 项目，其在面对海量 queue 队列、多连接数和超高 TPS 流量峰值场景下，依旧可以提供低延迟、高可靠的消息队列服务能力。从上面 PPT 图中可以看出，Aop 在数据可靠性、连接数限制、服务可用性、消息堆积能力和可观测性上，相比开源 RabbitMQ 都具备一定的优势。
作为面向 OpenStack 领域的消息通信中间件基座，基于 Aop 项目研发的 AMQP 高性能消息队列，目前已在移动云上完成了 600+ 台服务器规模的部署，上线移动云全量资源池（完成单个 3 节点组成的 Aop 集群纳管 3000+ 计算节点规模），日消息流转量达到了百亿条规模，解决开源 RabbitMQ 的诸多痛点问题，为中国移动超大规模算力网络构建提供消息通信的重要保障，同时为业界提供 Openstack 超大规模实践的消息通信解决方案。
随着云计算技术的蓬勃发展和落地，越来越多企业客户选择采用云服务快速完成业务数字化转型，更好地适应市场变化，其中有很多的企业基于降低技术开发和运维成本，选择将自己的业务部署在云端；还有一部分企业出于数据和安全隐私方面的考虑，选择在内部数据中心搭建专有云平台；而对公有云和专有云都有需求的企业用户，则选择搭建混合云 / 多云的架构搭建其业务系统。
移动云 RocketMQ 消息队列产品作为互联网新兴业务领域首选的消息通信产品，近年来日益收到客户的青睐，很多企业用户在选择混合云 / 多云架构搭建其业务系统时候，会考虑将 RocketMQ 消息队列作为构建其数字化业务系统在多云之间互联互通的数据通信管道。然而，鉴于 RocketMQ 4.X 版本与客户端之间的 2 次访问模型（也即为：客户端与 RocketMQ 的 Broker 所有节点的直连模式）会带来如下的几个典型问题：
（2）直连模式无法满足云端用户丰富的网络接入访问（公网 /VPC 内网 / 跨云访问接入）；
通过引入 RocketMQ 5.0 的无状态代理组件，同时新增支持 RocketMQ 原生 Remoting 协议的适配和兼容性，移动云 RocketMQ 消息队列产品实现了算存分离的完全云原生架构，解决了在多云 / 混合云应用架构下遇到的场景和诸多挑战，调整后的优势如下：
（1）解决了 RocketMQ 4.X Broker 直连模式下，对云端网络访问接入（公网 /VPC 访问）的绑定和限制问题；客户端只与 Proxy 代理层连接，针对多网络类型接入的诉求，可以将多网络类型绑定到 Proxy 代理层，保证了多类型网络接入是与集群规模无关的；
（2）Proxy 代理层易于实现流量隔离、ACL 鉴权和多协议适配等业务操作；
（3）Proxy 代理层无状态，可根据用户以及客户端的流量进行水平弹性扩缩容，完全支持云原生的语义；
（4）Proxy 代理组件属于计算型资源，相对消耗 CPU；Broker 属于存储型资源，相对消耗磁盘空间和存储 IO；便于部署时候提前规划资源类型和资源容量；
传统的 TCP/IP 网络（指内核态 TCP）一直是业界主流的网络通信协议，目前大部分云计算产品技术都是基于 TCP/IP 构建，但随着超算 / 智算数据中心相关的业务发展，云产品对于网络性能的需求越来越强烈。但是，传统 TCP/IP 网络方案存在如下几个典型问题：
（1）系统调用导致 CPU 在用户态和内核态之间来回切换，消耗大量时间；
（2）发送 / 接受过程中需要 CPU 把数据从用户空间到内核空间来回复制，增加了数据在网络中的传输延时；
（3）需要 CPU 参与数据包的封装和解析，在数据量大时将对 CPU 将造成很重的负担；因此，传统 TCP/IP 网络方案中的网络 IO 时延成为制约消息中间件（比如，Kafka）在大模型、AI 训练和批流计算等领域发展的重要因素。
为解决 TCP/IP 网络方案中时延和吞吐瓶颈，新一代高性能无损网络技术—RDMA（Remote Direct Memory Access）逐渐成为云计算时代超低时延网络传输的利器。概括地来说，RDMA 是一种基于硬件加速的网络传输技术，可以实现在完全无 CPU 参与下的数据传输，提高整体传输效率和性能（超低延迟、高吞吐量和低 CPU 开销）。从上面的图中可以看出 RDMA 在数据传输中的几个主要特点：
（2）在系统内存内部做到完全零拷贝，节省了数据在用户空间和内核空间之间拷贝的步骤；
（3）把数据包的封装和解析任务交给 RDMA 网卡硬件来完成，实现了 CPU 卸载；
我们希望借助 RDMA 网络技术为消息中间件实现网络层面的加速，主要的优势体现如下：
（1）借助 RDMA 网络单路 IO us 级时延的数据传输特性，加速消息中间件的网络 IO 效率，降低批量消息发送和主从复制过程中的网络时延和开销；
（2）考虑软硬协同一体化设计，借助 RDMA 网络技术提升消息中间件集群可承载的整体吞吐流量峰值；
在 Messsage on RDMA 这个创新计划的前期探索中，我们也是遇到了很多挑战，比如，socket API – RDMA verbs API 中间转换网络路径的替换和改造，大规模 RDMA 组网问题等。后续，我们会考虑将 Message on RDMA 的整体解决方案发布至社区，赋能开源用户，为业界提供参考苹果小火箭用不了了。
解决传统 TCP/IP 网络方案（指内核态 TCP）几个典型问题的另外一项网络技术就是 DPDK 网络 IO 加速技术。DPDK 网络技术并不是一个新技术，它最初是由 Intel 公司开发的一款高性能网络驱动组件，通过大页内存、绑核轮询取代中断、零拷贝、Linux 系统的 UIO 等技术实现了应用程序可以在用户态通过 DPDK 提供的接口实现网络数据包的收发操作。
（1）通过 Linux 系统的 UIO 技术旁路内核，避免了 CPU 在内核中断和用户态 / 内核态之间来回大量数据拷贝所带来的时间开销；
（2）在流量较高的网络数据收发场景中，通过绑 CPU 核轮询的方式，相比内核中断更为高效；
（3）大页内存技术可以避免使用 swap 、减轻 TLB 压力和减轻内存查询的压力；
我们希望借助 DPDK 网络技术为消息中间件实现网络 IO 层面的加速，主要的优势体现如下：
（2）相比传统的内核态 TCP 网络来说，单路 IO 和网络吞吐量均可提升 +20%~30%；
在 Messsage on DPDK 这个创新计划的前期探索中，我们也是遇到了很多挑战，比如，JDK/JVM 对于 DPDK （包括大页内存）的支持，应用对于纯 DPDK 操作如何适配和兼容等。后续，我们也同样会考虑将 Message on DPDK 的整体解决方案发布至社区，为业界提供一些消息中间件在软硬协同设计中的参考。
是时候彻底放弃“高分低能”的 Leetcode了：AI 时代的面试需要大变革！
B 站广州研发工作室解散；外媒曝光苹果中国区丑闻；OpenAI 被曝已叫停新大模型项目 Q资讯返回搜狐，查看更多
