螞蟻金服 Service Mesh 大規模落地系列 - 閘道器篇

本文為《螞蟻金服 Service Mesh 大規模落地系列》第五篇 - 閘道器篇，該系列將會從核心、RPC、訊息、無線閘道器、控制面、安全、運維、測試等模組對 Service Mesh 雙十一大規模落地實踐進行詳細解析。文末包含往期系列文章。

引言

本文結合無線閘道器的發展歷程，解讀進行 Service Mesh 改造的緣由和價值，同時介紹在雙十一落地過程中如何保障業務流量平滑遷移至新架構下的 Mesh 閘道器。分享將從如下三個方面展開：

1. 閘道器的前世今生，解釋閘道器為什麼要 Mesh 化；
2. 閘道器 Mesh 化，闡述如何進行 Mesh 化改造；
3. 雙十一落地，介紹在此過程中實現三板斧能力；

前世今生

螞蟻金服無線閘道器當前接入數百個業務系統，提供數萬個 API 服務，是螞蟻金服客戶端絕對的流量入口，支援的業務橫跨支付寶、網商、財富、微貸、芝麻和國際 A+ 等多種場景。面對多種業務形態、複雜網路結構，無線閘道器的架構也在不斷演進。

中心化閘道器

在 All In 無線的年代，隨著通用能力的沉澱，形成了中心化閘道器 Gateway。

1. 客戶端連線到閘道器接入層叢集 Spanner ；
2. Spanner 會把客戶端請求轉發到無線閘道器叢集 Gateway；
3. Gateway 提供通用能力如鑑權、限流等處理請求，並根據服務標識將請求路由到正確的後端服務；服務處理完請求，響應原路返回；

2016 年新春紅包爆發，螞蟻森林等新興業務發展壯大，閘道器叢集機器數不斷增長。這加劇了運維層面的複雜性，IT成本也不能承受之重。同時，一些核心鏈路的業務如無線收銀臺、掃一掃等，迫切需要與其他業務隔離，避免不可預知的突發流量影響到這些高保業務的可用性。因此，2016 年下半年開始建設和推廣去中心化閘道器。

去中心化閘道器

去中心化閘道器將原先集中式閘道器的能力進行了拆分：

• 轉發邏輯：將 Gateway 中根據服務標識轉發的能力遷移到 Spanner 上；
• 閘道器邏輯：將閘道器通用能力如鑑權、限流、LDC 等功能，抽成一個 mgw jar 整合到業務系統中，與後端服務同JVM 程式執行；

此時，客戶端請求的處理流程如下：

• 客戶端請求到 Spanner 後，Spanner 會根據服務標識轉發請求到後端服務的 mgw 中；
• mgw 進行通用閘道器能力處理，90% 的請求隨即進行 JVM 內部呼叫；

去中心化閘道器與集中式閘道器相比，具有如下優點：

• 提升效能：

    少一層閘道器鏈路，閘道器 jar 呼叫業務是 JVM 內部呼叫；

    大促期間，無需關心閘道器的容量，有多少業務就有多少閘道器；

• 提高穩定性：

    集中式閘道器形態下，閘道器出現問題，所有業務都會收到影響；

    去中心化後，閘道器的問題，不會影響去中心化的應用；

但凡事具有兩面性，隨著在 TOP30 的閘道器應用中落地鋪開，去中心化閘道器的缺點也逐步顯現：

• 研發效能低：

    接入難：需要引入 15+ pom 依賴、20+ 的配置，深度侵入業務配置；

   版本收斂難：當前 mgw.jar 已迭代了 40+ 版本，當前還有業務使用的是初版，難以收斂；

   新功能推廣難：新能力上線要推動業務升級和釋出，往往需要一個月甚至更久時間；

• 干擾業務穩定性：

    依賴衝突，干擾業務穩定性，這種情況發生了不止一次；

    閘道器功能無法灰度、獨立監測，資源佔用無法評估和隔離；

