蚂蚁金服 mPaaS 服务端核心组件：亿级并发下的移动端到端网络接入架构解析

根据 《mPaaS 服务端核心组件体系概述：移动 API 网关 MGS》 ，我们已经初步了解 mPaaS 服务端众多组件中移动 API 网关 MGS 的具体架构设计和简介。

本文结合贾岛在 TGO 鲲鹏会举办的「走进蚂蚁金服：双十一背后的蚂蚁金服技术支持」活动现场分享内容《亿级并发下的蚂蚁移动端到端网络接入架构》，着重探讨网络接入架构在蚂蚁金服体系内如何演进、如何应对“新春红包”等亿级并发挑战、以及相应的技术架构实践与优化思路如何在 mPaaS 中得到沉淀。

1. 前言

支付宝移动端架构已完成了 工具 型 App、平台型 App，以及超级 App 三个阶段的迭代与逐步完善。

本次分享将聚焦支付宝在移动网络接入架构的具体演进，以及应对新春红包等项目在亿级并发场景下的具体应对之道。此外，我们将延展探讨蚂蚁金服移动网络技术如何对外商业化应用和输出。

2. 蚂蚁金服移动网络接入架构演进

支付宝无线团队于 2008 年成立，那时支付宝 app 整体架构可以简单称之为单应用架构。单应用包括两部分，客户端 APP 和服务器，通过 https 进行通信。

由于无线业务的逐步发展，许多业务需要从 PC 迁到无线，越来越多的开发要投入到无线上，但是目前的架构无法支撑多业务多团队的并行研发。每个业务功能要拉一个分支，N 个业务同时要拉 N 个分支，合并代码也是很痛苦的，整个架构成为很大的瓶颈。

2013 年我们针对 App 架构进行升级，引入了 API 网关架构：把后端服务抽象为一个个接口对外提供服务，可以拆成各种各样的服务，每一个系统的研发与发布跟其他的系统没有关系，并且支持多端应用接入，比如口碑 App、支付宝主 App。

最重要的是我们引入了移动 RPC 研发模式，有一个中间态的 DSL 的 RPC 定义，可以生成多端代码，中间的通信细节全部由 RPC 框架负责，客户端只需关心业务。

API 网关架构提供了完善的 API 服务生命周期，可以定义为从 API 研发到发布上线、配置、服务上线、服务运营等，直到最后的下线。我们在研发支撑期做了很多工具，比如说代码生成、API 测试工具等。针对服务上线之后的运行，我们有一套完整监控的体系，包括会给每一个 API 打分，比如 API 的响应时间、数据传输大小、响应时间等，比如当错误率超过一个法定值时，会发邮件预警。我们还做了很多客户端和服务器的诊断功能，提供全平台式的应用支持。

此外，我们引入了无线 RPC 的机制。

研发时，服务端同学开通接口，自动拉取服务，接入到网关后台；业务同学可以生成各个客户端的 RPC 代码，发给客户端同学做集成；客户端同学依靠 RPC 代码发到网关，由网关转发到业务服务器。整个过程非常简单，整体研发效率有很大的提升。

2015 年开始，支付宝开始尝试做社交。由此，平台化架构的设计优化迫在眉睫，而新的业务场景对 App 稳定性也提出了更大的挑战和要求，于是移动接入的第三代架构应运而生。

• 首先，我们对网络协议做了优化，把客户端和服务器通信机制变成一个长链接，自定义了长连接协议 MMTP；
• 第二，引入了 SYNC 机制，服务端可以主动推送同步数据到客户端；第三，引入了移动调度，里面有各种个性化调度，比如机房容灾、白名单调度等。

接下来具体看一下网络协议的优化。

我们网络传输协议最底层是 SSL/TLS，蚂蚁是基于 TLS1.3 自研了 MTLS，上一层是会话层，最开始基于 HTTP，现在基于自研的通信协议 MMTP，最上层是 RPC、SYNC、PUSH 应用层协议。

RPC 解决“ 请求 - 响应 ”的通信模式；SYNC 负责“ 服务器直接推送数据到客户端 ”的通信模式；PUSH 负责“ 推传统的 PUSH 弹框通知 ”。

另外我们还重新定义了 HTTP2，引入 H2+ 私有帧协议，支持了自定义双向通信，HTTP2 现在基本上已经定为下一代通信协议，主流的浏览器都已经支持了。同时我们也引进到移动端，因为它具有多路复用、hpack 高可压缩算法等很多对移动网络友好的特性。

接下来我们讲一下 SYNC 机制。

