前言

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

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

一. 螞蟻金服移動網絡接入架構演進

支付寶移動網絡第一代架構

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

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

支付寶移動網絡第二代架構

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

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

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

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

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

支付寶移動網絡第三代架構

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

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

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

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

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

另外我們還重新定義了 HTTP2，引入 H2+ 私有幀協(xié)議，支持了自定義雙向通信，HTTP2 現(xiàn)在基本上已經定為下一代通信協(xié)議，主流的瀏覽器都已經支持了。同時我們也引進到移動端，因為它具有多路復用、hpack 高可壓縮算法等很多對移動網絡友好的特性。

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

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

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

關于移動調度設計，實際上移動調度底層是一個 HTTPDNS，而不是傳統(tǒng)的 LocalDNS。

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

支付寶移動網絡第四代架構

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

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

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

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

這樣有兩個好處：

一是性能提升，網關調用業(yè)務的遠程調用變成了本地 JVM 調用；

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

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

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

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

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

應對之道

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

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

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

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

接入層限流

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

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

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

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

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

TLS 性能優(yōu)化

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

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

壓縮算法優(yōu)化

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

三. 螞蟻金服移動網絡技術商業(yè)化應用與輸出

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

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

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

全面整合螞蟻金服技術能力

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