蚂蚁金服亿级并发下的移动端到端网络接入架构

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

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

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

 

支付宝移动网络第一代架构

支付宝无线团队于 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 冲突、异构系统不容易集成的问题。Service Mesh 的出现给我们带来新的思路，我们将网关逻辑做到 ServiceMesh 中的网络代理中，作为 Sidecar 以独立进程的形式部署到业务系统中，完美支持无损平滑升级，同时也支持异构系统，解决了支付宝内部 Nodejs 和 C 语言系统的去中心化的集成问题。

二. 如何应对新春红包亿级并发挑战

从 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 对于字典的要求比较高，我们通过清洗线上海量数据，得到合适我们的字典，极大提高了压缩率和压缩性能。

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

一站式移动开发平台 mPaaS

 

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

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

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

 

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