螞蟻金服 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：

https://github.com/sofastack/sofa-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		控制某個應用 的 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 網關負責人，專注領域：無線網關、服務高可用。

螞蟻金服 Service Mesh 大規模落地系列文章

• 螞蟻金服 Service Mesh 大規模落地系列-RPC篇
• 螞蟻金服 Service Mesh 大規模落地系列-運維篇
• 螞蟻金服 Service Mesh 大規模落地系列-消息篇
• 螞蟻金服 Service Mesh 大規模落地系列-核心篇
• Service Mesh 落地負責人親述：螞蟻金服雙十一四大考題