螞蟻金服 API Gateway Mesh 思考與實踐

本文整理自螞蟻金服高級技術專家賈島在 12 月 28 日 Service Mesh Meetup 杭州站現場分享。

MOSN 完成孵化， 啓用獨立 Group

2020.2019.12.18，MOSN 項目負責人、螞蟻金服應用網絡組負責人涵暢宣佈 MOSN 完成從 SOFAStack 的孵化，將啓用獨立 Group 進行後續運做，歡迎你們共同建設社區。

MOSN 是一款使用 Go 語言開發的網絡代理軟件，做爲雲原生的網絡數據平面，旨在爲服務提供多協議，模塊化，智能化，安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的簡稱，能夠與任何支持 xDS API 的 Service Mesh 集成，亦能夠做爲獨立的4、七層負載均衡，API Gateway，雲原生 Ingress 等使用。

項目地址：https://github.com/mosn/mosn

導語

在 Service Mesh 微服務架構中，咱們經常會聽到東西流量和南北流量兩個術語。螞蟻金服開源的 Service Mesh Sidecar：MOSN（Modular Observable Smart Network）已經屢次與你們見面交流，以往的議題重點在東西流量的服務發現與路由，那麼螞蟻金服在南北流量上的思考是怎樣的？

本次分享，將從螞蟻金服 API 網關發展歷程來看，Mesh 化的網關架構是怎樣的、解決了什麼問題、雙十一的實踐表現以及咱們對將來的思考。

今天的分享分爲三個部分：

1. API Gateway Mesh 的定義：我在 Google 上搜了下 API Gateway Mesh 這個詞，找到的都是 API Gateway vs Service Mesh，你們估計也會很好奇：這個詞具體的定義是怎樣的呢？因此咱們下面會作將 API Gateway 和 Service Mesh 作個對比，而後講一下我我的對這個詞有理解和思考。
2. API Gateway Mesh 在螞蟻金服的實踐：今年阿里巴巴核心系統 100% 雲原生化，撐住了雙11的世界級流量洪峯，這其中，螞蟻金服的 Service Mesh 大放光彩，核心鏈路全上 Mesh，數萬容器規模，咱們 API Gateway 在其中也承擔了部分錢包鏈路和支付鏈路 100% 的請求。這個章節，我會從螞蟻金服 API 網關的發展歷程來看，咱們爲何作 API Gateway Mesh，咱們的架構是如何的，以及咱們在過程當中的一些風險和考驗。
3. 雲原生下 API Gateway 的思考：你們如今都在講雲原生，可是真正實踐雲原生的過程當中，會越到各類各樣的問題，怎麼樣的 API Gateway 方案和形態是最合適大家的業務的？在雲原生的架構中，Service Mesh，API Gateway 都是最核心的組件之一，咱們對於雲原生下的 API Gateway 在 Service Mesh 架構中的定位是如何思考的？還有，將來咱們的一些計劃是怎樣的？都會在這個章節跟你們分享一下。

API Gateway Mesh 的定義

上面這張圖是一個雲原生，南北+東西流量的架構圖，這裏麪包含了核心的一些組件，我快速介紹一下：

• LBingress：負責 ssl 卸載、入口流量的負載均衡，一般會作一些簡單的路由；
• API Gateway：負責更偏向業務的 API 驗籤、限流、協議轉換、用戶會話、負載均衡等邏輯；
• Sidecar in POD：業務系統中的 Sidecar，代理機房內東西流量的轉發，通常走內部的 RPC（好比SOFARPC Dubbo Thrift SpringCloud），這裏面的流量所有經過 Service Mesh 的 Sidecar Proxy 來承載，這個 Sidecar 負責路由（單元化灰度金絲雀），負載均衡、服務鑑權等等；
• Control Plane：流量控制「大管家」，雲原生裏目前最主流的方案是 Istio，負責路由策略、安全、鑑權等等下發和控制；

上面的架構你們都比較瞭解了，從上面的描述你們也看出來了，API Gateway 和 Service Mesh 的 Sidecar 不少能力都是相似的，好比都是一個網絡代理，都具有負載均衡，都具有一些限流和鑑權能力。下面，咱們將作一個 API  Gateway 和 Service Mesh 的對比。