• 不支援異構接入： 非 Java 應用，無法使用去中心化閘道器； 

Mesh 閘道器

去中心化閘道器存在的諸多問題，多數是由於閘道器功能與業務程式捆綁在一起造成的。這引發了我們的思考：如果閘道器功能從業務程式中抽離出來，這些問題是否就可以迎刃而解了？這種想法，與 Service Mesh 的 Sidecar 模式不謀而合。因此在去中心化閘道器發展了三年後，我們再出發對螞蟻金服無線閘道器進行了 Mesh 化改造，以期籍此解決相關痛點。

Mesh 閘道器與後端服務同 Pod 部署，即 Mesh 閘道器與業務系統同伺服器、不同程式，具備閘道器的全量能力。客戶端請求的處理流程如下：

• 客戶端請求到 Spanner 後，Spanner 會根據服務標識轉發請求到後端服務同 Pod 中的 Mesh 閘道器；
• Mesh 閘道器執行通用邏輯後呼叫同機不同程式的業務服務，完成業務處理；

對比去中心化閘道器的問題，我們來分析下 Mesh 閘道器所帶來的優勢：

• 研發效能：

    接入方便：業務無需引入繁雜的依賴和配置，即可接入 Mesh 閘道器；

    版本容易收斂、新功能推廣快：新版本在灰度驗證透過後，即可全網推廣升級，無需維護和排查多版本帶來的各種問題；

• 業務穩定性：

    無損升級：業務系統無需感知閘道器的升級變更，且閘道器的迭代升級將可利用 MOSN 現有的特性進行細粒度的灰度和驗證，做到無損升級；

    獨立監測：由於和業務系統在不同程式，可以實時遙測 Mesh 閘道器程式的表現，並據此評估和最佳化，增強後端服務穩定性；

• 異構系統接入：Mesh 閘道器相當於一個代理，對前端遮蔽後端的差異，將支援 SOFARPC、Dubbo 和 gRPC 等主流 RPC 協議，並支援非 SOFA 體系的異構系統接入；

至此，我們賣瓜自誇式地講完了無線閘道器的前世今生，解釋了為何要擼起袖子進行閘道器 Mesh 化。但細心的你想必懷疑：

• Mesh 化之後的請求處理流程不是同程式呼叫，比起去中心化閘道器多了一跳，是否有效能損耗？
• 畢竟進行了大刀闊斧的變革，在上線過程中如何保障穩定性？

接下來的章節將對上述問題進行解釋。

Mesh 化

架構

首先，從架構層面詳細介紹閘道器 Mesh 化所做的相關工作。依照 Service Mesh 的分層模型，Mesh 閘道器分為資料面和控制面。

解讀：

• 藍色箭頭線是客戶端請求的處理流程，Mesh 閘道器資料面在螞蟻金服內部 MOSN 的 Sidecar 中；
• 綠色箭頭線是閘道器配置下發過程，Mesh 閘道器控制面當前還是由閘道器管控平臺來承載；
• 紅色箭頭線條是 MOSN Sidecar 的運維體系；

MOSN：

資料面

採用 Go 語言實現了原先閘道器的全量能力，融合進 MOSN 的模型中，複用了其他元件已有的能力。 同時網路接入層 Spanner 也實現了請求分發決策能力。

資料轉換

將客戶端的請求資料轉換成後端請求資料，將後端響應資料轉換成客戶端響應。利用 MOSN 協議層擴充套件能力，實現了對閘道器自有協議 Mmtp 的解析能力。

通用功能

授權、安全、限流、LDC 和重試等閘道器通用能力。利用 MOSN Stream Filter 序號產生器制以及統一的 Stream Send/Receive Filter 介面擴充套件而來。

請求路由

