關(guān)于Service Mesh和API Gateway之間的關(guān)系，這個問題過去兩年間經(jīng)常被問起，社區(qū)也有不少文章和資料給出解答。其中不乏 Christian Posta 這樣的網(wǎng)紅給出過深度介紹。我在這里做一個資料的整理和匯總，結(jié)合個人的理解給出一些看法。另外在本文最后，介紹螞蟻金服在Service Mesh和API Gateway融合的這個最新領(lǐng)域的一些開創(chuàng)性的實踐和探索，希望給大家一個更有體感的認(rèn)知。

備注1：為了節(jié)約篇幅，我們將直奔主題，假定讀者對Service Mesh和API Gateway已有基本的了解。備注2: 這邊文章更關(guān)注于梳理整個脈絡(luò)，內(nèi)容不會展開的特別細(xì)，尤其是其他文章已經(jīng)詳細(xì)闡述的部分。如果您在瀏覽本文之后，還想更深入的了解細(xì)節(jié)，請繼續(xù)閱讀文章最后的參考資料和推薦閱讀。

一、原本清晰的界限：定位和職責(zé)

首先，Service Mesh和API Gateway在功能定位和承擔(dān)的職責(zé)上有非常清晰的界限：

• Service Mesh：微服務(wù)的網(wǎng)絡(luò)通信基礎(chǔ)設(shè)施，負(fù)責(zé)（系統(tǒng)內(nèi)部的）服務(wù)間的通訊
• API Gateway：負(fù)責(zé)將服務(wù)以API的形式暴露（給系統(tǒng)外部），以實現(xiàn)業(yè)務(wù)功能

如上圖所示：

從功能和職責(zé)上說：

•    位于最底層的是拆分好的原子微服務(wù)，以服務(wù)的形式提供各種能力
•    在原子微服務(wù)上是（可選的）組合服務(wù)，某些場景下需要將若干微服務(wù)的能力組合起來形成新的服務(wù)
• 原子微服務(wù)和組合服務(wù)部署于 系統(tǒng)內(nèi)部，在采用Service Mesh的情況下，由Service Mesh提供服務(wù)間通訊的能力
• API Gateway用于將系統(tǒng)內(nèi)部的這些服務(wù)暴露給 系統(tǒng)外部，以API的形式接受外部請求。

從部署上說：

• Service Mesh部署在系統(tǒng)內(nèi)部：因為原子微服務(wù)和組合服務(wù)通常不會直接暴露給外部系統(tǒng)
• API Gateway部署在系統(tǒng)的邊緣：一方面暴露在系統(tǒng)之外，對外提供API供外部系統(tǒng)訪問；一方面部署在系統(tǒng)內(nèi)部，以訪問內(nèi)部的各種服務(wù)。

在這里引入兩個使用非常廣泛的術(shù)語：

• 東西向通訊：指服務(wù)間的相互訪問，其通訊流量在服務(wù)間流轉(zhuǎn)，流量都位于系統(tǒng)內(nèi)部
• 南北向通訊：指服務(wù)對外部提供訪問，通常是通過API Gateway提供的API對外部暴露，其通訊流量是從系統(tǒng)外部進入系統(tǒng)內(nèi)部。

解釋一下“東西南北”的由來：如上圖所示，通常在地圖上習(xí)慣性的遵循“上北下南，左東右西”的原則。

總結(jié)：Service Mesh和API Gateway在功能和職責(zé)上分工明確，界限清晰。但如果事情就這么結(jié)束，也就不會出現(xiàn)Service Mesh和API Gateway關(guān)系的討論了，自然也不會有本文。問題的根源在哪里？

強烈推薦閱讀：附錄中 Christian Posta 的文章 “Do I Need an API Gateway if I Use a Service Mesh?“對此有深度分析和講解。

二、哲學(xué)問題：網(wǎng)關(guān)訪問內(nèi)部服務(wù)，算東西向還是南北向？

如下圖所示，圖中黃色的線條表示的是API Gateway訪問內(nèi)部服務(wù)：

