螞蟻金服 Service Mesh 大規模落地系列(網關篇)

引言

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

  • 網關的前世今生,解釋網關爲什麼要 Mesh 化;
  • 網關 Mesh 化,闡述如何進行 Mesh 化改造;
  • 雙十一落地,介紹在此過程中實現三板斧能力;

前世今生

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

中心化網關

在 All In 無線的年代,隨着通用能力的沉澱,形成了中心化網關 Gateway。

  • 客戶端連接到網關接入層集羣 Spanner ;
  • Spanner 會把客戶端請求轉發到無線網關集羣 Gateway;
  • 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 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 網關負責人,專注領域:無線網關、服務高可用。

本文轉載自公衆號金融級分佈式架構(ID:Antfin_SOFA)。

原文鏈接

https://mp.weixin.qq.com/s?__biz=MzUzMzU5Mjc1Nw==&mid=2247485649&idx=1&sn=9313cd7ad588b00a214528ae682861a4&chksm=faa0e70bcdd76e1d10ddb3aa964f8c315383072b97628aaaaa25e38c9dbe1079eb2a5e5d29b5&scene=27#wechat_redirect

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章