前言

支付寶移動(dòng)端架構(gòu)已完成了工具型 App、平臺(tái)型 App，以及超級(jí) App 三個(gè)階段的迭代與逐步完善。

本次分享將聚焦支付寶在移動(dòng)網(wǎng)絡(luò)接入架構(gòu)的具體演進(jìn)，以及應(yīng)對(duì)新春紅包等項(xiàng)目在億級(jí)并發(fā)場(chǎng)景下的具體應(yīng)對(duì)之道。此外，我們將延展探討螞蟻金服移動(dòng)網(wǎng)絡(luò)技術(shù)如何對(duì)外商業(yè)化應(yīng)用和輸出。

一. 螞蟻金服移動(dòng)網(wǎng)絡(luò)接入架構(gòu)演進(jìn)

支付寶移動(dòng)網(wǎng)絡(luò)第一代架構(gòu)

支付寶無(wú)線團(tuán)隊(duì)于 2008 年成立，那時(shí)支付寶 app 整體架構(gòu)可以簡(jiǎn)單稱(chēng)之為單應(yīng)用架構(gòu)。單應(yīng)用包括兩部分，客戶端 APP 和服務(wù)器，通過(guò) https 進(jìn)行通信。

由于無(wú)線業(yè)務(wù)的逐步發(fā)展，許多業(yè)務(wù)需要從 PC 遷到無(wú)線，越來(lái)越多的開(kāi)發(fā)要投入到無(wú)線上，但是目前的架構(gòu)無(wú)法支撐多業(yè)務(wù)多團(tuán)隊(duì)的并行研發(fā)。每個(gè)業(yè)務(wù)功能要拉一個(gè)分支，N 個(gè)業(yè)務(wù)同時(shí)要拉 N 個(gè)分支，合并代碼也是很痛苦的，整個(gè)架構(gòu)成為很大的瓶頸。

支付寶移動(dòng)網(wǎng)絡(luò)第二代架構(gòu)

2013 年我們針對(duì) App 架構(gòu)進(jìn)行升級(jí)，引入了 API 網(wǎng)關(guān)架構(gòu)：把后端服務(wù)抽象為一個(gè)個(gè)接口對(duì)外提供服務(wù)，可以拆成各種各樣的服務(wù)，每一個(gè)系統(tǒng)的研發(fā)與發(fā)布跟其他的系統(tǒng)沒(méi)有關(guān)系，并且支持多端應(yīng)用接入，比如口碑 APP、支付寶主 APP。

最重要的是我們引入了移動(dòng) RPC 研發(fā)模式，有一個(gè)中間態(tài)的 DSL 的 RPC 定義，可以生成多端代碼，中間的通信細(xì)節(jié)全部由 RPC 框架負(fù)責(zé)，客戶端只需關(guān)心業(yè)務(wù)。

API 網(wǎng)關(guān)架構(gòu)提供了完善的 API 服務(wù)生命周期，可以定義為從 API 研發(fā)到發(fā)布上線、配置、服務(wù)上線、服務(wù)運(yùn)營(yíng)等，直到最后的下線。我們?cè)谘邪l(fā)支撐期做了很多工具，比如說(shuō)代碼生成、API 測(cè)試工具等。針對(duì)服務(wù)上線之后的運(yùn)行，我們有一套完整監(jiān)控的體系，包括會(huì)給每一個(gè) API 打分，比如 API 的響應(yīng)時(shí)間、數(shù)據(jù)傳輸大小、響應(yīng)時(shí)間等，比如當(dāng)錯(cuò)誤率超過(guò)一個(gè)法定值時(shí)，會(huì)發(fā)郵件預(yù)警。我們還做了很多客戶端和服務(wù)器的診斷功能，提供全平臺(tái)式的應(yīng)用支持。

此外，我們引入了無(wú)線 RPC 的機(jī)制。

研發(fā)時(shí)，服務(wù)端同學(xué)開(kāi)通接口，自動(dòng)拉取服務(wù)，接入到網(wǎng)關(guān)后臺(tái)；業(yè)務(wù)同學(xué)可以生成各個(gè)客戶端的 RPC 代碼，發(fā)給客戶端同學(xué)做集成；客戶端同學(xué)依靠 RPC 代碼發(fā)到網(wǎng)關(guān)，由網(wǎng)關(guān)轉(zhuǎn)發(fā)到業(yè)務(wù)服務(wù)器。整個(gè)過(guò)程非常簡(jiǎn)單，整體研發(fā)效率有很大的提升。

支付寶移動(dòng)網(wǎng)絡(luò)第三代架構(gòu)

