弱網優化在支付寶的深度實踐 | mPaaS 線下沙龍 CodeDay#1 分享實錄

做者：凝睇，螞蟻金服移動開發平臺 mPaaS 技術專家。目前負責螞蟻金服移動開發平臺 mPaaS 服務端組件體系優化與架構設計。 內容採編自 CodeDay#1 杭州站現場分享，主題是《弱網優化在支付寶的深度實踐》。

現場視頻： tech.antfin.com/activities/…

0. 背景

隨着 PC 端場景愈來愈重，其發展已日趨飽和，而隨着智能移動設備的興起，移動互聯網呈現出了井噴式發展形態。相比於 PC 互聯網時代的有線網絡，無線網絡通訊的穩定性卻有着巨大的差異；所以，開發者總會面對用戶反饋諸如 App 「不通」、「不快」等各類「網絡問題」。

做爲國民級 App，支付寶須要服務在各類複雜的移動網絡環境下的億級用戶，於是在網絡優化的道路上也是一走就不少年，本文的目的便是將咱們遇到的問題作一個總結，並把在一些實際可行的優化和實踐經驗分享給各位開發者，指望能從某個角度能給各開發者提供一些靈感以幫助你們建設更好的移動 App。

問題歸總

網絡問題，從用戶反饋過來的表象可分爲「不通」或者「不快」，這兩詞雖然只有一字之差，但本質卻徹底不一樣：

• 「不通」，通常爲服務可用性的問題，好比：由服務器宕機引發的「網絡異常」、「操做無響應」、「白屏」或者「徹底收不到消息」等問題；
• 「不快」，則通常爲真實的性能問題，好比：「轉菊花」、「操做響應慢」、「消息接受慢」等。

對於「不通」的問題，主要緣由爲客戶端真實網絡確實不可用或者服務端系統穩定性不足致使，從優化的角度，更偏向於優化服務端架構設計或者從交互角度讓客戶端在異常狀況如何更友好的呈現給用戶，而對於「不快」的問題，咱們則可從技術上作更多的優化和改進，於是也是本文的重點。

問題來源

首先咱們來看一下移動網絡的鏈路：

1. 移動端經過無線網絡協議，從運營商的基站得到無線鏈路分配用以知足跟網絡進行通信；
2. 運營商的網絡基站、控制器，給移動終端進行信號的分配以完成與終端的鏈接和交互；
3. 得到無線鏈路後，會進行網絡附着、加密、鑑權，核心網絡則會檢查終端是否能夠鏈接在這個網絡上，是否有開通套餐，是否是處於漫遊等。目前核心網絡有 SGSN 和 GGSN，這一步主要目的是完成無線網絡協議和有線以太網的協議的轉換；
4. SGSN 和 GGSN 核心網絡會根據終端的狀況進行 APN 的選擇、IP 分配、並啓動計費；
5. 以後纔是咱們所接觸的傳統網絡的步驟：DNS 查詢、響應，TCP 連接，HTTP GET 請求，RTTP RESPONSE 200，HTTP RESPONSE DATA，LAST HTTP RESPONSE DATA 和 UI 展示等等。

因而可知，移動網絡自己鏈路上就相較有線網絡複雜不少，同時終端由於其強烈的「移動」屬性，在不少場景下網絡狀況確實不如人意，好比在地下室、電梯、偏遠地區等等，總會帶來帶寬不足、頻繁丟包、高延遲的問題。與此同時，在進入後端服務器應用網絡以後還有一層層的防火牆、路由器、負載均衡、IDC 分機房部署。 再到客戶端應用程序、服務端的系統設計、接口設計等問題也會極大的影響到在弱網環境下用戶的體驗，如：

1. 客戶端啓動時各類併發 RPC 請求致使網絡或者線程擁塞
2. 服務端流程設計冗長，慢 SQL 等；
3. RPC 接口模型設計沉重，請求或相應模型大量冗餘數據；
4. 靜態未壓縮，或者未分網絡環境，不分用戶使用場景進行資源拉取致使首屏堵塞，遲遲未響應等。