問題來了，從流量走向看：這是外部流量進入系統(tǒng)后，開始訪問對外暴露的服務(wù)，應(yīng)該屬于“南北向”通訊，典型如上圖的畫法。但從另外一個角度，如果我們將 API Gateway 邏輯上拆分為兩個部分，先忽略對外暴露的部分，單獨只看 API Gateway 訪問內(nèi)部服務(wù)的部分，這時可以視 API Gateway 為一個普通的客戶端服務(wù)，它和內(nèi)部服務(wù)的通訊更像是“東西向”通訊：

所以，API Gateway 作為一個客戶端訪問內(nèi)部服務(wù)時，到底算南北向還是東西向，就成為一個哲學(xué)問題：完全取決于我們?nèi)绾慰创?API Gateway ，是作為一個整體，還是邏輯上分拆為對內(nèi)對外兩個部分。這個哲學(xué)問題并非無厘頭，在 API Gateway 的各種產(chǎn)品中，關(guān)于如何實現(xiàn) “API Gateway 作為一個客戶端訪問內(nèi)部服務(wù)” ，就通常分成兩個流派：

1. 涇渭分明：視 API Gateway 和內(nèi)部服務(wù)為兩個獨立事物，API Gateway訪問內(nèi)部服務(wù)的通訊機制自行實現(xiàn)，獨立于服務(wù)間通訊的機制
2. 兼容并濟：視 API Gateway 為一個普通的內(nèi)部服務(wù)的客戶端，重用其內(nèi)部服務(wù)間通訊的機制。

而最終決策通常也和產(chǎn)品的定位有關(guān)：如果希望維持 API Gateway 的獨立產(chǎn)品定位，希望可以在不同的服務(wù)間通訊方案下都可以使用，則通常選擇前者，典型如kong；如果和服務(wù)間通訊方案有非常深的淵源，則通常選擇后者，典型如springcloud生態(tài)下的zuul和springcloud gateway。但無論選擇哪個流派，都改變不了一個事實，當(dāng) “API Gateway 作為一個客戶端訪問內(nèi)部服務(wù)” 時，它的確和一個普通內(nèi)部服務(wù)作為客戶端去訪問其他服務(wù)沒有本質(zhì)差異：服務(wù)發(fā)現(xiàn)，負(fù)載均衡，流量路由，熔斷，限流，服務(wù)降級，故障注入，日志，監(jiān)控，鏈路追蹤，訪問控制，加密，身份認(rèn)證…… 當(dāng)我們把網(wǎng)關(guān)訪問內(nèi)部服務(wù)的功能一一列出來時，發(fā)現(xiàn)幾乎所有的這些功能都是和服務(wù)間調(diào)用重復(fù)。這也就造成了一個普遍現(xiàn)象：如果已有一個成熟的服務(wù)間通訊框架，再去考慮實現(xiàn)API Gateway，重用這些重復(fù)的能力就成為自然而然的選擇。典型如前面提到的 springcloud 生態(tài)下的 zuul 以及后面開發(fā)的 springcloud gateway，就是以重用類庫的方式實現(xiàn)了這些能力的重用。這里又是一個類似的哲學(xué)問題：當(dāng) “API Gateway 作為一個客戶端訪問內(nèi)部服務(wù)” 時，它以重用類庫的方式實現(xiàn)了代碼級別的能力重用，相當(dāng)于自行實現(xiàn)了一個和普通服務(wù)間通訊方案完全一樣的客戶端，那這個“客戶端”發(fā)出來的流量算東西向還是南北向？答案不重要。

三、Sidecar：真正的重合點

在進入Service Mesh時代之后，Service Mesh和API gateway 的關(guān)系開始是這樣：

1. 功能和職責(zé)清晰劃分
2. 客戶端訪問服務(wù)的功能高度重疊

