久久久青草久久久青草,国产成人精品三级,91精品国产自产在线观看永久∴

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

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

從部署上說(shuō)：

Servicemesh 部署在系統(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ì)有本文。

問(wèn)題的根源在哪里？

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

哲學(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è)流派：

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

而最終決策通常也和產(chǎn)品的定位有關(guān)：如果希望維持 API Gateway 的獨(dú)立產(chǎn)品定位，希望可以在不同的服務(wù)間通訊方案下都可以使用，則通常選擇前者，典型如 kong；如果和服務(wù)間通訊方案有非常深的淵源，則通常選擇后者，典型如 springcloud 生態(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ù)的能力就成為自然而然的選擇。典型如前面提到的 springcloud 生態(tài)下的 zuul 以及后面開(kāi)發(fā)的 springcloud 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)入 servicemesh 時(shí)代之后，Servicemesh 和 API gateway 的關(guān)系開(kāi)始是這樣：

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

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

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

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

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

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

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

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

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

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

而采用這個(gè)方案的公司，通常都是先有 servicemesh 產(chǎn)品，再基于 servicemesh 產(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)清晰。但是，和 servicemesh 使用 sidecar 被質(zhì)疑多一跳會(huì)造成性能開(kāi)銷影響效率一樣，API Gateway 使用 Sidecar 也被同樣的質(zhì)疑：多了一跳…

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

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

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

BFF(Backend For Frontend)的引入會(huì)讓 Servicemesh 和 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è)重要特性：去中心化。

上述 Servicemesh 和 API Gateway 融合的方案，并未停留在紙面上。

在螞蟻金服內(nèi)部，我們基于 Servicemesh 和 API Gateway 融合 + 去中心化的思路，進(jìn)行過(guò)開(kāi)創(chuàng)性的實(shí)踐和探索。以支付寶移動(dòng)網(wǎng)關(guān)為例，在過(guò)去十年間，網(wǎng)關(guān)經(jīng)歷了從單體到微服務(wù)，從中心化到去中心化，從共享的 gateway.jar 包到利用 MOSN 實(shí)現(xiàn)網(wǎng)關(guān) Mesh 化/Sidecar 化，最終演變成了這樣一個(gè)方案：

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

總結(jié)

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

后者的發(fā)展才剛剛起步，包括在螞蟻金服我們也是才開(kāi)始探索這個(gè)方向，但是相信在未來(lái)一兩年間，社區(qū)可能會(huì)有更多的類似產(chǎn)品形態(tài)出現(xiàn)。

補(bǔ)充介紹一下文中多次提到的“MOSN”：

MOSN 是 MOSN 是 Modular Open Smart Network 的簡(jiǎn)稱，是一款使用 Go 語(yǔ)言開(kāi)發(fā)的網(wǎng)絡(luò)代理軟件，由螞蟻金服開(kāi)源并經(jīng)過(guò)幾十萬(wàn)容器的生產(chǎn)級(jí)驗(yàn)證。 MOSN 作為云原生的網(wǎng)絡(luò)數(shù)據(jù)平面，旨在為服務(wù)提供多協(xié)議、模塊化、智能化、安全的代理能力。 MOSN 可以與任何支持 xDS API 的 Service Mesh 集成，亦可以作為獨(dú)立的四、七層負(fù)載均衡，API Gateway、云原生 Ingress 等使用。

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

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

意猶未盡的同學(xué)，歡迎繼續(xù)閱讀以下內(nèi)容。

按文章發(fā)表的時(shí)間排序：

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