1 原本清晰的界限：定位和職責

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

3 Sidecar：真正的重合點

4 BFF：把融合進行到底

5 總結(jié)

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

為了節(jié)約篇幅，我們將直奔主題，假定讀者對 Service Mesh 和 API Gateway 已有基本的了解。

1 原本清晰的界限：定位和職責

首先，Service Mesh 和 API Gateway 在功能定位和承擔的職責上有非常清晰的界限：

Service Mesh：微服務(wù)的網(wǎng)絡(luò)通信基礎(chǔ)設(shè)施，負責（系統(tǒng)內(nèi)部的）服務(wù)間的通訊；

API Gateway：負責將服務(wù)以 API 的形式暴露（給系統(tǒng)外部），以實現(xiàn)業(yè)務(wù)功能；

如下圖所示：

從功能和職責上說：

位于最底層的是拆分好的原子微服務(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)部。

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

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

問題的根源在哪里？

2 哲學問題：網(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ù)時，到底算南北向還是東西向，就成為一個哲學問題：完全取決于我們?nèi)绾慰创?API Gateway ，是作為一個整體，還是邏輯上分拆為對內(nèi)對外兩個部分。

這個哲學問題并非無厘頭，在 API Gateway 的各種產(chǎn)品中，關(guān)于如何實現(xiàn) “API Gateway 作為一個客戶端訪問內(nèi)部服務(wù)” ，就通常分成兩個流派：

涇渭分明：視 API Gateway 和內(nèi)部服務(wù)為兩個獨立事物，API Gateway 訪問內(nèi)部服務(wù)的通訊機制自行實現(xiàn)，獨立于服務(wù)間通訊的機制；

兼容并濟：視 API Gateway 為一個普通的內(nèi)部服務(wù)的客戶端，重用其內(nèi)部服務(wù)間通訊的機制。

而最終決策通常也和產(chǎn)品的定位有關(guān)：如果希望維持 API Gateway 的獨立產(chǎn)品定位，希望可以在不同的服務(wù)間通訊方案下都可以使用，則通常選擇前者，典型如 Kong；如果和服務(wù)間通訊方案有非常深的淵源，則通常選擇后者，典型如 Spring Cloud 生態(tài)下的 Zuul 和 Spring Cloud Gateway。

但無論選擇哪個流派，都改變不了一個事實，當 “API Gateway 作為一個客戶端訪問內(nèi)部服務(wù)” 時，它的確和一個普通內(nèi)部服務(wù)作為客戶端去訪問其他服務(wù)沒有本質(zhì)差異：服務(wù)發(fā)現(xiàn)、負載均衡、流量路由、熔斷、限流、服務(wù)降級、故障注入、日志、監(jiān)控、鏈路追蹤、訪問控制、加密、身份認證…… 當我們把網(wǎng)關(guān)訪問內(nèi)部服務(wù)的功能一一列出來時，發(fā)現(xiàn)幾乎所有的這些功能都是和服務(wù)間調(diào)用重復(fù)。

這也就造成了一個普遍現(xiàn)象：如果已有一個成熟的服務(wù)間通訊框架，再去考慮實現(xiàn) API Gateway，重用這些重復(fù)的能力就成為自然而然的選擇。典型如前面提到的 Spring Cloud 生態(tài)下的 Zuul 以及后面開發(fā)的 Spring Cloud Gateway，就是以重用類庫的方式實現(xiàn)了這些能力的重用。

這里又是一個類似的哲學問題：當 “API Gateway 作為一個客戶端訪問內(nèi)部服務(wù)” 時，它以重用類庫的方式實現(xiàn)了代碼級別的能力重用，相當于自行實現(xiàn)了一個和普通服務(wù)間通訊方案完全一樣的客戶端，那這個“客戶端”發(fā)出來的流量算東西向還是南北向？

答案不重要。

3 Sidecar：真正的重合點

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

功能和職責清晰劃分；

客戶端訪問服務(wù)的功能高度重疊。

此時兩者的關(guān)系很清晰，而且由于當時 Service Mesh 和 API Gateway 是不同的產(chǎn)品，兩者的重合點只是在功能上。

而隨著時間的推移，當 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 這種東西向通訊的方案。這里我們不展開細節(jié)，我這里援引一個圖片（鳴謝趙化冰同學）來解釋這個方案的思路：

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

API Gateway 本體：實現(xiàn) API Gateway 除了訪問內(nèi)部服務(wù)之外的功能；

Sidecar：按照 Service Mesh 的標準做法， 我們視 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 獨立部署，職責明確，架構(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？這個問題就像斑馬到底是白底黑紋還是黑底白紋一樣，見仁見智。

4 BFF：把融合進行到底

BFF（Backend For Frontend）的引入會讓 Service Mesh 和 API Gateway 走到一個更加親密的地步。

先來看看常規(guī)的 BFF 的玩法：

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

組合服務(wù)還屬于服務(wù)的范疇，只是實現(xiàn)機制上組合了多個服務(wù)，對外暴露的依然是一個完整和規(guī)范的服務(wù)；

BFF 不同，BFF 如名字所示，Backend For Frontend，完全是為了前端而存在，核心目標之一是簡化前端的訪問；

對我們今天的話題而言，最關(guān)鍵的一點：BFF 完全收口了從外部進入的流量，而組合服務(wù)沒有，API Gateway 是可以直接訪問原子微服務(wù)的。

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

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

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

和 BFF 部署在一起的，是沒有 API Gateway 功能的普通 Sidecar；

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

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

此時的場景是這樣：

流量直接打到 BFF 上（BFF 前面可能會掛其他的網(wǎng)絡(luò)組件提供負載均衡等功能）；

BFF 的 Sidecar 接收流量，完成 API Gateway 的功能，然后將流量轉(zhuǎn)給 BFF；

BFF 通過 Sidecar 調(diào)用內(nèi)部服務(wù)（和沒有合并時一致）。

注意這里有一個關(guān)鍵點，在前面時特意注明的：“BFF 完全收口外部流量”。這是前提條件，因為原有的 API Gateway 集群已經(jīng)不再存在，如果 BFF 沒能收口全部流量，則這些未能收口的流量會找不到 API Gateway。當然，如果愿意稍微麻煩一點，在部署時清晰的劃定需要暴露給外界的服務(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 化，最終演變成了這樣一個方案：

5 總結(jié)

本文總結(jié)了 Service Mesh 和 API Gateway 的關(guān)系，整體上說兩者的定位和職責“涇渭分明”，但在具體實現(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 集成，亦可以作為獨立的四、七層負載均衡，API Gateway、云原生 Ingress 等使用。