此時兩者的關(guān)系很清晰，而且由于當(dāng)時Service Mesh和API Gateway是不同的產(chǎn)品，兩者的重合點只是在功能上。而隨著時間的推移，當(dāng) Service Mesh 產(chǎn)品和 API Gateway 產(chǎn)品開始出現(xiàn)相互滲透時，兩者的關(guān)系就開始變得曖昧。在Service Mesh出現(xiàn)之后，如何為基于Service Mesh的服務(wù)選擇合適的API Gateway方案，就慢慢開始提上日程，而其中選擇重用Service Mesh的能力也自然成為一個探索的方向，并逐步出現(xiàn)新式API Gateway產(chǎn)品，其想法很直接：**如何融合東西向和南北向的通訊方案？**其中的一個做法就是基于Service Mesh的Sidecar來實現(xiàn)API Gateway，從而在南北向通訊中引入Service Mesh這種東西向通訊的方案。這里我們不展開細(xì)節(jié)，我這里援引一個圖片(鳴謝趙化冰同學(xué))來解釋這個方案的思路：

這個時候Service Mesh和API Gateway的關(guān)系就變得有意思了，因為Service Mesh中sidecar的引入，所以前面的“哲學(xué)問題”又有了一個新的解法：API Gateway這次真的可以分拆為兩個獨立部署的物理實體，而不是邏輯上的兩個部分：

1. API Gateway本體：實現(xiàn)API Gateway除了訪問內(nèi)部服務(wù)之外的功能
2. Sidecar：按照Service Mesh的標(biāo)準(zhǔn)做法， 我們視API Gateway為一個部署于Service Mesh中的普通服務(wù)，為這個服務(wù)1:1的部署sidecar

在這個方案中，原來用于Service Mesh的sidecar，被用在了API Gateway中，替代了API Gateway中原有的客戶端訪問的各種功能。這個方案讓API Gateway的實現(xiàn)簡化了很多，也實現(xiàn)了東西向和南北向通訊能力的重用和融合，而 API Gateway可以更專注于 “API Management” 的核心功能。此時 Service Mesh 和 API Gateway 的關(guān)系就從“涇渭分明”變成了“兼容并濟”。而采用這個方案的公司，通常都是先有Service Mesh產(chǎn)品，再基于Service Mesh產(chǎn)品規(guī)劃（或者重新規(guī)劃）API Gateway方案，典型如螞蟻金服的SOFA Gateway產(chǎn)品是基于MOSN，而社區(qū)開源產(chǎn)品Ambassador和Gloo都是基于Envoy。上述方案的優(yōu)勢在于API Gateway和Sidecar獨立部署，職責(zé)明確，架構(gòu)清晰。但是，和Service Mesh使用sidecar被質(zhì)疑多一跳會造成性能開銷影響效率一樣，API Gateway使用Sidecar也被同樣的質(zhì)疑：多了一跳……解決“多一跳”問題的方法簡單而粗暴，基于sidecar，將API Gateway的功能加進來。這樣API Gateway本體和Sidecar再次合二為一：

至于走到這一步之后，Service Mesh和API Gateway是什么關(guān)系：這到底算是Service Mesh/sidecar融合了API Gateway，還是API Gateway融合了Service Mesh/Sidecar？這個問題就像斑馬到底是白底黑紋還是黑底白紋一樣，見仁見智。

四、BFF：把融合進行到底

BFF(Backend For Frontend)的引入會讓Service Mesh和API Gateway走到一個更加親密的地步。先來看看常規(guī)的BFF的玩法：

在這里，多增加了一個 BFF 層，介于API Gateway和內(nèi)部服務(wù)（包括組合服務(wù)和原子微服務(wù)）之間。注意BFF的工作模式和組合服務(wù)很類似，都是組合多個服務(wù)。但差別在于：

1. 組合服務(wù)還屬于服務(wù)的范疇，只是實現(xiàn)機制上組合了多個服務(wù)，對外暴露的依然是一個完整和規(guī)范的服務(wù)
2. BFF不同，BFF如名字所示，Backend For Frontend，完全是為了前端而存在，核心目標(biāo)之一是簡化前端的訪問
3. 對我們今天的話題而言，最關(guān)鍵的一點：BFF完全收口了從外部進入的流量，而組合服務(wù)沒有，API Gateway是可以直接訪問原子微服務(wù)的

