前言

關(guān)于 Service Mesh 和 API Gateway 之間的關(guān)系，這個(gè)問(wèn)題過(guò)去兩年間經(jīng)常被問(wèn)起，社區(qū)也有不少文章和資料給出解答。其中不乏 Christian Posta 這樣的網(wǎng)紅給出過(guò)深度介紹。我在這里做一個(gè)資料的整理和匯總，結(jié)合個(gè)人的理解給出一些看法。

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

備注2:? 這邊文章更關(guān)注于梳理整個(gè)脈絡(luò)，內(nèi)容不會(huì)展開(kāi)的特別細(xì)，尤其是其他文章已經(jīng)詳細(xì)闡述的部分。如果您在瀏覽本文之后，還想更深入的了解細(xì)節(jié)，請(qǐng)繼續(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)外部），以實(shí)現(xiàn)業(yè)務(wù)功能；

如上圖所示：

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

• 位于最底層的是拆分好的原子微服務(wù)，以服務(wù)的形式提供各種能力；

• 在原子微服務(wù)上是（可選的）組合服務(wù)，某些場(chǎng)景下需要將若干微服務(wù)的能力組合起來(lái)形成新的服務(wù)；

• 原子微服務(wù)和組合服務(wù)部署于?系統(tǒng)內(nèi)部，在采用 Service Mesh 的情況下，由 Service Mesh 提供服務(wù)間通訊的能力；

• API Gateway 用于將系統(tǒng)內(nèi)部的這些服務(wù)暴露給?系統(tǒng)外部，以 API 的形式接受外部請(qǐng)求；

從部署上說(shuō)：

• Service Mesh 部署在系統(tǒng)內(nèi)部：因?yàn)樵游⒎?wù)和組合服務(wù)通常不會(huì)直接暴露給外部系統(tǒng)；

• API Gateway 部署在系統(tǒng)的邊緣：一方面暴露在系統(tǒng)之外，對(duì)外提供 API 供外部系統(tǒng)訪問(wèn)；一方面部署在系統(tǒng)內(nèi)部，以訪問(wèn)內(nèi)部的各種服務(wù)；

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

• 東西向通訊：指服務(wù)間的相互訪問(wèn)，其通訊流量在服務(wù)間流轉(zhuǎn)，流量都位于系統(tǒng)內(nèi)部；

• 南北向通訊：指服務(wù)對(duì)外部提供訪問(wèn)，通常是通過(guò) API Gateway 提供的 API 對(duì)外部暴露，其通訊流量是從系統(tǒng)外部進(jìn)入系統(tǒng)內(nèi)部；

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

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

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

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

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

所以，API Gateway 作為一個(gè)客戶端訪問(wèn)內(nèi)部服務(wù)時(shí)，到底算南北向還是東西向，就成為一個(gè)哲學(xué)問(wèn)題：完全取決于我們?nèi)绾慰创?API Gateway ，是作為一個(gè)整體，還是邏輯上分拆為對(duì)內(nèi)對(duì)外兩個(gè)部分。

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

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

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

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

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

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

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

答案不重要。

Sidecar：真正的重合點(diǎn)

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

1. 功能和職責(zé)清晰劃分；

2. 客戶端訪問(wèn)服務(wù)的功能高度重疊；

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

而隨著時(shí)間的推移，當(dāng) Service Mesh 產(chǎn)品和 API Gateway 產(chǎn)品開(kāi)始出現(xiàn)相互滲透時(shí)，兩者的關(guān)系就開(kāi)始變得曖昧。

在 Service Mesh 出現(xiàn)之后，如何為基于 Service Mesh 的服務(wù)選擇合適的 API Gateway 方案，就慢慢開(kāi)始提上日程，而其中選擇重用 Service Mesh 的能力也自然成為一個(gè)探索的方向，并逐步出現(xiàn)新式 API Gateway 產(chǎn)品，其想法很直接：

如何融合東西向和南北向的通訊方案？

其中的一個(gè)做法就是基于 Service Mesh 的 Sidecar 來(lái)實(shí)現(xiàn) API Gateway，從而在南北向通訊中引入 Service Mesh 這種東西向通訊的方案。這里我們不展開(kāi)細(xì)節(jié)，我這里援引一個(gè)圖片(鳴謝趙化冰同學(xué))來(lái)解釋這個(gè)方案的思路：

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

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

• Sidecar：按照 Service Mesh 的標(biāo)準(zhǔn)做法， 我們視 API Gateway 為一個(gè)部署于 Service Mesh 中的普通服務(wù)，為這個(gè)服務(wù) 1:1 的部署 Sidecar；

