螞蟻金服面對億級併發場景的元件體系設計

作者 ：呂丹（凝睇），2011 年加入支付寶，先後負責了支付寶 Wap、alipass 卡券、SYNC 資料同步等專案，並參與了多次雙十一、雙十二、春節紅包大促活動，在客戶端基礎服務方面有一定的專案實踐經驗與積累。目前負責螞蟻金服移動開發平臺 mPaaS 服務端元件體系最佳化與架構設計。

5 月 6 日，InfoQ 主辦的 QCon 2019 全球軟體開發大會在北京舉行。螞蟻金服技術專家呂丹（凝睇）在大會上做了《螞蟻金服面對億級併發場景的元件體系設計》的分享，我們根據演講整理如下：

今天，我主要想和大家分享一下移動領域基礎元件體系，內容大致可以分為四大塊，第一塊是標準移動研發所需的基礎服務體系，第二塊是支撐億級併發的核心元件“移動接入”的架構演進過程，第三塊是雙十一、雙十二、新春紅包這種大促活動的的應付方法，最後一塊是目前已經對外輸出的基礎服務產品。

0. 移動研發基礎服務體系

首先介紹一下支付寶客戶端的演進過程。之前，支付寶客戶端的主要功能是轉賬、訂單支付、交易查詢等等，更像是一個工具類的 APP，在需要付錢的時候才會掏出來，用完了就放回去了。2013 年，螞蟻金服 all in 無線之後，加入了很多服務，例如餘額寶、卡券、探索發現等，基本是把支付寶網站上的功能都儘量遷移到客戶端，支付寶也逐漸演化成一個平臺級別的客戶端。之後，隨著移動網際網路的快速發展，公司內部孵化出了更多的 APP，其他行業也在移動網際網路圈內鋪開了大量的業務，為了提升使用者量、使用者粘性，APP 之間也開始進行了大量的業務融合，超級 APP 也因此而誕生，APP 開始朝著生態化的模式發展。

截止到目前為止，支付寶客戶端的年活躍使用者數超過 8 億，在大促場景下，同時線上量超過 3 億，併發請求超過 1 億，同時上線的使用者數超過百萬每秒。

而在這些資料的背後一定需要一套龐大、複雜、完整的支撐體系來支援支付寶的運作，移動研發基礎服務體系就是其中的重要組成部分。

按照研發過程，我們把移動研發基礎服務體系分成四大塊：APP 研發階段，主要包括 App 框架、基礎元件、雲端服務和研發工具；App 測試階段 ，主要包括研發協作平臺和真機測試平臺，其中研發協作平臺包含版本管理、迭代管理、安裝包編譯、構建和打包的能力，而真機測試主要是代替人工服務，減少人工消耗，提升測試效率； App 運維階段 ，主要包括智慧釋出、日誌回溯、應急管理和動態配置；App 運營階段，主要包括輿情反饋、實時分析、離線計算和智慧營銷。

1. 螞蟻移動接入架構演進

今天的主題為支撐億級併發下的基礎服務，而在億級併發下移動接入又是最核心、最重要的一個環節。移動接入並不是單個系統，而是一整套元件的總稱，包括：Spanner+ 連線管理、API 閘道器、PUSH 通知和 SYNC 資料同步，它是所有移動業務的流量入口，需要維持客戶端的狀態，支援進行統一的管控，同時還需要進行部分的業務資料處理。

其實，一開始並沒有移動接入這個說法，與支付寶客戶端的演進過程類似，後端移動接入也是逐步迭代演進的。最開始，各個業務服務都是自己提供 API 或者直接暴露能力給客戶端，沒有統一的架構，沒有統一的模型，也沒有統一的管控。

為了解決這個問題，在 all in 階段我們引申出了一個 API 閘道器，由它來做集中式管理，同時新增了 PUSH 推送的能力。因為公司內部有很多 APP，我們希望這些能力能夠複用，所以在架構上，我們支援多 APP 同構，客戶端會提供多個 SDK，可以隨時進行整合。

【閘道器架構】