除此以外，傳統網絡協議在流程設計上限定，若是移動 App 自身沒有進行改良和優化，在弱網環境下也可能會成爲絆腳石。

如：

1. TCP 傳輸過程當中爲防止過多的數據注入到網絡中，會先探測一下網絡的擁塞程度，會有由小到大逐漸增長擁塞窗口的大小；
2. 在絕大部分 App 中，均須要進行SSL鏈路加密，所以須要耗費 2 個 RTT 來作證書的交換；
3. 除此以外，不一樣運營商、在不一樣地區對於 DNS 域名解析的支持能力也有所不一樣，絕大部分須要 1 秒以上，在某些狀況下甚至可能超過7秒，而且此處也須要消耗 1 個 RTT。
4. 經過分析上面的幾個可能產生問題的根源，咱們基本就能夠知道在網絡鏈路上、客戶端&服務端流程設計上、以及網絡協議上本都作一些事情來達到優化的效果。

1. 優化指標

作優化必定須要有可量化的指標來衡量和記錄咱們的勞動成果和效果，所以，能夠主要從如下幾個指標入手：

1. 建連成功率：可經過客戶端端埋點的手段進行開展，並經過MAS的數據採集和數據分析等功能來記錄、統計、分析；
2. 建連時⻓（耗時）：依然經過客戶端端埋點的方式，來記錄、統計、分析耗時信息；
3. 鏈接保持時長：此處能夠在服務端和客戶端分別進行實時，主要用以評估終端 TCP 鏈接的穩定性；
4. 移動網關 RPC API 方法的調用成功率（錯誤率）、包大小、耗時等；
5. MSS、MPS 數據同步推送成功率、耗時、包大小等。

其中各類指標均須要區分網絡類型（WiFi、4G、3G等等）、機型等參數進行分別監控，至於其餘的數據則可根據不一樣場景繼續延伸挖掘，並可針對諸如「當面付」等重點業務作專題分析。

2. 優化方向

在前面的章節已經有提到，根據移動網絡的特性，咱們能夠分別從網絡鏈路上，客戶端&服務端流程設計以及網絡協議上下手，在實際的操做過程當中，則經過如下幾方面開展：

1. 網絡服務架構升級：主要組成部分爲AccGW網絡接入網關、MGS移動API網關、MPS消息推送服務、MSS數據同步服務以及MDC移動調度服務。
2. 定製網絡協議：MMTP（螞蟻移動傳輸協議）+MTLS（螞蟻移動安全傳輸協議）；
3. 網絡數據處理：HybridPB 序列化、gzip、zstd、hpack 等壓縮方式升級；
4. 鏈接策略細化：建（斷）連控制、鏈接保持、智能心跳、假鏈接偵測等；
5. 持續業務治理：接口設計優化、靜態資源優化、監控體系建設等。

網絡服務架構升級

如圖中所示，客戶端可拆分爲主進程和 Service 進程，主進程主要承載具體的功能組件和業務模塊，Service 進程則主要負責與服務端進行網絡協議和網絡數據對接，並負責進程保活。

在穿過公網、LVS、以及一系列防火牆、路由器以後，進入後端具體應用可直接感知 SLB，在這以後才正式進入咱們可操做和優化的後端架構：AccGW、ApiGW(MGS)、SyncGW(MSS)、PushGW(MPS)，並由 LinkMng 來統一管理終端的鏈接信息和鏈接生命週期，移動調度這使用 MDC 配合 HTTPDNS 來完成。

AccGW

接入網關目前由 Spanner 來承接：

Spanner 是螞蟻集團基於 Nginx 二次開發的一套事件驅動型系統，其主要功能大體可分爲：

