螞蟻金服億級併發下的移動端到端網絡接入架構解析

前言

支付寶移動端架構已完成了工具型 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，上文主要是針對螞蟻金服平臺如何構建億級併發下的移動端到端網絡接入架構實踐的分享。