API  Gateway vs Service Mesh 

從本質概念上來說，API Gateway 用一句話歸納：「Exposes your services as managed APIs」，將內部的服務以更加可控可管理的方式暴露出去，這裏的關鍵詞是「暴露」和「可控」。Service Mesh 用一句話歸納：「A infrastructure to decouple the application network from your service code」，一種將服務代碼與應用網絡解耦的基礎設施，這裏的關鍵詞是「解耦」。

在流量上，API Gateway 是管理南北流量的，而 Servcie Mesh 中的 Sidecar 通常狀況下是用來負載東西流量的Proxy。二者都具有負責均衡的能力，API Gateway 通常狀況下是經過 lvs 、nginx 中心化的一個負載均衡器，咱們管這個叫硬負載；而 Service Mesh 通常狀況下是經過服務發現，Sidecar 之間是點對點的調用，咱們叫軟負載。

通訊協議上，API Gateway 通常對外接收開放的通訊協議，通常是 HTTP、gRPC 等，並且可能涉及到協議的轉換，將 HTTP 轉換成內部的 RPC 協議，而 Service Mesh 代理的內部流量通常是內部的私有 RPC 協議（WebService、Dubbo、SOFABolt、Thrift 等等）。在鑑權、流控、安全等控制流量的層面上，對於 API Gateway 來說都是強依賴的，這樣才體現「可控」的特色，而 Service Mesh 代理的內部流量，因爲通常處於內網環境，這些控制通常狀況下都是弱依賴。

咱們對 Service Mesh 的真正理解

你們能夠看到，API Gateway 和 Service Mesh 實際上有不少共同點，也有不少區別。那 API Gateway Mesh 究竟是如何定義的呢？那要介紹下，咱們對 Service Mesh 的真正理解！

Service Mesh 中的 Sidecar 就是這樣一輛邊車摩托車，Sidecar 將 Service Code 和內部通訊 RPC 邏輯解耦掉。可是 Sidecar 的座位上，不只僅能夠坐「內部通訊的 RPC」，也能夠將其餘中間件放到這輛 Sidecar 中，API Gateway + Sidecar = API Gateway Mesh，咱們也能夠把 MessageQueue Client 放在 Sidecar 中，就是 Message Mesh。

因此，你們看，其實 Service Mesh 是一種模式和架構，關鍵詞就是「解耦」你的服務代碼和你的「中間件」。

API Gateway Mesh 定義

因此 API Gateway Mesh 的定義是：An infrastructure to expose your services as a managed APIs in the form of a decoupled sidecar proxy，以解耦 Sidecar 的形式，將你的服務代碼暴露成可控的 API 基礎設施。

OK，到目前爲止，API Gateway Mesh 的定義解釋清楚了，可是咱們爲何要這樣架構咱們的 API Gateway？這樣作解決了什麼問題？解釋這些問題，要從支付寶 API 網關的發展歷程來看。

螞蟻金服 API Gateway Mesh 實踐

支付寶移動網關的前身

支付寶 APP 初版2009年發佈的，2009年仍是功能機（Nokia Symbian）的天下，APP 移動端還不是流量的主入口，因此 APP 服務器的架構也是很簡單的，全部業務代碼都堆積在一個叫 Mobile 的系統中，對外提供 https restful 服務，這樣的架構優勢就是簡單粗暴。隨着時間的推遲，2013年移動互聯網崛起，智能機（Android&iOS）普及開來，公司愈來愈多的業務轉向移動端，一個 Mobile 系統已經成爲研發的瓶頸，另外單體系統的穩定性問題也凸現出來。

2013年，公司提出「ALL IN」無線的戰略，那個時候產生了移動微服務網關（2014年馬丁大叔提出了微服務概念），主要是解決多業務團隊協做的問題。

微服務網關架構