“BFF完全收口外部流量”，這一點在API Gateway和Sidecar融合之后，會變得很有想象空間，我們先看按照前面的融合方式，在有BFF的情況下，API Gateway和Sidecar融合后的情景：

放大一點，單獨看API Gateway和BFF：

注意到，流量從被API Gateway接收，到進入BFF在這個流程中，這個請求路徑中有兩個sidecar：

1. 和BFF部署在一起的，是沒有API Gateway功能的普通Sidecar
2. API Gateway和Sidecar融合之后，這就是一個“有API Gateway功能的大Sidecar”（或者是“有Sidecar功能的特殊API Gateway”）：雖然扮演了API Gateway的角色，但本質(zhì)上依然包含一個完整功能的sidecar，和BFF自帶的Sidecar是等同的

所以，問題來了：為什么要放兩個sidecar在流程中，縮減到一個會怎么樣？我們嘗試將兩個Sidecar合二為一，去掉BFF自帶的Sidecar，直接把扮演API Gateway的sidecar給BFF用：

此時的場景是這樣：

1. 流量直接打到BFF上（BFF前面可能會掛其他的網(wǎng)絡(luò)組件提供負(fù)載均衡等功能）
2. BFF的sidecar接收流量，完成API Gateway的功能，然后將流量轉(zhuǎn)給BFF
3. BFF通過sidecar調(diào)用內(nèi)部服務(wù)（和沒有合并時一致）

注意這里有一個關(guān)鍵點，在前面時特意注明的：“BFF完全收口外部流量”。這是前提條件，因為原有的API Gateway集群已經(jīng)不再存在，如果BFF沒能收口全部流量，則這些未能收口的流量會找不到API Gateway。當(dāng)然，如果愿意稍微麻煩一點，在部署時清晰的劃定需要暴露給外界的服務(wù)，直接在這些服務(wù)上部署帶API Gateway功能的Sidecar，也是可行的，只是管理上會比BFF模式要復(fù)雜一些。另外，在部署上，按照上面的方案，我們會發(fā)現(xiàn)：API Gateway“消失”了 —— 不再有一個明確物理部署的API Gateway的集群，常規(guī)的中心化的網(wǎng)關(guān)在這個方案中被融合到每一個BFF的實例中，從而實現(xiàn)另外一個重要特性：去中心化。上述Service Mesh 和 API Gateway融合的方案，并未停留在紙面上。在螞蟻金服內(nèi)部，我們基于Service Mesh 和 API Gateway融合 + 去中心化的思路，進行過開創(chuàng)性的實踐和探索。以支付寶移動網(wǎng)關(guān)為例，在過去十年間，網(wǎng)關(guān)經(jīng)歷了從單體到微服務(wù)，從中心化到去中心化，從共享的 gateway.jar 包到利用MOSN實現(xiàn)網(wǎng)關(guān)Mesh化/Sidecar化，最終演變成了這樣一個方案：

 強烈推薦閱讀：附錄中我的同事 賈島 的文章 “螞蟻金服 API Gateway Mesh 思考與實踐” 對此有深入介紹和詳細(xì)描述。

五、總結(jié)

本文總結(jié)了 Service Mesh 和 API Gateway 的關(guān)系，整體上說兩者的定位和職責(zé)“涇渭分明”，但在具體實現(xiàn)上，開始出現(xiàn)融合的趨勢：早期傳統(tǒng)方式是類庫級別的代碼復(fù)用，最新趨勢是API Gateway和Sidecar 合二為一。后者的發(fā)展才剛剛起步，包括在螞蟻金服我們也是才開始探索這個方向，但是相信在未來一兩年間，社區(qū)可能會有更多的類似產(chǎn)品形態(tài)出現(xiàn)。補充介紹一下文中多次提到的“MOSN”：MOSN 是 Modular Open Smart Network 的簡稱， 是一款使用 Go 語言開發(fā)的網(wǎng)絡(luò)代理軟件，由螞蟻金服開源并經(jīng)過幾十萬容器的生產(chǎn)級驗證。MOSN 作為云原生的網(wǎng)絡(luò)數(shù)據(jù)平面，旨在為服務(wù)提供多協(xié)議、模塊化、智能化、安全的代理能力。MOSN 可以與任何支持 xDS API 的 Service Mesh 集成，亦可以作為獨立的四、七層負(fù)載均衡，API Gateway、云原生 Ingress 等使用。

