本文为《蚂蚁金服 Mesh 大规模落地系列》第二篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。

引言

Mesh 作为蚂蚁金服向下一代云原生架构演进的核心基础设施，在2019年得到了大规模的应用与落地，截止目前，蚂蚁金服的 Mesh 数据平面 MOSN 已接入应用数百个，接入容器数量达数十万，一举成为全世界最大的 Mesh 集群。同时，在刚刚结束的双十一大促中， Mesh 的表现也十分亮眼，RPC 峰值 QPS 达到了几千万，消息峰值 TPS 达到了几百万，且引入 Mesh 后的平均 RT 增长幅度控制在 0.2 ms 以内。

本文作为整个 Mesh 系列文章的消息篇，作者：刘翔（花名：无勤），蚂蚁金服消息 Mesh 负责人， 消息中间件核心研发成员，专注于高吞吐、低延迟的消息中间件研发，以及云原生时代下一代消息系统的架构设计与研发。本文将从以下几个方面对消息 Mesh 进行解读：

消息 Mesh 简介

Mesh 作为云原生场景下微服务架构的基础设施（轻量级的网络代理），正受到越来越多的关注。 Mesh 不仅负责在微服务架构的复杂拓扑中可靠地传递请求，也将限流、熔断、监控、链路追踪、服务发现、负载均衡、异常处理等与业务逻辑无关的流量控制或服务治理行为下沉，让应用程序能更好地关注自身业务逻辑。

微服务架构中的通信模式实际上是多种多样的，既包含同步的请求调用，也包含异步的消息/事件驱动，然而流行的 Mesh 实现（Istio，， 等），都仍局限在对微服务中同步请求调用的关注，却无法管理和追踪异步消息流量。而消息 Mesh 则是对这一块的重要补充，通过将消息 Mesh 有机地融合到 Mesh 中，可以帮助 Mesh 实现对所有微服务流量的管控和追踪，从而进一步完善其架构目标。

消息 Mesh 的价值

在传统的消息中间件领域，我们更关注的是消息服务端的性能、服务可用性、数据可靠性等核心指标，而与业务应用密切相关的一些能力，包括消息的流量控制（限流、熔断、灰度、着色、分组等），消息的服务治理（消息量级与消息应用拓扑等），消息链路的追踪（消息轨迹）却往往不尽如人意。

这不仅是因为传统模式下上述能力的提供和优化都涉及客户端的改造与大规模升级，整个过程常常比较漫长，难以快速根据有效反馈不断优化，更重要的是缺乏一个统一的架构指导思想，混乱无序地向客户端叠加相关功能只会让消息客户端变得越来越臃肿和难以维护，也变向增加了业务系统的接入、调试和排查问题的成本。而消息Mesh 作为 Mesh 的补充，能显著带来如下价值和收益：

消息 Mesh 化改造

在蚂蚁金服内部， 基于推模型提供高可靠、高实时、事务消息、 订阅等特性，帮助核心链路进行异步解耦，提升业务的可扩展能力，并先后伴随蚂蚁金服众多核心系统一起经历了分布式改造、单元化改造与弹性改造，目前主要承载蚂蚁内部交易、账务、会员、消费记录等核心在线业务的异步消息流量。

由于 Mesh 的推进目标也是优先覆盖交易支付等核心链路，为在线业务赋能，因此我们优先选择对 系统进行 Mesh 化改造。下面将以 为例，重点剖析 Mesh 化后在整体架构和核心交互流程上的变化，为消息领域的 Mesh 化改造提供参考。

整体架构

消息 Mesh 化后的整体架构如上图所示，与原有的消息架构相比，主要的变化有：

核心交互流程

当 代理了消息客户端的所有请求后，一旦 完成消息服务的发现与服务端/客户端路由数据的缓存，无论是客户端的发消息请求还是服务端的推消息请求，都能由 进行正确的代理转发，而这一切的关键，则是 与消息客户端协同完成一系列的初始化操作。

消息 Mesh 化后具体的初始化流程如下所示，与原有的初始化流程相对比，主要有如下不同：

MOSN：

消息 Mesh 的挑战

消息中间件最关键的挑战，在于如何在洪峰流量下依然保障消息服务的高可靠与高实时。而在消息 Mesh 化的大规模实施过程中，还需要考虑数十万的容器节点对数据面整体稳定性和控制面性能带来的巨大挑战，这些都依赖于完善的 运维体系，包括 的资源分配策略，以及 独立变更升级的策略。

资源管理