1. 進行 SSL 卸載：可支持標準的 TLS1.0、1.一、1.二、1.3 以及 mtls；
2. 配置管控：可經過控制檯動態的管理配置項、上線、下線，並提供一系列的API可供後端系統動態調用；
3. 動態 UPSTREAM 路由：因須要對接不一樣的基於 mmtp 協議的後端基礎組件，所以須要區分數據包渠道類型（upstream 路由到哪一個基礎組件），並可實時、動態的掛載和下線後端服務器；
4. MMTP 協議處理：包括數據的序列化、反序列化、壓縮、解壓縮；
5. 鏈接保持：須要掛載全部終端的 TCP 鏈接，並經過智能心跳維持住鏈接；
6. 數據埋點：可在最上層進行數據包的埋點記錄，並用戶監控體系爲後續流量管控及網絡分析提供一手數據。
7. 流量管控：其核心目的是在大促場景下，可在最上層將業務流量進行限制和管理，以確保下游系統能安全存活。

MSS 消息同步服務

在基礎服務架構升級中，MSS（SYNC）的出現一樣扮演了及其重要的角色：

在以前的文章中已經有介紹 MSS 是經過一個安全的數據通道 TCP+SSL，及時、準確、有序地將服務器端的業務數據，主動的同步到客戶端 App，其定位是一個客戶端與服務端之間的消息中間件。

MSS 主體思想是：相似 MySQL 數據庫 binlog 原理的基礎上定義了一個 oplog 概念，服務器和客戶端 SDK 之間傳遞的最小數據單元被稱爲一個 oplog，每當業務須要同步一個數據變動到指定的用戶/設備的時候，業務調用MSS服務端的 SyncData 接口，MSS 會將業務須要同步的數據變動包裝爲一個 oplog 持久化到數據庫，而後在客戶端在線的時候把oplog 推送給客戶端，若是當前則當即觸發推送。每一個 oplog 擁有一個惟一的 oplog id，oplog ID 在肯定的用戶、肯定的業務範圍內保證惟一而且單調遞增（按調用順序）。MSS 按照 oplog ID 從小到大的順序把每一條 oplog 都推送到客戶端。經過 ACK 機制服務端和客戶端均會記錄客戶端已同步數據的最大 oplog ID（亦可理解爲數據版本），後續產生新數據時進行差量計算和差量同步。

經過 MSS 能夠給客戶端帶來幾大好處：

1. 業務合併：一次初始化命令，推送多業務數據，減小冗餘的請求數據；
2. 增量推送：增量數據相對較少，減小冗餘數據的傳輸，下降網絡成本；
3. 減小請求：沒有增量數據時，將不會消耗請求成本，減小了無謂的請求；
4. 提升時效：當服務端發生數據變化，能夠直接推送至客戶端，無需等待客戶端請求；
5. 提高體驗：在渲染界面以前，數據已經到位，下降了用戶等待的時間；

這些優點可很是有效的減小客戶端 RPC 接口交互次數，減小須要傳輸的業務數據內容，並因爲其主動推送的特性又可極大的提高用戶的體驗效果。

移動調度

在移動調度的升級上，採用的是 MDC 配合 HTTPDNS，傳統的 DNS 有幾大弊端：

1. 終端網絡請求須要消耗 1 個 RTT 先進行域名解析，須要額外的網絡和時間開支。
2. 運營商 DNS 良莠不齊：不一樣的地區、環境、不一樣的運營商 DNS 解析效率徹底不一樣，快則1秒，滿則 7~8 秒甚至因爲緩存等問題解析失敗。
3. 目前大型 App 均須要進行多機房、多中心部署，傳統 DNS 沒法在客戶端直接路由到指定機房或中心，而且因爲緩存等問題容災效率也不高。
4. 沒法知足自定義的調度需求：灰度、白名單、特殊業務場景指定到具體機房、中心或指定到某一個臺服務器上。
5. 存在 DNS 劫持問題。

經過 MDC 配合 HTTPDNS 則能夠完美的解決以上問題：客戶端經過獨立的網絡請求到服務器拉取可用的 IP 列表，IP 列表信息中已包含了服務端的機房、中心以及白名單相關信息，客戶端在獲取到 IP 列表以後既可根據當前用戶（設備）信息在後面的網絡請求中直接路由到對應的機房、中心、某臺具體服務器或者海外 POP 加速站點。IP 列表可長期的保存在客戶端中，後續的請求中均只須要經過本地 DNS 解析便可以完成 IP 映射，用以節省 1 次 RTT 請求時間，也能夠有效的防範 DNS 域名劫持，於此同時可結合 MSS 等服務來指定實際更新策略來確保第一時間更新 IP 列表。此外，客戶端也可經過按期檢測、定製質量模型等方式來計算、評估獲取最優 IP 地址。

