星期

2020年03月23日

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

2020-03-23 09:19:41 来源:互联网 阅读:-

前言

支付宝移动端架构已完成了工具型 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 通道推送,保证高可用、高推送率。


推荐阅读:骁龙710与麒麟710