2015 年開(kāi)始，支付寶開(kāi)始嘗試做社交。由此，平臺(tái)化架構(gòu)的設(shè)計(jì)優(yōu)化迫在眉睫，而新的業(yè)務(wù)場(chǎng)景對(duì) App 穩(wěn)定性也提出了更大的挑戰(zhàn)和要求，于是移動(dòng)接入的第三代架構(gòu)應(yīng)運(yùn)而生。

首先，我們對(duì)網(wǎng)絡(luò)協(xié)議做了優(yōu)化，把客戶端和服務(wù)器通信機(jī)制變成一個(gè)長(zhǎng)鏈接，自定義了長(zhǎng)連接協(xié)議 MMTP；第二，引入了 SYNC 機(jī)制，服務(wù)端可以主動(dòng)推送同步數(shù)據(jù)到客戶端；第三，引入了移動(dòng)調(diào)度，里面有各種個(gè)性化調(diào)度，比如機(jī)房容災(zāi)、白名單調(diào)度等。

接下來(lái)具體看一下網(wǎng)絡(luò)協(xié)議的優(yōu)化。

我們網(wǎng)絡(luò)傳輸協(xié)議最底層是 SSL/TLS，螞蟻是基于 TLS1.3 自研了 MTLS，上一層是會(huì)話層，最開(kāi)始基于 HTTP，現(xiàn)在基于自研的通信協(xié)議 MMTP，最上層是 RPC、SYNC、PUSH 應(yīng)用層協(xié)議。

RPC 解決“請(qǐng)求 - 響應(yīng)”的通信模式；SYNC 負(fù)責(zé)“服務(wù)器直接推送數(shù)據(jù)到客戶端”的通信模式；PUSH 負(fù)責(zé)“推傳統(tǒng)的 PUSH 彈框通知”。

另外我們還重新定義了 HTTP2，引入 H2+ 私有幀協(xié)議，支持了自定義雙向通信，HTTP2 現(xiàn)在基本上已經(jīng)定為下一代通信協(xié)議，主流的瀏覽器都已經(jīng)支持了。同時(shí)我們也引進(jìn)到移動(dòng)端，因?yàn)樗哂卸嗦窂?fù)用、hpack 高可壓縮算法等很多對(duì)移動(dòng)網(wǎng)絡(luò)友好的特性。

接下來(lái)我們講一下 SYNC 機(jī)制。

本質(zhì)上 SYNC 是基于 SyncKey 的一種同步協(xié)議。我們直接舉個(gè)“賬單頁(yè)展示”的例子來(lái)解釋什么是 SYNC：傳統(tǒng)意義上客戶端要拉取這個(gè)人所有的賬單，就發(fā) RPC 請(qǐng)求給服務(wù)器，服務(wù)器把所有的數(shù)據(jù)一下子拉回來(lái)，很耗費(fèi)流量。我們的 SYNC 機(jī)制是同步差量數(shù)據(jù)，這樣達(dá)到了節(jié)省流量的效果，數(shù)據(jù)量小了通信效率也更高效，客戶端拿到服務(wù)端數(shù)據(jù)的成功率更高。

另外對(duì)于 SYNC 機(jī)制，客戶端還無(wú)需實(shí)時(shí)在線，對(duì)于用戶不在線的情況，SYNC Server 會(huì)將差量數(shù)據(jù)保存在數(shù)據(jù)庫(kù)中。當(dāng)客戶端下次連接到服務(wù)器時(shí)，再同步差量數(shù)據(jù)給用戶。在支付寶內(nèi)部，我們?cè)诹奶?、配置同步、?shù)據(jù)推送等場(chǎng)景都應(yīng)用了 SYNC 機(jī)制。

關(guān)于移動(dòng)調(diào)度設(shè)計(jì)，實(shí)際上移動(dòng)調(diào)度底層是一個(gè) HTTPDNS，而不是傳統(tǒng)的 LocalDNS。

因?yàn)閭鹘y(tǒng) DNS 首先有 DNS 劫持的問(wèn)題，而且運(yùn)營(yíng)商本身的 DNS 質(zhì)量參差不齊，會(huì)影響到請(qǐng)求響應(yīng)的質(zhì)量，另外它還不支持 LDC 多中心調(diào)度等復(fù)雜的自定義調(diào)度需求。所以我們自己做了移動(dòng)的調(diào)度 AMDC，支持容災(zāi)、策略、通道優(yōu)化、LDC 白名單的調(diào)度。

支付寶移動(dòng)網(wǎng)絡(luò)第四代架構(gòu)