協議優化

• MMTP

MMTP：全稱螞蟻移動傳輸協議，是二進制的 TLV(類型、⻓度、值)結構的協議；是並駕於 HTTP、HTTP2.0、spdy 的私有化傳輸協議。

其主要優勢爲：

1. 打包解包效率高，省內存；
2. 可多路複用，並具備極高的擴展性；
3. 因爲高度的自定義，引入了諸多的特性，如：數據包重發、Sequence 檢測假鏈接、柔性斷鏈並可作到精細管控等。

• MTLS

MTLS：全稱螞蟻移動安全傳輸協議是基於 TLS1.3 擴展的安全傳輸協議。

TLS1.3 可經過證書 cache、session Ticket 等機制支持 1RTT 握手，加密套件則可選用ECDHE，根據有關數據驗證，160 比特 ECC 密鑰和 1024 比特的 RSA 密鑰的安全性至關，小數據量在速度、效率、帶寬、存儲上都會體現出明顯優點，此外在某些特殊功能上，甚至可使用 0RTT 的方式直接完成數據交互。

數據優化

1. 序列化方式：目前在螞蟻體現內已基本普及了 protobuf。Protobuf 全稱 Google Protocol Buffer，是一種輕便高效的結構化數據存儲格式，主要知足結構化數據串行化，或者說序列化。它很適合作數據存儲或 RPC 數據交換格式。可用於通信協議、數據存儲等領域的語言無關、平臺無關、可擴展的序列化結構數據格式。

   而經過 protobuf 官方工具生成的客戶端文件較大，可能會引發安裝包過大，函數方法過多等問題，螞蟻內部在此基礎上又從新定製了生產工具，最終產出物被定義成 HybridPB。

2. ZSTD 壓縮算法：在上一代產品中業務數據 body 主要使用的 gzip 壓縮，而在目前的產品中則主要採用了 ZSTD 壓縮：

   ZSTD 全稱 Zstandard，是一款免費的開源，快速實時數據壓縮程序，具備更好的壓縮比，由 Facebook 開發。 它是用 C 語言編寫的無損壓縮算法 （在 Java 中有一個從新實現） ， 所以它是一個本地 Linux 程序。在移動網絡中，它能夠須要將壓縮速度交換爲更高的壓縮比率（壓縮速度與壓縮比率的權衡能夠經過小增量來配置），它具備小數據壓縮的特殊模式，稱爲字典壓縮，能夠從任何提供的樣本集中構建字典。更高的壓縮比意味着更小的網絡傳輸成本消耗，而這也是在移動端被採用的主要緣由之一。

3. HPACK 壓縮算法：網絡協議上，壓縮算法目前採用的是 HPACK。簡單的說，HPACK 使用 2 個索引表（靜態索引表和動態索引表）來把頭部映射到索引值，對不存在的頭部使用huffman編碼，並動態緩存到索引，從而達到壓縮頭部的效果。

鏈接策略

TCP 建連行爲由移動終端發起：目前主要在終端啓動時、先後臺切換時、網絡超時、鏈接錯誤或者網絡類型切換時會發生建連動做，而建聯的策略上主要由如下幾種：

1. 並行建連：當客戶端串行建連失敗必定次數後、則會進入併發建聯模式，期目的是爲了併發爭取信道，增長創建成功率。
2. 短頻建連：在弱網狀況下可加快創建鏈接的頻率，以踩中一閃而過的可用間隙，第一個連接還沒建上，也可開始第二個。
3. 柔性斷連：因併發建聯引發，某些場景業務可作重連重發，所以對可能並存的多條鏈接，須要作延遲迴收，以等待在這條即將被回收的鏈接上的可能存在的回包。
4. 長短鏈接並存：在某些場景下，由於tcp沒法長久保持，則可經過http短鏈接來提升請求瞬間衝擊能力，快速完成業務請求，並釋放資源。

