目錄

Service Mesh vs API Gateway

在前一篇關於Service Mesh的文章中,我提到了幾個關於Service Mesh和API Gateway之間關係的問題，在本篇文章中，我打算就Service Mesh和API Gateway的用途進行進一步討論。

為了區分API Gateway和Service Mesh，讓我們先分別看看兩者各自的關鍵特徵。

API Gateway: 將服務作為被管理的API向外部暴露

使用API Gateway的主要目的是將微服務作為被管理的API暴露（給外部系統）。因此，我們在API Gateway層開發的API或者邊界服務對外提供了業務功能。

API/邊界服務呼叫下游的組合或者原子微服務，通過組合/混裝多個下游微服務的方式來提供業務邏輯。

在API/Edge服務呼叫下游服務時，需要採用一種可靠的通訊方式，應用了斷路器，超時，負載均衡/故障轉移等可靠性模式。因此大部分的API Gateway解決方案都內建了這些特性。

API Gateway也內建了以下特性的支援，包括：服務發現，分析（可見性：效能指標，監控，分散式日誌，分散式呼叫追蹤）和安全。

API Gateway和API管理生態系統的其他元件的關係緊密，比如： API 市場/商店， API 釋出門戶。

Service Mesh：微服務的網路通訊基礎設施

現在我們來看看Service Mesh有哪些不同。

Service Mesh是一個網路通訊基礎設施， 可以用於將應用層的網路通訊功能從你的服務程式碼中剝離出來。

採用Service Mesh， 你不用在服務程式碼中實現用於可靠通訊的模式如斷路，超時等，類似地，Service Mesh也提供了服務發現，服務可見性等其他功能。

API Gateway和Service Mesh實踐

API Gateway和Service Mesh之間的主要不同點：API Gateway是暴露API/邊界服務的關鍵元件，而Service Mesh則僅僅是一個服務間通訊的基礎設施，並不瞭解應用中的業務邏輯。

下圖說明了API Gateway和Service Mesh的關係。如同前面所說，這兩者之間也有一些重疊的部分（例如斷路器等），但重要的是需要理解這兩者是用於完全不同的用途。

圖1： API Gateway和Service Mesh實踐

如上圖所示，Service Mesh作為Sidecar（邊車）和服務一起部署，它是獨立於服務的業務邏輯的。

另一方面，API Gateway 提供了所有的API服務（這些API服務有明確定義的業務功能），它是應用業務邏輯的一部分。API Gateway可以具有內建的服務間通訊能力，但它也可以使用Service Mesh來呼叫下游服務（API Gateway->Service Mesh->Microservices）。

在API管理層次，你可以使用API Gateway內建的服務間通訊能力；也可以通過Service Mesh來呼叫下游服務，以將應用網路通訊功能從應用程式轉移到Service Mesh中。

譯者按

API Gateway和Service Mesh的關係是我最近一直在思考的問題，也和同事及社群的朋友之間進行了一些討論。這篇短文很清晰地總結了兩者之間的相似之處以及這兩者在微服務架構中的不同用途。

文章中提到“可以使用API Gateway內建的服務間通訊能力；也可以通過Service Mesh來呼叫下游服務”。在和同事討論時，大家提到一個比較重要的考慮因素是在API Gateway處引入一個Sidecar可能帶來的額外延遲。

API Gateway作為微服務引用的流量入口，其對效率要求較高，如果隨API Gateway部署一個Sidecar，可能對效率有一定影響。

我對此未進行測試，但從理論上來說，服務發現，重試，斷路等邏輯無論放到API Gateway還是Service Mesh中耗時應該是差不多的，部署Sidecar只是增加了建立一個本地連結的消耗，如下圖所示:

將API Gateway和Service Mesh的功能進行清晰劃分，API Gateway負責應用邏輯，Service Mesh負責服務通訊，Metrics收集等微服務基礎設施，這樣劃分後在架構上更為清晰。對於效率問題，我們可以考慮對API Gateway進行水平擴充套件來解決。

原文