上圖是一個移動 API 閘道器的架構，從圖中可以看到，我們把 API 生命週期定義為以下幾個階段：API 定義、API 研發、API 釋出、API 配置、API 上線、API 運營和 API 下線。而移動閘道器又把 API 生命週期切分成三大塊，分別是研發支撐階段、執行時階段和服務治理階段。

研發支撐階段主要有四個能力，分別為 Code-Gen、API-MAN、API-Test 和 API-Mock。為了提高 API 資料在網路上的傳輸效率，目前螞蟻的 API 模型全部都採用了 protobuf 進行序列化，因此，為了方便業務開發，API 閘道器提供了統一的基於 proto 檔案的程式碼生成工具，並且為了減少客戶端的檔案大小和方法數限制，我們修改了官方提供的生成程式碼，有效減少了冗餘的方法並大大減小了客戶端檔案大小。

在執行時階段，核心的功能包括 API 流量管控、資料驗籤、使用者鑑權以及介面系統路由等。

API 日常的運維由服務治理體系來搞定，主要的能力為 API 監控，並根據實時資料進行 API 質量模型評估，同時提供了一些應急的管理措施。

API 閘道器最為核心的架構設計是 Pipeline，正如大家所知，閘道器看起來只是一個簡單的 API 管控和路由，但其中涉及的節點卻非常多，而每個節點的功能又相互獨立，並且隨著業務的發展，功能節點會逐漸增加，在某些場景下，還需要做不同的節點組合。如果採用傳統的鏈式呼叫，程式碼執行串會非常的長，同時擴充套件和維護起來都非常的困難。因此我們參考了 netty 的 Pipeline 設計，完成了自己的 Pipeline 鏈路。Pipeline 中的各個 handler 保持相互獨立，同時可以根據需要、根據配置自由捆綁，也為後續的功能延伸提供了良好的架構支撐；

【程式碼變革】

從程式碼來看，我們可以明確的感受到之前的呼叫過程是一個遠端呼叫，需要感知路徑、引數等，而在統一了整個資料的互動之後，對於業務系統來說，這個呼叫過程更像是本地呼叫，直接呼叫函式，封裝模型。透過這種方式，業務類研發同學能夠更關注於自己業務系統的程式碼邏輯編寫，完全不用關注底層通訊的實現，較大的提升了研發效率。

行動網路跟有線網路是有很大區別的。行動網路比較複雜，使用者狀態也比較複雜，有可能是在地下室、電梯或者其它弱網環境中，並且使用者在移動場景下對於體驗的要求非常高，例如在支付時，使用者需要立馬拿到支付結果。之前，我們主要是做了服務端的改進，針對客戶端並沒有做改進。為了解決使用者問題、效能問題、提升使用者體驗，我們在進行了一次升級，做了一個統一接入閘道器，並把它架在基礎元件之上，同時研發了效能資料同步、增強了 IP 排程等能力。

【統一接入閘道器】

統一接入閘道器（ACCGW），可以理解成一個前置的 Nginx，是螞蟻基於 Nginx 二次開發的一套元件，在內部我們叫做 Spanner，它在接入架構中主要負責非業務的那一部分邏輯處理，主要包括 SSL 的解除安裝，MMTP 的協議解析，資料的壓縮、解壓縮，客戶端 TCP 長連線的維持，接入流量的總控，資料包的路由以及客戶端日誌的接入。API 閘道器、PUSH 推送、資料同步等元件，都在它的庇廕之下。

【網路協議最佳化】

MMTP 協議的全稱是螞蟻移動傳輸協議，基於 TLV 的資料結構，這種資料結構的好處是分包解包的效率非常高，且它是基於二進位制的，儲存成本相對較低。同時還滿足了客戶端多個元件的鏈路複用，當然 MMTP 配合客戶端也有自己的一些特性，同時我們也加入了很多新特性，例如智慧連線策略。因為移動環境下使用者的網路狀態不是很可靠，如果是傳統的連線方式，不一定能滿足所有 RPC 請求，所以我們做了策略改進。在能夠使用長連線的情況下儘量使用長連線，如果出現長連線連不上或者閃斷的情況，我們就嘗試使用短連線的方式，短連線可以滿足當時緊急的 RPC 發資料。同時我們也會用一些併發建連的策略，運營商網路通常是先連上哪個就使用哪個連線，連線之後我們會使用智慧心跳策略，用以捕捉不同運營商、不同地區，對於維持連線的心跳時間的差異。