• GitHub：https://github.com/mosn/mosn
• 官網(wǎng)：https://mosn.io

六、附錄：參考資料和推薦閱讀

意猶未盡的同學(xué)，歡迎繼續(xù)閱讀以下內(nèi)容。按文章發(fā)表的時間排序：

• The Difference Between API Gateways and Service Mesh：2020-02，指導(dǎo)架構(gòu)師確定何時使用API網(wǎng)關(guān)以及何時使用服務(wù)網(wǎng)格，作者Marco Palladino，來自kong。
• Do I Need an API Gateway if I Use a Service Mesh?：2020-01，作者 Christian Posta，中文翻譯版本請見馬若飛同學(xué)的 [使用了 Service Mesh 后我還需要 API 網(wǎng)關(guān)嗎]，對 Service Mesh 技術(shù)和 API 網(wǎng)關(guān)的對比，著重分析了兩者的功能重合點和分歧點，為技術(shù)選型和落地提供了指導(dǎo)思路。
• 螞蟻金服 API Gateway Mesh 思考與實踐: 2019-12，作者賈島，介紹螞蟻金服支付寶網(wǎng)關(guān)的發(fā)展和API Gateway Mesh的由來，強烈推薦閱讀，這個文章非常清晰的介紹了螞蟻金服在Service Mesh和API Gateway融合方面的實踐。
• [API Gateway的身份認(rèn)同危機]: 2019-05, 原文作者 Christian Posta，譯者周雨青，講述API Gateway的基本理念如API的定義，API Management的含義，API Gateway模式，以及服務(wù)網(wǎng)格和API Gateway的關(guān)系。
• 長路漫漫踏歌而行：螞蟻金服Service Mesh實踐探索: 2018-10，我在QCon的演講，我分享了當(dāng)時螞蟻金服在服務(wù)間通訊范圍的探索，提出將服務(wù)網(wǎng)格在東西向通訊中的能力重用到南北向通訊中，當(dāng)時基于Sidecar的SOFA Gateway產(chǎn)品剛開始開發(fā)。
• API Gateway vs Service Mesh: 2018-09，作者Richard Li，Datawire的CEO ，在開發(fā) Ambassador API Gateway。Ambassador 是基于 Envoy 的API Gateway開源產(chǎn)品，文章闡述了對服務(wù)網(wǎng)格和API Gateway的看法，差異，以及對兩者集成的看法。
• DreamMesh拋磚引玉(9)-API Gateway: 2018-03，這個文章也是我寫的，2018年初我和Service Mesh社區(qū)的一些朋友深入探討之后，在DreamMesh系列博客文章中記錄下了當(dāng)時構(gòu)想的方案，尤其對 API gateway和sidecar是分是合有詳細(xì)討論。當(dāng)時想法還不夠成熟，但大體方向已經(jīng)有雛形了。鳴謝當(dāng)時參與討論的同學(xué)！
• Service Mesh vs API Gateway: 2017-10，原文作者 Kasun Indrasiri，以及 趙化冰同學(xué)翻譯的中文版本，文章不長，主要對比了服務(wù)網(wǎng)格和API Gateway的產(chǎn)品功能，提出了兩者融合的方式——在API Gateway中通過服務(wù)網(wǎng)格來調(diào)用下游服務(wù)。
• Application Network Functions With ESBs, API Management, and Now.. Service Mesh?：2017-08，作者 Christian Posta，講述服務(wù)網(wǎng)格與ESB，消息代理和API管理之類的事物的關(guān)系。內(nèi)容非常好，強烈推薦閱讀（我不得不吐糟一下：配圖太辣眼睛）。