前言

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

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

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

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

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

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

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

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

最重要的是我們引入了移動 RPC 研發(fā)模式，有一個中間態(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ù)運營等，直到最后的下線。我們在研發(fā)支撐期做了很多工具，比如說代碼生成、API 測試工具等。針對服務(wù)上線之后的運行，我們有一套完整監(jiān)控的體系，包括會給每一個 API 打分，比如 API 的響應(yīng)時間、數(shù)據(jù)傳輸大小、響應(yīng)時間等，比如當(dāng)錯誤率超過一個法定值時，會發(fā)郵件預(yù)警。我們還做了很多客戶端和服務(wù)器的診斷功能，提供全平臺式的應(yīng)用支持。

此外，我們引入了無線 RPC 的機制。

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

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

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

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

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

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

RPC 解決“請求 - 響應(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)支持了。同時我們也引進到移動端，因為它具有多路復(fù)用、hpack 高可壓縮算法等很多對移動網(wǎng)絡(luò)友好的特性。

接下來我們講一下 SYNC 機制。

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

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

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

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

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

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

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

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

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

這樣有兩個好處：

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

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

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

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

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

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

應(yīng)對之道

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

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

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

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

接入層限流

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

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

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

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

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

TLS 性能優(yōu)化

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

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

壓縮算法優(yōu)化

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

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

一站式移動開發(fā)平臺 mPaaS

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

mPaaS 是源于支付寶 App 近 10 年的移動技術(shù)思考和實踐，為移動開發(fā)、測試、運營及運維提供云到端的一站式平臺解決方案，能有效降低技術(shù)門檻、減少研發(fā)成本、提升開發(fā)效率，協(xié)助生態(tài)伙伴快速搭建穩(wěn)定高質(zhì)量的移動 App。移動網(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ù)，它們基本上覆蓋了請求響應(yīng)、推送、增量更新三種模式，可以滿足大部分的業(yè)務(wù)應(yīng)用場景。網(wǎng)關(guān)服務(wù)的開放版開放版支持 HTTP、Dubbo、ZDAS、SOFA-RPC 等多種協(xié)議，還支持插件式功能，通過插件的方式強化網(wǎng)關(guān)功能。MSS 服務(wù)機制是增量更新的模式，而且可以做順序推送，比如做聊天，聊天消息必須是一條條到達，不能亂序，而且還可以做到秒級觸達。MPS 服務(wù)在國內(nèi)我們會自建 PUSH 通道，另外在自建通道不可用時會嘗試走小米、華為等廠商 PUSH 通道推送，保證高可用、高推送率。