在併發建連的過程中經常會出現客戶端同時存在多端長連線的現象，資料包可能會在中間做傳輸，如果立馬斷掉的話，資料包就丟了，很可能對業務產生影響，因此我們加入了柔性斷連，以確保可能在傳輸過程中的資料包能被安全送達。另外，多個連線建完之後，客戶端可能出現狀況，服務端沒有及時感知到，無法獲知這個連線是好是壞。因此，我們加入了假連線監測，資料包派發的時候攜帶一個序列號，客戶端回報之後，如果序列號返回了，就證明這個連線是可用的，反之，我們就認為這個連線是假死狀態，可以在合適的時間點斷掉該連線。

MTLS 是螞蟻移動安全傳輸協議，基於 TLS1.3。我們在做的時候，TLS1.3 還沒有正式釋出，但是我們瞭解到一些它的特性，並將某些特性加入到了設計中。比如採用了 1RTT ECDHE 的握手方式。1RTT ECDHE 是基於 ECC 加密套件，ECC 的最大特點是金鑰串比較小，更小的資料在移動方面有非常大的優勢，例如提升傳輸效率，節省儲存成本。在儲存或傳輸過程中，資料包大小是移動領域特別關注的點。也因為如此，我們選擇了 ZSTD 壓縮演算法，ZSTD 有非常大的壓縮比，且在該壓縮比之下，壓縮和解壓縮的效率都不錯。另外，在某些可支援重放的業務場景中，我們還加入了 0RTT 策略，第一時間把資料從客戶端傳送到服務端。透過上述最佳化，RPC 的平均響應效率提升了 5~6 倍。

【SYNC 資料同步】

SYNC 資料同步聽起來有點陌生，其實可以理解成是 PUSH 的演進版本。它是基於 TCP、雙向傳輸的。雖然傳統的 RPC 能夠解決絕大多數的問題，但是在某些場景下，它是有缺陷的。例如，客戶端啟動之後，需要透過 RPC 請求去判斷服務端是不是有資料。其實 90% 的情況是查詢介面沒有任何的變化或者返回的資料客戶端已經存在了，所以這個過程非常冗餘。除了資料冗餘以外，請求也冗餘，因為沒有發生變化，呼叫在原則上是可以省下來的。

當初，在 all in 之後，我們做了一些體驗上的最佳化，如預載入能力，當客戶端啟動之後，觸發資料預載入，雖然沒有進入到模組，但為了提升使用者體驗，客戶端傳送很多 RPC 請求，也因此造成了大量的冗餘併發請求。

另一個不足是客戶端沒辦法主動感知到服務端的資料變化，比如在聊天場景中，使用者是等著互動的，如果使用 RCP 定時拉取的方式，客戶端和服務端的成本會非常高，整體響應時間也比較慢。而透過 SYNC 的推送模式，可以在服務端產生資料的時候，基於 TCP 方式把資料推送到客戶端，客戶端可以在第一時間拿到資料做業務渲染，比如支付寶的掃碼支付、當面付都是透過 SYNC 服務來同步的結果資料。

SYNC 的基礎核心是——oplog，它類似於 mysql 的 binlog，是每一條增量資料的快照。SYNC 會為每一條 oplog 生成一個唯一的、遞增的版本號，然後透過記錄客戶端當前資料版本號的方式來計算兩端之間的差量，並僅同步差量資料。因為 SYNC 是基於 TCP，可雙向主動傳輸，從而達到實時、有序、可靠、增量的資料傳輸效果。同時，SYNC 在客戶端觸發場景中，並非基於業務場景，而是基於事件，如建聯、登入、從後臺到前臺等動作，因此，可以達到單次事件觸發多業務的增量計算，而當無增量資料時客戶端也不需要進行任何的其他 RPC 請求，從而極大的減少了客戶的請求數和冗餘資料傳輸，不但提高了效率、實時性，還間接的降低了系統壓力。

【移動排程中心】