關(guān)于第四代支付寶移動(dòng)架構(gòu)演進(jìn)，我們主要做了兩件事情：第一，統(tǒng)一網(wǎng)絡(luò)庫(kù)；第二，網(wǎng)關(guān)去中心化。

一方面，客戶端平臺(tái)需要覆蓋 iOS、Android，此外還有 IOT RTOS 等平臺(tái)，未來(lái)還需要支持更多端。然而每支持一個(gè)平臺(tái)，我們都需要重新開(kāi)發(fā)一套網(wǎng)絡(luò)庫(kù)；另一方面，我們的客戶端網(wǎng)絡(luò)庫(kù)有比較豐富且復(fù)雜的策略，我們經(jīng)常會(huì)發(fā)現(xiàn)，每個(gè)平臺(tái)上的策略實(shí)現(xiàn)也會(huì)有不同，這些不同會(huì)導(dǎo)致很多意想不到的問(wèn)題。

基于上述兩點(diǎn)，我們考慮做用 C 語(yǔ)言做統(tǒng)一網(wǎng)絡(luò)庫(kù)，可以運(yùn)行在不同的平臺(tái)上，所有的客戶端網(wǎng)絡(luò)策略和調(diào)度全部統(tǒng)一。這樣極大程度地降低了研發(fā)成本，每個(gè)需求只需要一個(gè)研發(fā)同學(xué)投入，不同平臺(tái)升級(jí)統(tǒng)一網(wǎng)絡(luò)庫(kù)即可。

服務(wù)端部分我們做了網(wǎng)關(guān)去中心化的架構(gòu)升級(jí)，中心化的網(wǎng)關(guān)有兩個(gè)問(wèn)題：第一，容量規(guī)劃的問(wèn)題，現(xiàn)在整個(gè)支付寶網(wǎng)關(guān)平臺(tái)有近萬(wàn)個(gè)接口，每次搞活動(dòng)前都需要評(píng)估接口的請(qǐng)求量，但是它們的峰值請(qǐng)求量很難評(píng)估，每次都是拍一個(gè)大概的容量；另外，網(wǎng)關(guān)服務(wù)器成本越來(lái)越高，每次活動(dòng)業(yè)務(wù)量很大，每次都要大量擴(kuò)容；第二，穩(wěn)定性問(wèn)題，API 網(wǎng)關(guān)更貼近業(yè)務(wù)，發(fā)布變更還是比較頻繁的，有時(shí)候因?yàn)槟硞€(gè)業(yè)務(wù)而做的變更存在問(wèn)題，會(huì)導(dǎo)致整個(gè)網(wǎng)關(guān)集群掛掉，影響到所有的業(yè)務(wù)，無(wú)法做到業(yè)務(wù)級(jí)別的隔離。所以我們做了網(wǎng)關(guān)去中心化，干掉了「形式」上的網(wǎng)關(guān)，把網(wǎng)關(guān)上的 API 路由能力前置到最上層的接入網(wǎng)關(guān)上，把網(wǎng)關(guān)核心功能（比如說(shuō)驗(yàn)簽、會(huì)話、限流等）抽成一個(gè) Jar，集成到業(yè)務(wù)系統(tǒng)上。

這樣有兩個(gè)好處：

一是性能提升，網(wǎng)關(guān)調(diào)用業(yè)務(wù)的遠(yuǎn)程調(diào)用變成了本地 JVM 調(diào)用；

二是穩(wěn)定性提升，每個(gè)業(yè)務(wù)集成一個(gè)穩(wěn)定版本的網(wǎng)關(guān) Jar，某一個(gè)業(yè)務(wù)系統(tǒng)做網(wǎng)關(guān) Jar 升級(jí)時(shí)，其他業(yè)務(wù)系統(tǒng)都不受干擾。

但網(wǎng)關(guān)去中心化的缺點(diǎn)也是比較明顯，比如版本分裂問(wèn)題，每次系統(tǒng)集成的網(wǎng)關(guān) Jar 的版本都不一樣，比如發(fā)現(xiàn)網(wǎng)關(guān) Jar 有一個(gè)安全漏洞需要升級(jí)解決，推動(dòng)各個(gè)業(yè)務(wù)系統(tǒng)升級(jí) Jar 是一個(gè)比較痛苦的過(guò)程，業(yè)務(wù)系統(tǒng)需要經(jīng)歷集成新版 Jar，測(cè)試回歸，線上發(fā)布等復(fù)雜的過(guò)程。