本质上 SYNC 是基于 SyncKey 的一种同步协议。我们直接举个“账单页展示”的例子来解释什么是 SYNC：传统意义上客户端要拉取这个人所有的账单，就发 RPC 请求给服务器，服务器把所有的数据一下子拉回来，很耗费流量。我们的 SYNC 机制是同步差量数据，这样达到了节省流量的效果，数据量小了通信效率也更高效，客户端拿到服务端数据的成功率更高。

另外对于 SYNC 机制，客户端还无需实时在线，对于用户不在线的情况，SYNC Server 会将差量数据保存在数据库中。当客户端下次连接到服务器时，再同步差量数据给用户。在支付宝内部，我们在聊天、配置同步、数据推送等场景都应用了 SYNC 机制。

关于移动调度设计，实际上移动调度底层是一个 HTTPDNS，而不是传统的 LocalDNS。

因为传统 DNS 首先有 DNS 劫持的问题，而且运营商本身的 DNS 质量参差不齐，会影响到请求响应的质量，另外它还不支持 LDC 多中心调度等复杂的自定义调度需求。所以我们自己做了移动的调度 AMDC，支持容灾、策略、通道优化、LDC 白名单的调度。

关于第四代支付宝移动架构演进，我们主要做了两件事情：第一，统一网络库；第二，网关去中心化。

一方面，客户端平台需要覆盖 iOS、Android，此外还有 IOT RTOS 等平台，未来还需要支持更多端。然而每支持一个平台，我们都需要重新开发一套网络库；另一方面，我们的客户端网络库有比较丰富且复杂的策略，我们经常会发现，每个平台上的策略实现也会有不同，这些不同会导致很多意想不到的问题。

基于上述两点，我们考虑做用 C 语言做统一网络库，可以运行在不同的平台上，所有的客户端网络策略和调度全部统一。这样极大程度地降低了研发成本，每个需求只需要一个研发同学投入，不同平台升级统一网络库即可。

服务端部分我们做了网关去中心化的架构升级，中心化的网关有两个问题：第一，容量规划的问题，现在整个支付宝网关平台有近万个接口，每次搞活动前都需要评估接口的请求量，但是它们的峰值请求量很难评估，每次都是拍一个大概的容量；另外，网关服务器成本越来越高，每次活动业务量很大，每次都要大量扩容；第二，稳定性问题，API 网关更贴近业务，发布变更还是比较频繁的，有时候因为某个业务而做的变更存在问题，会导致整个网关集群挂掉，影响到所有的业务，无法做到业务级别的隔离。所以我们做了网关去中心化，干掉了「形式」上的网关，把网关上的 API 路由能力前置到最上层的接入网关上，把网关核心功能（比如说验签、会话、限流等）抽成一个 Jar，集成到业务系统上。

这样有两个好处：

• 一是 性能提升 ：网关调用业务的远程调用变成了本地 JVM 调用；
• 二是 稳定性提升 ：每个业务集成一个稳定版本的网关 Jar，某一个业务系统做网关 Jar 升级时，其他业务系统都不受干扰。

但网关去中心化的缺点也是比较明显，比如版本分裂问题，每次系统集成的网关 Jar 的版本都不一样，比如发现网关 Jar 有一个安全漏洞需要升级解决，推动各个业务系统升级 Jar 是一个比较痛苦的过程，业务系统需要经历集成新版 Jar，测试回归，线上发布等复杂的过程。

另外还存在依赖 Jar 冲突、异构系统不容易集成的问题。ServiceMesh 的出现给我们带来新的思路，我们将网关逻辑做到 ServiceMesh 中的网络代理中，作为 Sidecar 以独立进程的形式部署到业务系统中，完美支持无损平滑升级，同时也支持异构系统，解决了支付宝内部 Nodejs 和 C 语言系统的去中心化的集成问题。

3. 如何应对新春红包以及并发挑战

从 2015 年春节开始，支付宝都会做新春红包活动。2016 年，支付宝和春晚合作，咻一咻的红包，峰值达到了 177 亿 / 分钟，每秒钟将近 3 亿的请求 —— 这样的并发挑战，我们是如何应对的呢？

| 应对之道

支付宝做大型活动的过程是：首先产品经理在几个月之前确定业务的玩法，技术同学拿到业务玩法后开始做技术的评估，评估出活动峰值的在线用户数、核心业务请求量等核心指标出来之后会评估技术方案。

技术方案依赖于我们要分析核心链路，然后对所有的系统做容量评估，容量评估以后做限流的方案，最后看能否对整个链路中某些系统或者节点做优化。