咱們在這套網關架構中，設計了螞蟻金服無線 RPC 協議（相似於 gRPC），支持客戶端 iOS、Android 多語言 RPC 代碼生成能力，屏蔽了網絡通訊細節，加入了更多安全、鑑權、監控的能力。因爲傳統 Servlet 的線程模型與後端系統 RT 很敏感，咱們將 API Gateway 的通訊所有改爲了 Netty 異步化。爲了解決 HTTP 通訊在移動弱網下的不友好，咱們設計了基於 TCP 的私有長鏈接協議。這樣一個架構支撐了3-4年的業務快速發展。

可是在2016年末，中心化的網關暴露出不少問題，好比：

• 網關更變風險的問題：網關的邏輯變動發佈一旦有問題，將會影響全部業務；
• 業務分級隔離的問題：核心業務的 API 但願和非核心業務的接口作資源上隔；
• 大促容量評估的問題：每一年雙十一、新春紅包活動，上萬 API 接口的 QPS 很難評估，不一樣 API 的 RT、BodySize、QPS 對於網關性能的影響都是不一樣的，爲了網關入口的穩定性，通常狀況下，都會瘋狂的擴容；

去中心化網關

基於上述的問題，咱們打算幹掉形式上的網關，這樣就引入了下一代的網關架構：去中心化網關。

咱們將中心化的網關進行了拆分，將邏輯簡單的路由模塊遷移到 spanner 負載均衡器上，將網關複雜的鑑權、LDC 路由、安全等邏輯抽象成一個 gateway.jar，業務集成這個 Jar 包就具有了網關的能力，這樣業務系統之間作到了隔離，中心化的網關變動風險也不會影響到這些系統，這些系統自己就是一個「網關」，大促容量的問題也再也不是問題。

一個新的架構，解決了一些問題，可是也會引入一些新的問題。

去中心化架構平穩運行了2年，接入了30多個系統（全量系統在數百個），承載了60%-80%的流量，爲何只接入30個系統？由於目前的去中心化網關架構存在不少問題，導入推廣比較困難：

• 接入困難：gateway.jar 依賴了數十個 Jar，另外還存在配置，並且新的版本還在不停加新的依賴；
• Jar 包衝突：一個案例，gateway.jar 依賴 Netty 低版本，某個中間件升級間接升級了這個 Netty 版本，致使網關 Jar 的功能異常；
• 升級困難：最開始的時候，咱們有想過去中心化網關帶來的版本多、升級難的問題，可是當時天真的認爲，網關發展了這麼多年，已經很穩定，不須要常常變動了，並且即便變動，讓須要更新的系統升級一下就行了。可是事情老是想象的太美好：一旦有升級，業務方都要說：開發集成、迴歸測試，沒時間！新功能沒法普及，全網升級更本超級高；
• 異構系統支持：支付寶有部分業務是 Node.js 技術棧的，Node.js 中間件團隊很是牛逼，花了1-2個月時間用 JavaScript 把網關的 Java 的代碼翻譯了一遍，可是後面放棄了更新了，新功能不可能所有 copy 一遍，成本過高，並且研發同窗沒有成就感...

看到這裏，你們是否是感受跟 Service Mesh 解決的問題差很少：解耦網關代碼和業務代碼、獨立升級、支持異構系統。因此咱們將去中心化的網關 Jar 集成到 Service Mesh 的 Sidecar 中，引入了下一代網關架構：Mesh 化網關架構。

Mesh 化網關架構

總結一下：

• 微服務網關架構：解耦業務和網關；
• 去中心化網關架構：解決穩定性、業務分級隔離、大促容量評估等問題；
• Mesh 化網關架構：解決了去中心化升級難，異構系統支持等問題；

螞蟻金服 API Gateway Mesh 架構

下面介紹下螞蟻金服 API Gateway Mesh 的架構和落地過程當中的問題。

上圖是 API Gateway Mesh 的架構圖，其中有3個流：

• 數據流：業務數據經過 Spanner 直接轉發到某個系統中 POD 的 Sidecar 中，通過網關內的各類檢驗邏輯，本地或轉發請求到 SOFA 業務邏輯中；
• 控制流：通常 Service Mesh 中的控制面是 Istio 中的 Pilot 組件，可是因爲原生 Pilot 組件在較大致量體況下性能不行，因此咱們目前沒有走 Pilot，而是直接對接了網關後臺管控；
• Ops 流：是運維的通道，經過 K8s operator sidecar 注入的方式，讓業務具有網關 Mesh 的能力；

