蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇

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

引言

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

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

• 对消息 Mesh 进行介绍，解答消息 Mesh 在整个 Service Mesh 中的地位是什么，它又能为业务带来哪些价值；
• 结合蚂蚁金服消息中间件团队 Mesh 化的实践与思考，阐述如何在消息领域进行 Mesh 化改造；
• 消息 Mesh 在蚂蚁金服内部大规模落地过程当中遇到的问题与挑战，以及对应的解决方案；
• 消息流量精细化调度上的思考与在 Mesh 上的实现与落地；

消息 Mesh 简介

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

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

消息 Mesh 的价值

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

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

• 快速升级 - 经过将与业务逻辑无关的一些核心关键能力下沉到 Sidecar 中，使这些能力的单独快速迭代与升级成为可能；
• 流量控制 - 能够向 Sidecar 中集成各类流量控制策略，例如可根据消息类型、消息数量、消息大小等多种参数来控制消息的发送和消费速率；
• 流量调度 - 经过打通 Sidecar 节点之间的通讯链路，能够利用 Sidecar 的流量转发来实现任意精度的消息流量调度，帮助基于事件驱动的微服务应用进行多版本流量管理、流量着色、分组路由、细粒度的流量灰度与A/B策略等；
• 消息验证 - 消息验证在基于事件驱动的微服务架构中正变得愈来愈重要，经过将这部分能力下沉到 Sidecar，不只可让业务系统无缝集成消息验证能力，也可让 Sidecar 经过 Schema 理解消息内容，并进一步具有恶意内容识别等安全管控能力；
• 可观测性 - 因为全部的消息流量都必须经过 Sidecar，所以能够为 Sidecar 上的消息流量按需增长 Trace 日志，Metrics 采集，消息轨迹数据采集等能力，并借此进一步丰富消息服务的治理能力；

消息 Mesh 化改造

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

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

总体架构

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

• 客户端再也不与服务端直连，而是经过 Sidecar 进行请求的中转，对客户端而言，Sidecar 其实是它惟一能感知到的消息服务端，对服务端而言，Sidecar 则扮演着客户端的角色；
• 全部 Sidecar 都会与控制平面交互，接收服务端地址列表、流量管控和调度配置、运行时动态配置等的下发，从而使数据平面具有限流、熔断、异常重试、服务发现、负载均衡、精细化流量调度等能力；

核心交互流程

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

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

• 在通过 Mesh 化改造后，消息客户端再也不直接向 SOFARegistry 订阅消息服务端的地址，而是将全部消息元数据（包含业务应用声明的消息 Topic、发送/订阅组 GroupId 等关键信息）经过 HTTP 请求上报给 MOSN，由 MOSN 进行元数据的持久化（用于 MOSN 异常 Crash 后的恢复）以及消息服务端地址的订阅和处理；
• 当客户端收到 MOSN 对于注册请求的响应时，会主动与 MOSN 创建链接，并将与该链接相关的 Group 集合信息经过控制指令发送给 MOSN，因为客户端与 MOSN 可能存在多个链接，且不一样链接上的 Group 集合能够不一样，而 MOSN 与同一个消息服务端只维持一个链接，所以控制指令没法向消息数据同样直接进行转发，而是须要汇总计算全部 GroupId 集合后再统一广播给消息服务端集群。因为上述计算逻辑十分复杂，须要包含过滤和聚合，且存在动态和并发行为，一旦因计算错误则会严重影响到消息投递的正确性，所以当前 MOSN 绕过了该指令的代理，只利用客户端的控制指令进行相关数据的校验，以及更新客户端链接的映射信息（用于 MOSN 的客户端链接选择），而是选择依赖消息客户端的改造引入上述 HTTP 注册请求来构造全量控制指令；

MOSN：https://github.com/sofastack/sofa-mosn

消息 Mesh 的挑战

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

资源管理

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

平滑升级

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

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

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

• 在链接迁移的过程当中，若是消息客户端已处理完通过 MOSN 转发的服务端投递消息请求，可是还未回复响应，此时若把链接迁移到新的 MOSN，则新的 MOSN 将收到上述响应，但因为新 MOSN 缺失上下文，没法将该响应返回给正确的消息服务端
• 在链接迁移完成，但老 MOSN 还未优雅退出期间，因为两个 MOSN 与消息服务端都存在链接，二者都会收到服务端发送的投递消息请求，但因两个 MOSN 与服务端链接的状态各自独立，可能会使客户端收到的请求ID冲突

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

• 老 MOSN 平滑升级指令后，会当即向全部的消息服务端发送禁止再接收消息的控制指令；
• 新 MOSN 感知老 MOSN 完成前置操做，开始进行原有的平滑升级流程，进行初始化和存量链接迁移；
• 新 MOSN 完成存量链接迁移后，向全部的消息服务端发送接收消息的控制指令，开始正常的消息订阅；

消息 Mesh 流量调度

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

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

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

最后，与 RPC 的点对点通讯方式不一样，不管是消息发送端仍是订阅端都只与消息服务端通讯，这意味着即便进行了消息 Mesh 化改造后，MOSN 也只与消息服务端通讯，同一个应用的 MOSN 节点之间是不存在消息链接的，为了实现 MOSN 之间的消息流量转发，则须要内置实现一个与业务应用进程同生命周期的消息转发服务，由同应用内的全部其余 MOSN 节点订阅并在须要转发时调用。

总结

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

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

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

往期系列阅读

• 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇
• Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题

公众号：金融级分布式架构（Antfin_SOFA）