Categories
程式開發

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


MOSN 完成孵化,啟用獨立 Group

2019.12.18,MOSN 項目負責人、螞蟻金服應用網絡組負責人涵暢宣布 MOSN 完成從 SOFAStack 的孵化,將啟用獨立 Group 進行後續運作,歡迎大家共同建設社區。

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

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

導讀

在 Service Mesh 微服務架構中,我們常常會聽到東西流量和南北流量兩個術語。螞蟻金服開源的Service Mesh Sidecar:MOSN(Modular Observable Smart Network)已經多次與大家見面交流,以往的議題重點在東西流量的服務發現與路由,那麼螞蟻金服在南北流量上的思考是怎樣的?

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

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

今天的分享分為三個部分:

  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 的定義

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

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

  • 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 Mesh 思考與實踐 3

從本質概念上來講,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 的真正理解!

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

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 思考與實踐 5

所以 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 實踐

支付寶移動網關的前身

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

支付寶APP 第一版2009年發布的,2009年還是功能機(Nokia Symbian)的天下,APP 移動端還不是流量的主入口,所以APP 服務器的架構也是很簡單的,所有業務代碼都堆積在一個叫Mobile 的系統中,對外提供https restful 服務,這樣的架構優點就是簡單粗暴。隨著時間的推遲,2013年移動互聯網崛起,智能機(Android&iOS)普及開來,公司越來越多的業務轉向移動端,一個Mobile 系統已經成為研發的瓶頸,另外單體系統的穩定性問題也凸現出來。

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

微服務網關架構

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

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

但是在2016年底,中心化的網關暴露出很多問題,比如:

  • 網關更變風險的問題:網關的邏輯變更發布一旦有問題,將會影響所有業務;

  • 業務分級隔離的問題:核心業務的 API 希望和非核心業務的接口做資源上隔;

  • 大促容量評估的問題:每年雙11、新春紅包活動,上萬API 接口的QPS 很難評估,不同API 的RT、BodySize、QPS 對於網關性能的影響都是不同的,為了網關入口的穩定性,一般情況下,都會瘋狂的擴容;

去中心化網關

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

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

我們將中心化的網關進行了拆分,將邏輯簡單的路由模塊遷移到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 化網關架構

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

總結一下:

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

螞蟻金服 API Gateway Mesh 架構

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

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

上圖是 API Gateway Mesh 的架構圖,其中有3個流:

  • 數據流:業務數據通過 Spanner 直接轉發到某個系統中 POD 的 Sidecar 中,經過網關內的各種檢驗邏輯,本地或轉發請求到 SOFA 業務邏輯中;
  • 控制流:一般 Service Mesh 中的控制面是 Istio 中的 Pilot 組件,但是由於原生 Pilot 組件在較大體量體況下性能不行,所以我們目前沒有走 Pilot,而是直接對接了網關後台管控;
  • Ops 流:是運維的通道,通過 K8s operator sidecar 注入的方式,讓業務具備網關 Mesh 的能力;

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

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

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

新技術的上線,絕對不是一件簡單的事!

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

  • 功能:因為 MOSN 是基於 Go 語言研發的,所以我們要將 Java 技術棧轉向 Go,但不僅僅是照搬 Java 代碼,根據 Go 的語言特點,不僅做好功能,更好做好性能;
  • 性能:最終線上壓測,我們發現Mesh 版本比原來的Java 版本還有一定的性能提升,原因在於我們將序列化方式從Hessian 改成了Protobuf,另外Java 的線程模式切換到Go 的goroutine 也帶來了一定的性能提升;
  • 運維:運維更想偏於 K8s 雲原生的方向;
  • 風險:已知的風險都不是風險,怎麼降低未知的風險?

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

在 API Gateway Mesh 上線的過程中,我們如何做灰度和快速回滾的?

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

這裡,我舉一個例子,Spanner 為新網 Sidecar 切流的流程。我們支持通過百分比切流,可以做到慢速度的灰度和快速的回​​滾。另外,MOSN 的 Sidecar 注入不是一次性全集群接入的,我們通過 Label 打標的方式,支持集群部分單機集成 MOSN 的切流驗證。

雲原生下 API Gateway 的思考

雲原生南北向流量方案

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

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

上圖是業界主流的3種南北向方案,第一種是K8s Ingress,功能比較簡單;第二種是Istio Gateway,具備了比Ingress 更多的路由等功能;第三種是功能更加強大的API Gateway,可以更加精細化的管控接口和流量,可以根據自己業務的特點選擇適合自己的南北向流量產品。

雲原生下 MOSN 的多面性

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

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

前面講過 Service Mesh 的 Sidecar,不僅僅只用於南北流量的 RPC,實際上它可以做所有流量的 Sidecar。

未來,MOSN 的定位就是雲原生全功能網絡代理,可以和LB 部署在一起作為LB Sidecar;可以獨立部署作為中心化網關;可以和業務POD 部署作為去中心化網關或MessageQueue Client;也可以作為跨雲通信網關。

Service Mesh 已來,還不趕緊上車!以上就是本期的全部分享內容。

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

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

作者介紹

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

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

原文鏈接

https://mp.weixin.qq.com/s/o4yrZXhW4tnggctL03t7kw