在這個(gè)方案中，原來(lái)用于 Service Mesh 的 Sidecar，被用在了 API Gateway 中，替代了 API Gateway 中原有的客戶端訪問(wèn)的各種功能。這個(gè)方案讓 API Gateway 的實(shí)現(xiàn)簡(jiǎn)化了很多，也實(shí)現(xiàn)了東西向和南北向通訊能力的重用和融合，而 API Gateway 可以更專注于 “API Management” 的核心功能。

此時(shí) Service Mesh 和 API Gateway 的關(guān)系就從“涇渭分明”變成了“兼容并濟(jì)”。

而采用這個(gè)方案的公司，通常都是先有 Service Mesh 產(chǎn)品，再基于 Service Mesh 產(chǎn)品規(guī)劃（或者重新規(guī)劃） API Gateway 方案，典型如螞蟻金服的 SOFA Gateway 產(chǎn)品是基于 MOSN，而社區(qū)開(kāi)源產(chǎn)品 Ambassador 和 Gloo 都是基于 Envoy。

上述方案的優(yōu)勢(shì)在于 API Gateway 和 Sidecar 獨(dú)立部署，職責(zé)明確，架構(gòu)清晰。但是，和 Service Mesh 使用Sidecar 被質(zhì)疑多一跳會(huì)造成性能開(kāi)銷影響效率一樣，API Gateway 使用 Sidecar 也被同樣的質(zhì)疑：多了一跳......

解決“多一跳”問(wèn)題的方法簡(jiǎn)單而粗暴，基于 Sidecar，將 API Gateway 的功能加進(jìn)來(lái)。這樣 API Gateway 本體和 Sidecar 再次合二為一：

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

BFF：把融合進(jìn)行到底

BFF(Backend For Frontend) 的引入會(huì)讓 Service Mesh 和 API Gateway 走到一個(gè)更加親密的地步。

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

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

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

• BFF 不同，BFF 如名字所示，Backend For Frontend，完全是為了前端而存在，核心目標(biāo)之一是簡(jiǎn)化前端的訪問(wèn)；

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

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

放大一點(diǎn)，單獨(dú)看 API Gateway 和 BFF：

注意到，流量從被 API Gateway 接收，到進(jìn)入 BFF 在這個(gè)流程中，這個(gè)請(qǐng)求路徑中有兩個(gè) Sidecar：

• 和 BFF 部署在一起的，是沒(méi)有 API Gateway 功能的普通 Sidecar；

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

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

此時(shí)的場(chǎng)景是這樣：

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

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

• BFF 通過(guò) Sidecar 調(diào)用內(nèi)部服務(wù)（和沒(méi)有合并時(shí)一致）；

注意這里有一個(gè)關(guān)鍵點(diǎn)，在前面時(shí)特意注明的：“BFF 完全收口外部流量”。這是前提條件，因?yàn)樵械?API Gateway 集群已經(jīng)不再存在，如果 BFF 沒(méi)能收口全部流量，則這些未能收口的流量會(huì)找不到 API Gateway。當(dāng)然，如果愿意稍微麻煩一點(diǎn)，在部署時(shí)清晰的劃定需要暴露給外界的服務(wù)，直接在這些服務(wù)上部署帶 API Gateway 功能的 Sidecar，也是可行的，只是管理上會(huì)比 BFF 模式要復(fù)雜一些。

另外，在部署上，按照上面的方案，我們會(huì)發(fā)現(xiàn)：API Gateway“消失”了 —— 不再有一個(gè)明確物理部署的 API Gateway 的集群，常規(guī)的中心化的網(wǎng)關(guān)在這個(gè)方案中被融合到每一個(gè) BFF 的實(shí)例中，從而實(shí)現(xiàn)另外一個(gè)重要特性：去中心化。

總結(jié)

本文總結(jié)了 Service Mesh 和 API Gateway 的關(guān)系，整體上說(shuō)兩者的定位和職責(zé)“涇渭分明”，但在具體實(shí)現(xiàn)上，開(kāi)始出現(xiàn)融合的趨勢(shì)：早期傳統(tǒng)方式是類庫(kù)級(jí)別的代碼復(fù)用，最新趨勢(shì)是 API Gateway 和 Sidecar 合二為一。

后者的發(fā)展才剛剛起步，但是相信在未來(lái)一兩年間，社區(qū)可能會(huì)有更多的類似產(chǎn)品形態(tài)出現(xiàn)。

總結(jié)

以上是生活随笔為你收集整理的Service Mesh 和 API Gateway 关系深度探讨的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。