API Gateway Mesh 的底座是螞蟻金服開源的 MOSN Sidecar Proxy，咱們基於 MOSN 的模塊化擴展能力，升級了一層 Gateway Core Module，包括核心的 Server、Router、Pipeline、Service、Config 等核心模型，集成了 Lua、JavaScript 等動態腳本加強網關的動態能力，基於 MOSN 的協議擴展能力，輕鬆地實現了螞蟻金服的 MMTP 私有協議。在 Gateway Core 的上線，經過插拔不一樣的 Filter 和 Config，擴展出不一樣場景的網關產品，如螞蟻金服的無線網關、開放平臺網關、金融雲網關等等。控制面上咱們支持多種形式的配置下發通道，包括 Istio 的 XDS、Amdin RestAPI，K8s ConfigMap 等等。

MOSN：https://github.com/mosn/mosn

新技術的上線，絕對不是一件簡單的事！

• 功能：由於 MOSN 是基於 Go 語言研發的，因此咱們要將 Java 技術棧轉向 Go，但不只僅是照搬 Java 代碼，根據 Go 的語言特色，不只作好功能，更好作好性能；
• 性能：最終線上壓測，咱們發現 Mesh 版本比原來的 Java 版本還有必定的性能提高，緣由在於咱們將序列化方式從 Hessian 改爲了 Protobuf，另外 Java 的線程模式切換到 Go 的 goroutine 也帶來了必定的性能提高；
• 運維：運維更想偏於 K8s 雲原生的方向；
• 風險：已知的風險都不是風險，怎麼下降未知的風險？

互聯網公司與傳統軟件公司最大的區別就是敏捷，咱們會將更多的精力放在三板斧的實現上。一般，咱們爲了作一個功能可能花了30%的工做量，可是要花70%的工做量來作灰度、回滾、監控的建設。

在 API Gateway Mesh 上線的過程當中，咱們如何作灰度和快速回滾的？

這裏，我舉一個例子，Spanner 爲新網 Sidecar 切流的流程。咱們支持經過百分比切流，能夠作到慢速度的灰度和快速的回滾。另外，MOSN 的 Sidecar 注入不是一次性全集羣接入的，咱們經過 Label 打標的方式，支持集羣部分單機集成 MOSN 的切流驗證。

雲原生下 API Gateway 的思考

雲原生南北向流量方案

上面介紹的是螞蟻金服在實踐 API Gateway Mesh 的一些經驗，接下來，我想跟你們分享，雲原生下一些標準的南北向流量解決方案的選擇問題。

上圖是業界主流的3種南北向方案，第一種是 K8s Ingress，功能比較簡單；第二種是 Istio Gateway，具有了比 Ingress 更多的路由等功能；第三種是功能更增強大的 API Gateway，能夠更加精細化的管控接口和流量，能夠根據本身業務的特色選擇適合本身的南北向流量產品。

雲原生下 MOSN 的多面性

下面，介紹下 MOSN 的多面性。

前面講過 Service Mesh 的 Sidecar，不只僅只用於南北流量的 RPC，實際上它能夠作全部流量的 Sidecar。

將來，MOSN 的定位就是雲原生全功能網絡代理，能夠和 LB 部署在一塊兒做爲 LB Sidecar；能夠獨立部署做爲中心化網關；能夠和業務 POD 部署做爲去中心化網關或 MessageQueue Client；也能夠做爲跨雲通訊網關。

Service Mesh 已來，還不趕忙上車！以上就是本期的所有分享內容。

做者介紹

靳文祥（花名賈島），螞蟻金服高級技術專家賈島，2011年畢業後加入支付寶無線團隊，一直從事移動網絡接入、API 網關、微服務等相關的研發工做，目前負責螞蟻金服移動網絡接入架構設計與優化。

本期回顧視頻以及分享 PPT 查看地址

https://tech.antfin.com/community/activities/1056/review/962

公衆號：金融級分佈式架構（Antfin_SOFA）