對於客戶端請求來說最重要的是在第一時間內找到正確的 IP 並把請求發出去。之前這些工作一般是由傳統 DNS 來做，但傳統 DNS 會有一些問題，例如 DNS 劫持、DNS 解析失敗、不同運營商 DNS 解析效率不同等等，解析 DNS 需要消耗額外的 RTT。

針對這些情況，我們設立了移動排程中心，它是基於 HTTPDNS，並在此基礎上加入了使用者分割槽資訊。什麼叫使用者分割槽呢？面對億級併發，服務端肯定不會在一個機房裡，可能是在多個機房中，且機房內部還有邏輯分割槽。使用者屬於哪個邏輯區只有服務端知道，客戶端本身是感知不到的。當某個分割槽的使用者接入進來後，如果沒有在正確的分割槽內，且又需要轉到其它分割槽做業務處理時，如果是採用傳統 DNS 是無法實現的，因為無法解析出使用者屬於哪個 IP 列表。而 HTTPDNS+ 分割槽資料的模型，可以讓客戶端快速拿到最準確的 IP 地址，同時客戶端還可以針對這個 IP 地址做質量檢測和有效性檢測，在請求之前就確定最優的 IP 地址。另外，HTTPDNS 還可以支援海外節點的部署。HTTPDNS 一定不會比 DNS 的效果差，因為它還有 DNS 來兜底，一旦 HTTPDNS 出現問題，那麼就會切換到 DNS 去做解析。

以上的演進過程滿足了絕大多數日常的需求，但是支付寶有很多大促場景，每次大促的玩法都不同，且峰值集中在一剎那。針對這個場景，我們又孵化出了新的模式，一是 API 閘道器的去中心化，二是 SYNC-PULL 機制，三是 SYNC-Bucket 計算模式。

【閘道器去中心化】

閘道器去中心化解決的一個核心問題就是成本。大促場景下，業務量不停上升，峰值可能非常高。但峰值只有一剎那，其他時間內機器都是處於空閒狀態，這是非常大的資源浪費。而為了保證大促時不崩潰，機器又不能減少，所以對應用的壓力是非常大的。

如果都是做單點，那麼還會存在穩定性的問題。如果閘道器在釋出時出現了某些差錯，那麼有可能影響所有業務流程的處理。另外，如果單個介面出現問題，客戶端出現死迴圈等問題，也會影響到其他系統業務的流程。面對以上情況，我們把閘道器去中心化就可以抵消這些風險，如果只是單個系統出問題，那麼不會因為網路的問題導致其他業務發生問題。

【SYNC-PULL 讀擴散】

為什麼會有 SYNC-PULL 讀擴散的需求呢？因為支付寶內部有非常多大 V 商戶，每個商戶有非常多的關注使用者，它需要定期或不定期的做一些運營訊息投放。如果按照 SYNC 的場景，透過寫擴散的方式給每個關注投放一條資料，不僅浪費儲存，而且效率很低下。假設某個商戶有 5 億關注使用者，5 億資料全部入庫最快也要幾十分鐘。另外，由於我們商戶的數量很多，大家都爭搶這個資源，可能會出現排隊的情況。對於商戶來說，無法立馬將活動觸達到使用者端，對於服務端來說，訊息可能是一模一樣的，造成了儲存浪費。即使是使用了快取，整個索引也需要給每個使用者去存一遍，這對資料的 TPS 依然要求非常高。

為了解決以上問題，我們升級成了讀擴散的模式，把它抽象成關注關係，每個商戶抽象成 Topic，然後把所有資料放在 Topic 下面。因為使用者關注的大 V 相對比較少，且大 V 生產資料的頻率並不高，有效的資料集不是特別多，所以可以把超級大 V 的資料先放在快取裡面，然後透過二叉索引快速定址使用者下的關注關係，並透過原有的 SYNC 機制把增量資料推到客戶端。這樣，原來億級的儲存就變成了一條儲存，原來幾十分鐘的響應時間變成了秒級，效率和體驗都有了極大的提升。