客戶端請求按照特定規則路由到正確的後端系統。在閘道器層面實現 LDC 邏輯後，複用 MOSN RPC 元件的路由匹配能力。其中大部分請求都會路由到當前 Zone，從而直接請求到當前 Pod 的業務程式埠。

後端呼叫

支援呼叫多種型別的後端服務，支援對 SOFARPC、Chair 等後端，後期計劃支援更多的 RPC 框架和異構系統。

控制面

為閘道器使用者提供新增、配置 API 等服務的管控系統，可將閘道器配置資料下發至 Mesh 閘道器的 Sidecar 例項；

效能

大家比較關心的是多一跳對業務效能是否有影響？

這個是螞蟻金服內部 MOSN 層面的效能損耗分析，具體分析參見敖小劍的 「螞蟻金服 Service Mesh 深度實踐」。得出的結論是相較於複雜的業務邏輯，Mesh 的效能損耗在可接受的範圍內，同時帶來了快速獲得收益的能力。同時 Mesh 閘道器在此次接入過程中做了 Session 精簡化：

• 內容精簡：從 7k 位元組降低到 650 位元組；
• 無解壓縮：節省 GZip 的效能損耗；
• 無線 PC 隔離：解決 session 汙染問題；

在帶 Session 校驗場景下，相較於去中心化閘道器，基準效能壓測得出的結論是：QPS 提升近 1倍，RT 下降約 15%。在此也感謝業務方在 Session 精簡化改造過程中的理解和支援。

雙十一落地

本次雙十一，Mesh 閘道器的落地情況如下：

• 大促支付鏈路淘系支付 API 100% 引流；
• 大促會員鏈路主戰場應用 100% 引流；
• 閘道器 Top API 5% 引流；

從上述引流情況可以看出，Mesh 閘道器支援多維度百分比引流。當然，新的架構體系在大促時落地，充滿了各種風險。

為了做好風險管控，我們嚴格按照三板斧（可監控、可灰度、可回滾）的要求建設相關能力。當前的 Mesh 閘道器的路由具備 API 百分比、伺服器、Zone 以及應用級別的開關能力，支援業務灰度和應急止血。 

開關                    生效時機                                 作用

Mesh 百分比            立即                      控制某個 API 的 Mesh 路由是否開啟，支援百分比

Label                   自動感知                  控制某臺伺服器的 Mesh 路由是否開啟

Zone                   Spanner Reload             控制某個 Zone 的 Mesh 路由是否開啟

MeshOnly               Spanner Reload              控制某個應用 的 Mesh 路由是否開啟

這裡著重分享下 Mesh 閘道器 API 百分比分流策略。我們和網路接入層 Spanner 配合，開發了 Mesh 分流功能，實現了秒級生效的單個 API 百分比切流 Mesh 閘道器能力。某 API 配置了  去中心化 x%，Mesh 化 y% 的切流規則時的流量示意圖。

• 去中心化閘道器服務：由 port1（Http）或 port2（Mmtp）埠提供服務；
• Mesh 閘道器服務：由 port3（Http）或 port4（Mmtp）埠提供服務；

其中百分比資訊由業務方在 API 管控頁面配置，隨著 API 響應頭帶回 Spanner Worker，由 Worker 自主學習後，按照對應的百分比做分流決策。同時實現了路由失敗回退機制，優先順序  service:去中心化埠 > service:Mesh 埠 > Gateway ，由集中式閘道器進行兜底保證業務不失敗。

最後

寫了這麼多，也到了本次分享的尾聲。隨著雙十一落地和驗證，後續我們會加快推進 Mesh 閘道器在螞蟻金服落地節奏。期待 Service Mesh 在螞蟻金服雲化戰略中發揮重要的作用。Mesh 閘道器也會持續迭代演進，融合雲原生技術，支援南北和東西向流量。

艱難困苦，玉汝於成。

作者介紹

陸鑫，花名悟塵，螞蟻金服 Mesh 閘道器負責人，專注領域：無線閘道器、服務高可用。