另外還存在依賴(lài) Jar 沖突、異構(gòu)系統(tǒng)不容易集成的問(wèn)題。Service Mesh 的出現(xiàn)給我們帶來(lái)新的思路，我們將網(wǎng)關(guān)邏輯做到 ServiceMesh 中的網(wǎng)絡(luò)代理中，作為 Sidecar 以獨(dú)立進(jìn)程的形式部署到業(yè)務(wù)系統(tǒng)中，完美支持無(wú)損平滑升級(jí)，同時(shí)也支持異構(gòu)系統(tǒng)，解決了支付寶內(nèi)部 Nodejs 和 C 語(yǔ)言系統(tǒng)的去中心化的集成問(wèn)題。

二. 如何應(yīng)對(duì)新春紅包億級(jí)并發(fā)挑戰(zhàn)

從 2015 年春節(jié)開(kāi)始，支付寶都會(huì)做新春紅包活動(dòng)。2016 年，支付寶和春晚合作，咻一咻的紅包，峰值達(dá)到了 177 億 / 分鐘，每秒鐘將近 3 億的請(qǐng)求 —— 這樣的并發(fā)挑戰(zhàn)，我們是如何應(yīng)對(duì)的呢？

應(yīng)對(duì)之道

支付寶做大型活動(dòng)的過(guò)程是：首先產(chǎn)品經(jīng)理在幾個(gè)月之前確定業(yè)務(wù)的玩法，技術(shù)同學(xué)拿到業(yè)務(wù)玩法后開(kāi)始做技術(shù)的評(píng)估，評(píng)估出活動(dòng)峰值的在線用戶數(shù)、核心業(yè)務(wù)請(qǐng)求量等核心指標(biāo)出來(lái)之后會(huì)評(píng)估技術(shù)方案。

技術(shù)方案依賴(lài)于我們要分析核心鏈路，然后對(duì)所有的系統(tǒng)做容量評(píng)估，容量評(píng)估以后做限流的方案，最后看能否對(duì)整個(gè)鏈路中某些系統(tǒng)或者節(jié)點(diǎn)做優(yōu)化。

最后的重點(diǎn)是，能否對(duì)非核心的業(yè)務(wù)、非核心的功能做依賴(lài)度降級(jí)。技術(shù)方案出來(lái)以后會(huì)做壓測(cè)，壓測(cè)達(dá)標(biāo)之后是活動(dòng)演練，演練中會(huì)發(fā)現(xiàn)一些問(wèn)題，及時(shí)修復(fù)掉。后續(xù)便是準(zhǔn)備實(shí)戰(zhàn)應(yīng)對(duì)，如果其中有問(wèn)題會(huì)做應(yīng)急的處理。活動(dòng)結(jié)束之后，我們會(huì)將之前做的降級(jí)策略，機(jī)房彈出等操作進(jìn)行回滾操作。

我們網(wǎng)絡(luò)接入層是如何保障大促活動(dòng)的呢？下面主要針對(duì)接入層限流和性能優(yōu)化做一下分享。

接入層限流

我們面臨的請(qǐng)求量是上億級(jí)的，后端業(yè)務(wù)是肯定撐不住，入口層必須要通過(guò)限流的手段保護(hù)后端系統(tǒng)。

核心思想是要做一個(gè)有損服務(wù)，保障核心業(yè)務(wù)在體驗(yàn)可接受范圍內(nèi)做降級(jí)非核心功能和業(yè)務(wù)。首先我們調(diào)低壓縮閾值，降低對(duì)性能層的消耗；另外我們會(huì)把非核心不重要的接口全部降級(jí)，因?yàn)檫@些接口被限流也不會(huì)對(duì)客戶端體驗(yàn)造成影響。

我們做了多層級(jí)限流機(jī)制，分為 LVS 限流，接入層限流、API 網(wǎng)關(guān)限流、業(yè)務(wù)層限流：

LVS 方面：?jiǎn)?VIP 一個(gè) LVS 集群一般是 4 臺(tái)機(jī)器，一個(gè)集群 LVS 肯定扛不住，所以我們給每個(gè) IDC 分配了多個(gè) VIP，多套 LVS 集群共同承擔(dān)流量，并且提高抗 DDOS 攻擊的能力。

接入層方面：提供了 TCP 限流、核心 RPC 的限流能力。另外我們?cè)?API 網(wǎng)關(guān)層做了分級(jí)限流算法，對(duì)不同請(qǐng)求量的接口做了策略，高 QPS 限流用簡(jiǎn)單基數(shù)算法，超過(guò)這個(gè)值就直接拒絕掉；對(duì)中等 QPS 做了令牌桶算法，接受一定的流量突發(fā)；對(duì)低 QPS 進(jìn)行分布式限流，保障限流的準(zhǔn)確。