早先，我們做 SYNC 的時候是想讓每個業務都相對獨立、相對隔離，計算也獨立進行。當時的業務場景不多，但是後來接入的業務越來越多，將近有 80 個業務場景，且每個業務都是獨立計算。客戶端是基於事件的，建連之後，需要進行 80 次業務獨立計算，在大促一百萬每秒的傳送量的情況下，很容易就達到億級，這對資料庫、應用程式、快取等的壓力都是非常大的，同時這種方式也沒法滿足未來的持續發展。

為了解決這些問題，我們針對原來的計算特性抽象出了幾個分類。例如，基於使用者維度、基於裝置維度、基於一次性、基於多端同步、基於全域性使用者配置的幾個大類資料，抽象成幾個抽象模型。我們姑且認為是有 5 個 bucket，所有的計算都基於 bucket 方式來做，如果有新的業務加入，那就根據它的特性把它歸到某個 bucket 中。

另外，大促場景下會有高優先順序的業務，所以需要做一些特定的限流策略。針對這種情況，bucket 可以動態的增減，業務進出 bucket 也可以隨時切換。bucket 上線之後，當時我們的計算量下降超過了 80%，在後面的 2、3 年中，業務從 80 個增加到 300 個，伺服器也沒有增加。整體來說，對效能的提升還是非常明顯的。

2. 大促活動場景應對之道

前面的內容主要是移動接入方面的元件設計如何支撐億級場景，下面我們聊一下，如何切實的應對大促活動。

【大促活動場景應對之道：步法】

透過幾年的大促經驗，我們在技術上提煉出了應對大促的幾個步法：首先業務同學設定業務目標，確定業務玩法；技術同學在收到大促介紹之後，開始分解技術指標，並根據各自系統的能力、流程和特性確定相應的技術方案，確定技術方案的步驟則主要為：鏈路分析、容量評估、效能最佳化、流控方案、預案策略以及確定彈性流量規則。在確定完成技術應對方案後，最重要的是進行全鏈路的壓測，透過影子使用者，影子表進行生產環境的全鏈路壓測，每個系統壓測週期短則幾天，長則需要數月。在不斷的壓測中發現問題，發現瓶頸，最佳化後再次進行壓測，直到完成技術目標；在全鏈路完成壓測指標後，進行多輪活動的演練，以模擬真實業務場景，並驗證技術方案的準確性；此後，根據實際需要，擇時進入大促階段。在這個階段，研發同學主要工作是配合運維進行預案的執行、觀察大促期間各種指標的變化，並根據監控確認是否需要應急。當然，應急方案在之前的演練中也需要進行驗證。隨後大促活動結束後，需要進行預案 & 應急策略的回滾和驗證，這樣大促活動才算真正結束。同時，更重要的是，我們需要對每年的大促進行復盤 review，以便發現不足，在後續的活動中加以改進。

【大促活動場景應對之道——流控】

在大促執行過程中，最為關鍵的是流控。對技術同學來說，讓系統在活動中活下來是對大促最給力的支援，流控是系統最有力的屏障。由於各系統在大促活動中發揮的作用、業務的緊急程度、叢集的規模各不相同，因此大促中一般會犧牲一些特性來為主要鏈路騰出效能空間，比如流水日誌、壓縮閾值、訊息順序性等等。

流量的管控也會分多級，在最上層 LVS 會在 VIP 上進行數十億級別的控制，到接入閘道器層則根據建連量、包數進行億級流控，而 API 閘道器層則進行千萬級別的控制。在這幾層上，一般簡單計數即可滿足。而到業務層，特別是中低流量的業務層，一般採取的是令牌桶和分散式限流方式。然後，在 API 閘道器上，也可以做一些自定義的指令碼，mock 返回結果來為業務系統抵擋住一部分請求。

【自動化真機測試】

除了核心鏈路之外，我們也需要一些後勤服務。例如在測試過程中，需要自動化，特別是真機模擬測試來抵消部分的人力勞動。我們的機房中部署了上千臺手機，通常都會進行一些自動化的運維檢測，包括安裝包的安裝解除安裝、效能損耗、功能測試等。除了自動化測試，它還扮演著自動審批和服務巡檢的角色，分別用來檢測小程式和及時發現問題。透過自動測試平臺可以節省 60% 以上的重複體力勞動消耗。