對於鏈接的保持，傳統的作法就是心跳，心跳包可由客戶端發起，也可由服務端發起。因爲移動端終端的運營商、手機廠商等各類定製、非定製的因素干擾，對於 TCP 鏈接保持能力上各不相同，所以恆定的心跳時間未必能知足各類狀況，過快、過慢都會帶來問題，所以支付寶採用的是動態心跳的方式來維持鏈接，客戶端經過必定的質量模型來評估某一心跳週期的鏈接維持質量，並在過程當中逐步增長或減小心跳週期，在到一個最優的模型質量以後記錄下最優心跳時間，並用改週期時間來維持以後的一段時間。

鏈接超時控制上：除了傳統的業務請求超時和建連超時，還引入了包 sequence 概念，每一個上行包發送時，加入遞增序號，服務端收到帶序的包後，若是有下行包，就把當時收到的最大序號返回給客戶端。客戶端收到後，既可確認全部小於等於這個序號的上行包都已被服務端接受；若是某個上行包的序號在一段時間尚未收到確認，可懷疑出現「假鏈接」，須要進入回收評估階段，服務端下行包亦然。

3. 業務治理：持久戰

在上面的內容中，咱們一直在基礎服務上作文章，而實際的生產過程當中，業務接口的設計也極大的影響着用戶的真實網絡體驗，而且因爲業務在持續發展，人員也持續的迭代，對於優化的規範和設計的思路上並不是都在同一水平上，所以業務治理絕對是一個須要持續堅持不懈戰鬥的過程。在業務治理過程當中也可總結爲幾個方面：

1. 接口設計優化：主要爲接口數據模型設計須要在知足業務功能的基礎儘可能精簡、減小沒必要要的數據傳輸；客戶端併發請求優化，區分優先級，讓客戶端在合適的場景作合適的事情，千萬不可大量併發爭搶資源而影響用戶核心流程的使用，服務端接口流程優化，好比採用異步、緩存、減小慢 SQL 等；
2. 資源拉取策略優化：使用更快捷的圖片格式、在不一樣網絡環境使用不一樣縮放程度的圖片、資源合併、圖片壓縮等；
3. 減小數據量、數據包大小：推廣各業務方接入例如 PB 等更高效的序列化方式，推薦業務接入 MSS，SYNC 服務，經過增量推送的方式減小客戶端請求次數與服務端返回數據的大小；
4. 監控體系持續完善：全鏈路數據打通，問題剖析一杆子到底；多維評價模型，監控預警，數據化研發；作到管控決策有依據，結果有數據，推進有根據；
5. 大戶專項治理：針對重大業務、核心業務，網絡同窗直接深刻業務流程設計，協助業務方發現問題並推進不斷改善。

最後： 鍥而不捨。不管是性能優化、網絡優化，都是一個長期的過程，這也將伴隨着整個終端和服務端的生命週期，所以鍥而不捨的優化改進纔是重中之重。

*注（更多詳細內容）：

• 進一步學習「protobuf」：

  developers.google.com/protocol-bu…

• 進一步學習「ZSTD」：

  facebook.github.io/zstd/

• 進一步學習「HPACK」：

  www.rfc-editor.org/rfc/pdfrfc/…

| 移動開發平臺 mPaaS 三款組件重磅上線螞蟻金服開放平臺：

• 公測期，歡迎體驗試用。支付寶掃碼或登陸開放平臺

往期閱讀

《開篇 | 螞蟻金服 mPaaS 服務端核心組件體系概述》

《螞蟻金服 mPaaS 服務端核心組件體系概述：移動 API 網關 MGS》

《螞蟻金服 mPaaS 服務端核心組件：億級併發下的移動端到端網絡接入架構解析》

《支付寶 App 構建優化解析：經過安裝包重排布優化 Android 端啓動性能》

《支付寶 App 構建優化解析：Android 包大小極致壓縮》

關注咱們公衆號，得到第一手 mPaaS 技術實踐乾貨

釘釘羣：經過釘釘搜索羣號「23124039」

期待你的加入～