最后的重点是，能否对非核心的业务、非核心的功能做依赖度降级。技术方案出来以后会做压测，压测达标之后是活动演练，演练中会发现一些问题，及时修复掉。后续便是准备实战应对，如果其中有问题会做应急的处理。活动结束之后，我们会将之前做的降级策略，机房弹出等操作进行回滚操作。

我们网络接入层是如何保障大促活动的呢？下面主要针对接入层限流和性能优化做一下分享。

| 接入层限流

我们面临的请求量是上亿级的，后端业务是肯定撑不住，入口层必须要通过限流的手段保护后端系统。

核心思想是要做一个有损服务，保障核心业务在体验可接受范围内做降级非核心功能和业务。首先我们调低压缩阈值，降低对性能层的消耗；另外我们会把非核心不重要的接口全部降级，因为这些接口被限流也不会对客户端体验造成影响。

我们做了多层级限流机制，分为 LVS 限流，接入层限流、API 网关限流、业务层限流：

LVS 方面：单 VIP 一个 LVS 集群一般是 4 台机器，一个集群 LVS 肯定扛不住，所以我们给每个 IDC 分配了多个 VIP，多套 LVS 集群共同承担流量，并且提高抗 DDOS 攻击的能力。

接入层方面：提供了 TCP 限流、核心 RPC 的限流能力。另外我们在 API 网关层做了分级限流算法，对不同请求量的接口做了策略，高 QPS 限流用简单基数算法，超过这个值就直接拒绝掉；对中等 QPS 做了令牌桶算法，接受一定的流量突发；对低 QPS 进行分布式限流，保障限流的准确。

| TLS 性能优化

网关接入层面对如此海量的请求，必须做好性能的极致优化，我们做了很多性能优化，降低对性能的消耗。

首先分享下 TLS 的优化，有没有 TLS 对性能来讲是量级的差别（http 和 https 的差别）。了解加密算法的同学知道，在 TLS 中性能开销最大的是 TLS 握手阶段的 RSA 加解密。为了优化 RSA 加解密对服务器的性能消耗，几年前我们的优化策略是硬件加速，将 RSA 加解密的操作交给一个单独的硬件加速卡处理。随着 TLS 的不断发展，TLS 中的 RSA 基本被废弃，用最新的 ECDSA 取代 RSA，ECDSA 最底层的算法和成本对性能的消耗远低于 RSA，相差 5-6 倍。另外我们使用 Session Ticket 机制将 TLS 握手从 2RTT 降低为 1RTT，同时极大提升了性能。

| 压缩算法优化

最常用的压缩算法是 gzip，压缩的两个关键指标是：压缩比和压缩 / 解压速度。我们尝试过开源很多算法，像 gzip、lz4、brotli、zstd，最后发现 Facebook 的压缩算法 zstd 的这两个指标都占优。但是 zstd 对于字典的要求比较高，我们通过清洗线上海量数据，得到合适我们的字典，极大提高了压缩率和压缩性能。

4. 蚂蚁金服移动网络技术商业化应用与输出

| 一站式移动开发平台 mPaaS

蚂蚁移动网络技术的商业化是依托于蚂蚁金服移动开发平台 mPaaS。

mPaaS 是源于支付宝 App 近 10 年的移动技术思考和实践，为移动开发、测试、运营及运维提供云到端的一站式平台解决方案，能有效降低技术门槛、减少研发成本、提升开发效率，协助生态伙伴快速搭建稳定高质量的移动 App。移动网络服务在 mPaaS 中提供了 MGS 网关服务、MSS 数据同步服务、MPS 推送服务、MDC 调度服务等丰富的网络解决方案。

| 全面整合蚂蚁金服技术能力

服务端侧的 MGS（网关服务）、MPS（推送服务）、MSS（同步服务）是我们的核心服务，它们基本上覆盖了请求响应、推送、增量更新三种模式，可以满足大部分的业务应用场景。网关服务的开放版开放版支持 HTTP、Dubbo、ZDAS、SOFA-RPC 等多种协议，还支持插件式功能，通过插件的方式强化网关功能。MSS 服务机制是增量更新的模式，而且可以做顺序推送，比如做聊天，聊天消息必须是一条条到达，不能乱序，而且还可以做到秒级触达。MPS 服务在国内我们会自建 PUSH 通道，另外在自建通道不可用时会尝试走小米、华为等厂商 PUSH 通道推送，保证高可用、高推送率。

5. 结语

通过本节内容，相信大家对蚂蚁如何构建应对亿级并发的网络接入架构以及 mPaaS 移动 API 网关服务 MGS 有了初步认识。

关于网关功能详细介绍，可以参考 mPaaS 移动网关官方文档：t.cn/EUL8D6o

后续我们将针对 mPaaS 其他服务组件的设计与优化，展开更多探讨。