【客戶端智慧釋出——確保客戶端萬無一失】

如果要確保客戶端萬無一失，那麼最核心的就是灰度流程，灰度流程結束之後，我們才能釋出到生產環境中。

智慧釋出主要支援客戶端各種的釋出包，包括安裝包、離線包、小程式包等。透過多年的釋出，我們也沉澱了一些模板，例如灰度使用者、灰度覆蓋率等等。灰度時我們可以選擇一定的模板，按照既定邏輯，使用自動化流程代替人工處理。

【輿情分析——及時獲取使用者反饋】

客戶端釋出之後，業務同學一定非常關心使用者心聲和市場反應，技術同學則希望第一時間收集到使用者的真實反饋。輿情分析系統就用來滿足這些需求，輿情繫統可以分為 4 大塊：資料採集，主要採集渠道為各大媒體中心、應用市場評論、開會的反饋功能和客戶滿意中心的資料；資料內容則可以包含各種熱點話題、熱點事件和主要生產問題；資料儲存，目前主要由 4 大塊來支撐：後設資料一般可以採用關係型資料庫，文件資料使用的是 MongoDB，爬蟲採集的條目透過 MQ 來傳輸，所有資料最終會落至 ES 中，用來做檢索和基礎分析；資料計算更多的是透過檔案演算法來對 ES 中的資料進行分析，最終產出各種趨勢和各種事件、話題排行，同時針對每一個使用者反饋又可以實時通知到相關的負責人。

在這裡我們說的移動分析主要是基於客戶端日誌埋點的資料分析能力。客戶端需要有標準的埋點 SDK 來採集 Native、H5、小程式的各種框架 & 容器埋點，也需要支援業務自定義的業務埋點。同時，為了在大促場景能有效的提升服務端效能，埋點的寫入與上報也需要有一些措施來進行動態的控制，埋點在客戶端完成後，在合適的時機就會上報給服務端的移動日誌閘道器，（移動日誌閘道器目前也已經逐步被納入到移動接入中進來）。當客戶端日誌上報到服務端之後，即可由日誌閘道器輸出到服務端日誌檔案或投遞至訊息元件，供其他的平臺進行消費計算，這包括如 Jstorm、kepler、Flink 這樣實時計算平臺，也可以投遞到 Spark、odps 等離線大資料計算平臺來進行進一步分析。作為基礎元件，移動分析除了日誌採集和同步之外，也進行了一些框架輸出日誌的基本資料分析，行為分析（像日活、新增、流存在）、頁面分析（停留時長，參與度）、閃退分析、卡頓分析，並提供了日誌回溯和日誌拉取等能力供研發同學進行問題排查和分析。當然，這些資料可以用於各種業務分析，分析的形式完全取決於業務方想如何使用。

3. 對外輸出的基礎服務產品

【技術元件產品服務輸出：成熟一個，開放一個】

我們的基礎能力經過這幾年的努力，也沉澱了不少技術產品可以輸出出來。這些技術產品覆蓋了從 APP 研發到測試到運維到運營的各個階段，有客戶端框架、客戶端基礎元件，有云端基礎服務（像 API 閘道器、SYNC 資料同步、PUSH 通知這些），有開放工具，有外掛，有伴隨研發測試的研發協作平臺來進行迭代管理、編譯、構建、打包，真機測試平臺，也有 APP 運維階段所需的智慧釋出、日誌管理、應急管理，還有用於 APP 運營的，各種資料分析和營銷投放產品。這些能力目前已經輸出到了螞蟻國際（印度 paytm、馬來西亞、印度尼西亞、菲律賓等）的多個合作伙伴 APP，公有云的上百個企業級 APP，以及私有云的數十家金融 APP。

我們的宗旨是，成熟一個、開放一個，來與合作伙伴共建移動網際網路的生態。

【一站式研發平臺——mPaaS】

為了能夠幫助合作伙伴快速、有效的建設自己的 APP，我們也推出了一站式的移動研發平臺——mPaaS。mPaaS 囊括了前面說到的各項基礎能力，同時，支援公有云和私有云，mPaaS 不僅僅是技術的輸出，也是生產經驗和運營理念的輸出。