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

前言

支付宝移动端架构已完成了工具型 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 应用层协议。在此我向你们推荐一个架构学习交流群。交流学习圈：948368769里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多

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 进行分布式限流，保障限流的准确。在此我向你们推荐一个架构学习交流群。交流学习圈：948368769里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多

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、lz四、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 通道推送，保证高可用、高推送率。

原文连接：http://www.uml.org.cn/zjjs/201901042.asp，上文主要是针对蚂蚁金服平台如何构建亿级并发下的移动端到端网络接入架构实践的分享。