TLS 性能優(yōu)化

網(wǎng)關(guān)接入層面對(duì)如此海量的請(qǐng)求，必須做好性能的極致優(yōu)化，我們做了很多性能優(yōu)化，降低對(duì)性能的消耗。

首先分享下 TLS 的優(yōu)化，有沒(méi)有 TLS 對(duì)性能來(lái)講是量級(jí)的差別（http 和 https 的差別）。了解加密算法的同學(xué)知道，在 TLS 中性能開(kāi)銷(xiāo)最大的是 TLS 握手階段的 RSA 加解密。為了優(yōu)化 RSA 加解密對(duì)服務(wù)器的性能消耗，幾年前我們的優(yōu)化策略是硬件加速，將 RSA 加解密的操作交給一個(gè)單獨(dú)的硬件加速卡處理。隨著 TLS 的不斷發(fā)展，TLS 中的 RSA 基本被廢棄，用最新的 ECDSA 取代 RSA，ECDSA 最底層的算法和成本對(duì)性能的消耗遠(yuǎn)低于 RSA，相差 5-6 倍。另外我們使用 Session Ticket 機(jī)制將 TLS 握手從 2RTT 降低為 1RTT，同時(shí)極大提升了性能。

壓縮算法優(yōu)化

最常用的壓縮算法是 gzip，壓縮的兩個(gè)關(guān)鍵指標(biāo)是：壓縮比和壓縮 / 解壓速度。我們嘗試過(guò)開(kāi)源很多算法，像 gzip、lz4、brotli、zstd，最后發(fā)現(xiàn) Facebook 的壓縮算法 zstd 的這兩個(gè)指標(biāo)都占優(yōu)。但是 zstd 對(duì)于字典的要求比較高，我們通過(guò)清洗線上海量數(shù)據(jù)，得到合適我們的字典，極大提高了壓縮率和壓縮性能。

三. 螞蟻金服移動(dòng)網(wǎng)絡(luò)技術(shù)商業(yè)化應(yīng)用與輸出

一站式移動(dòng)開(kāi)發(fā)平臺(tái) mPaaS

螞蟻移動(dòng)網(wǎng)絡(luò)技術(shù)的商業(yè)化是依托于螞蟻金服移動(dòng)開(kāi)發(fā)平臺(tái) mPaaS。

mPaaS 是源于支付寶 App 近 10 年的移動(dòng)技術(shù)思考和實(shí)踐，為移動(dòng)開(kāi)發(fā)、測(cè)試、運(yùn)營(yíng)及運(yùn)維提供云到端的一站式平臺(tái)解決方案，能有效降低技術(shù)門(mén)檻、減少研發(fā)成本、提升開(kāi)發(fā)效率，協(xié)助生態(tài)伙伴快速搭建穩(wěn)定高質(zhì)量的移動(dòng) App。移動(dòng)網(wǎng)絡(luò)服務(wù)在 mPaaS 中提供了 MGS 網(wǎng)關(guān)服務(wù)、MSS 數(shù)據(jù)同步服務(wù)、MPS 推送服務(wù)、MDC 調(diào)度服務(wù)等豐富的網(wǎng)絡(luò)解決方案。

全面整合螞蟻金服技術(shù)能力

服務(wù)端側(cè)的 MGS（網(wǎng)關(guān)服務(wù)）、MPS（推送服務(wù)）、MSS（同步服務(wù)）是我們的核心服務(wù)，它們基本上覆蓋了請(qǐng)求響應(yīng)、推送、增量更新三種模式，可以滿足大部分的業(yè)務(wù)應(yīng)用場(chǎng)景。網(wǎng)關(guān)服務(wù)的開(kāi)放版開(kāi)放版支持 HTTP、Dubbo、ZDAS、SOFA-RPC 等多種協(xié)議，還支持插件式功能，通過(guò)插件的方式強(qiáng)化網(wǎng)關(guān)功能。MSS 服務(wù)機(jī)制是增量更新的模式，而且可以做順序推送，比如做聊天，聊天消息必須是一條條到達(dá)，不能亂序，而且還可以做到秒級(jí)觸達(dá)。MPS 服務(wù)在國(guó)內(nèi)我們會(huì)自建 PUSH 通道，另外在自建通道不可用時(shí)會(huì)嘗試走小米、華為等廠商 PUSH 通道推送，保證高可用、高推送率。