当 Mesh 的实体 MOSN作为 与业务容器部署在一起时，就不再像消息服务端一样只需要关心自身的资源消耗，而是必须精细化其 CPU、内存等资源的分配，才能达到与应用最优的协同合作方式。在 的精细化资源管理上，先后经历了独立分配、通过超卖与业务容器共享、细粒度的 CPU 资源分配策略和内存 OOM 策略调整等多个阶段，最终基于 Mesh 将原有的与业务无关的逻辑下沉到 ，其占用的资源实际是原来业务容器会使用的资源这一假设，在零新增成本的情况下平稳支撑了数十万规模级别的 容器分配。关于资源管理更详细的内容可以期待后续 Mesh 系列文章中的运维篇，本文就不再赘述。

平滑升级

为了达到 这一类基础设施的变更升级对业务完全无感知的目的，就需要使 MOSN 具备平滑升级的能力。在平滑升级过程中，新的MOSN首先会被注入，并通过共享卷的 去检查是否存在老的 MOSN，若存在，则利用内核 的迁移实现老 MOSN 的连接全部迁移给新 MOSN，如下图所示，最终再让老 MOSN 优雅退出，从而实现 MOSN 在整个升级和发布过程中对业务无任何打扰，关于 MOSN 本身平滑升级更多的内容，可以参考 Mesh 系列文章中的核心篇。

上述平滑升级方案，其实隐含了一个非常重要的前提，单条连接上的请求必须是单向的。从下图可知，对于 RPC 场景，其单条连接的角色是固定的，只能是服务端连接或客户端连接，且对一次请求的代理过程也是固定的，总是从服务端连接上收到一个请求，再从客户端连接将请求转发出去，因此 RPC 可以直接使用上述平滑升级方案。

然而，在消息场景特别是 场景下，如下图所示，MOSN 上的连接请求实际上是双向的，不仅客户端会使用该连接进行消息的发送，服务端也会利用该连接将消息主动推送给 MOSN，这就会给上述连接迁移带来新的问题和挑战：

解决上述问题的思路其实很简单，即为在平滑升级的过程中，禁止服务端向老 MOSN 发送投递消息请求，保证即使在消息场景整个平滑升级过程中的所有连接仍然是单工通信的。具体对平滑升级流程的改动如下：

消息 Mesh 流量调度

消息 Mesh 的流量调度如下图所示。

首先，控制平面会将与流量调度相关的规则下发至 MOSN，规则主要包含该应用下所有容器节点的 IP 地址与流量权重，这是能够进行精细化流量调度的前提。

其次，当 MOSN 收到消息投递请求时，会判断请求的来源，若请求来源于其他 MOSN 节点，则会直接将该请求转发给客户端，避免消息投递请求的循环转发，而若请求来源于消息服务端，则 MOSN 会根据自身的流量权重来决定下一步的路由，若自身的流量权重是100%，会同样将该请求转发给客户端，但若自身权重小于100%，则会按照配置的权重将剩余请求均匀转发给其他流量权重为100%的 MOSN 节点。

最后，与 RPC 的点对点通信方式不同，无论是消息发送端还是订阅端都只与消息服务端通信，这意味着即使进行了消息 Mesh 化改造后，MOSN 也只与消息服务端通信，同一个应用的 MOSN 节点之间是不存在消息连接的，为了实现 MOSN 之间的消息流量转发，则需要内置实现一个与业务应用进程同生命周期的消息转发服务，由同应用内的所有其他 MOSN 节点订阅并在需要转发时调用。

总结

消息 Mesh 经过蚂蚁消息中间件团队大半年的打磨和沉淀，已经迈出了坚实的一大步：在开源社区迟迟未在消息 Mesh 上取得实质性进展时，我们已经为蚂蚁内部主流消息中间件打通了数据平面。

同时也有充满想象力的一小步：依赖消息的精细化流量调度，预期可以发挥更大的业务价值，包括基于事件驱动的 化应用多版本流量管理、流量着色、分组路由、细粒度的流量灰度与A/B策略等，等待着去开发与挖掘，

这些都在双十一大促中取得了不俗的成绩。未来，我们将会持续加大对消息 Mesh的投入，为消息 Mesh 支持更多的消息协议，赋予更多开箱即用的的消息流量管控和治理能力，并进一步结合 探索消息精细化流量调度在 下的应用场景。最后，也欢迎志同道合的伙伴，一起参与金融级分布式消息系统、云原生时代的下一代消息系统的架构设计和研发。

往期系列阅读