螞蟻金服 mPaaS 服務端核心元件：億級併發下的移動端到端網路接入架構解析
根據《mPaaS 服務端核心元件體系概述：移動 API 閘道器 MGS》，我們已經初步瞭解 mPaaS 服務端眾多元件中移動 API 閘道器 MGS 的具體架構設計和簡介。
本文結合賈島在 TGO 鯤鵬會舉辦的「走進螞蟻金服：雙十一背後的螞蟻金服技術支援」活動現場分享內容《億級併發下的螞蟻移動端到端網路接入架構》，著重探討網路接入架構在螞蟻金服體系內如何演進、如何應對“新春紅包”等億級併發挑戰、以及相應的技術架構實踐與優化思路如何在 mPaaS 中得到沉澱。
1. 前言
支付寶移動端架構已完成了工具型 App、平臺型 App，以及超級 App 三個階段的迭代與逐步完善。
本次分享將聚焦支付寶在行動網路接入架構的具體演進，以及應對新春紅包等專案在億級併發場景下的具體應對之道。此外，我們將延展探討螞蟻金服移動網路技術如何對外商業化應用和輸出。
2. 螞蟻金服行動網路接入架構演進
支付寶無線團隊於 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 衝突、異構系統不容易整合的問題。ServiceMesh 的出現給我們帶來新的思路，我們將閘道器邏輯做到 ServiceMesh 中的網路代理中，作為 Sidecar 以獨立程序的形式部署到業務系統中，完美支援無損平滑升級，同時也支援異構系統，解決了支付寶內部 Nodejs 和 C 語言系統的去中心化的整合問題。
3. 如何應對新春紅包以及併發挑戰
從 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 對於字典的要求比較高，我們通過清洗線上海量資料，得到合適我們的字典，極大提高了壓縮率和壓縮效能。
4. 螞蟻金服移動網路技術商業化應用與輸出
| 一站式移動開發平臺 mPaaS
螞蟻移動網路技術的商業化是依託於螞蟻金服移動開發平臺 mPaaS。
mPaaS 是源於支付寶 App 近 10 年的移動技術思考和實踐，為移動開發、測試、運營及運維提供雲到端的一站式平臺解決方案，能有效降低技術門檻、減少研發成本、提升開發效率，協助生態夥伴快速搭建穩定高質量的移動 App。行動網路服務在 mPaaS 中提供了 MGS 閘道器服務、MSS 資料同步服務、MPS 推送服務、MDC 排程服務等豐富的網路解決方案。
| 全面整合螞蟻金服技術能力
服務端側的 MGS（閘道器服務）、MPS（推送服務）、MSS（同步服務）是我們的核心服務，它們基本上覆蓋了請求響應、推送、增量更新三種模式，可以滿足大部分的業務應用場景。閘道器服務的開放版開放版支援 HTTP、Dubbo、ZDAS、SOFA-RPC 等多種協議，還支援外掛式功能，通過外掛的方式強化閘道器功能。MSS 服務機制是增量更新的模式，而且可以做順序推送，比如做聊天，聊天訊息必須是一條條到達，不能亂序，而且還可以做到秒級觸達。MPS 服務在國內我們會自建 PUSH 通道，另外在自建通道不可用時會嘗試走小米、華為等廠商 PUSH 通道推送，保證高可用、高推送率。
5. 結語
通過本節內容，相信大家對螞蟻如何構建應對億級併發的網路接入架構以及 mPaaS 移動 API 閘道器服務 MGS 有了初步認識。
關於閘道器功能詳細介紹，可以參考 mPaaS 移動閘道器官方文件： t.cn/EUL8D6o
後續我們將針對 mPaaS 其他服務元件的設計與優化，展開更多探討。
往期閱讀
《支付寶 App 構建優化解析：通過安裝包重排布優化 Android 端啟動效能》