為了與金融從業者、科技從業者共同探討金融 + 業務的深層次問題，螞蟻金服聯手 TGO 鯤鵬會上海分會，在 12 月 8 日舉辦了「走進螞蟻金服：雙十一背后的螞蟻金服技術支持」活動。螞蟻金服高級技術專家賈島為大家分享了《億級并發下的螞蟻移動端到端網絡接入架構》主題演講。本文根據當天演講整理，有部分不改變原意的刪減。

講師介紹

螞蟻金服高級技術專家賈島

靳文祥（花名：賈島），2011 年畢業后加入支付寶無線團隊，參與過悅享拍、支付寶無線網關設計、無線接入、移動網絡優化等項目。目前負責螞蟻金服移動網絡接入架構設計與優化。

前言

支付寶移動端架構已完成了工具型 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 通道推送，保證高可用、高推送率。

以上即關于螞蟻金服如何構建億級并發下的移動端到端網絡接入架構實踐的分享。

---

TGO 鯤鵬會是極客邦科技旗下高端技術人聚集和交流組織，目前已在北京、上海、杭州、廣州、深圳、成都、硅谷、臺灣、南京、蘇州、武漢全球十一個城市設立分會。現在全球累計 700 多名會員，60% 為 CTO、技術 VP、技術合伙人。

如果你想和這些優秀的科技領導者們一起前行，目前廈門分會已經成立，歡迎點擊「報名表單，申請加入」。