在微服務架構風格中，一個大應用通常會被拆分成為了多個小的服務系統提供出來，這些小的系統他們可以自成體系，也就是說這些小系統可以擁有自己的數據庫，框架甚至語言等，這些小系統通常以提供 Rest Api 風格的接口來被 H5, Android, IOS 以及第三方應用程序調用。

我們通常需要在一個界面上展示很多數據，這些數據可能來自於不同的微服務中，比如在一個電商系統中，查看一個商品詳情頁，這個商品詳情頁包含商品的標題，價格，庫存，評論等，這些數據對於後端來說可能是位於不同的微服務系統之中。我們要如何從這些微服務中拉取相應的信息回來呢？

基於以上背景，在微服務架構中，我們可能會遇到一下問題：

• 服務的劃分可能隨著時間或者需求變更而變化
• 服務實例會動態變化
• 服務的API粒度，相對而言在微服務架構中，每個服務都只提供相對細粒度的API
• 不同的客戶端（H5,App等）可能需要不同的數據

這種情況下，我們就需要：API 網關（API Gateway）。API 網關模式意味著你要把API 網關放到你的微服務們的最前端，並且要讓 API 網關變成由應用所發起的每個請求的入口，這樣就可以明顯的簡化客戶端實現和微服務應用程序之間的溝通方式。

API 網關

API Gateway 可以分為兩種：

1.單節點 API Gateway

2.BFF(Backends for frontends) Gateway

API 網關職責

在我們內部，API 網關需要承擔包括但不限於下面的這些職責：

1.請求路由，版本控制

API Gateway 是微服務的入口，可以根據不同的請求路由到不同的服務上，也可以在 Gateway 上進行路由的版本控制，這樣即使後服務發生了變化，Gateway 的路徑依然可以不改變。

2.用戶登錄，權限認證

客戶端在與我們後端服務進行交互之前，需要先進行登錄鑑權操作，這是後端所有的服務都需要有的共有邏輯，因此在 Gateway 做這個事情就再合適不過。

3.數據聚合

由於不同的客戶端往往需要的數據完全不同，而這些數據又是不同的 service 提供的，比如上面提到的查看一個商品詳情頁，我們可能需要同時從商品服務，庫存服務，評價服務等中拉取信息，我們可以藉助 Gateway 方便完成來自不同 service 的數據聚合。

4.協議轉換

在我們的實踐中，CS（Client to Server）協議和SS（Server to Server）協議是不一樣的，為了保證數據傳輸的可靠性，我們的CS協議會有鑑權以及加密解密的邏輯，而在內部的SS協議則不需要這些邏輯，因此在 Gateway 我們需要有一個協議轉換的過程。

5.熔斷，降級，限流

當監測到某個服務發生異常，或者當服務的流量超過我們服務的承載能力等情況時，我們可以採取相應的措施，對整個系統的容錯性、穩定性有很大幫助。

6.負載均衡

API 網關知道所有服務實例的地址，所以可以根據不同服務採取不同的負載均衡策略。

7.灰度發佈

有時候我不希望讓所有的流量都一次性的到達程序的新版本，因為那個新版本也許並沒有測試地很充分。灰度發佈允許你直接只導入指定量的流量到新的版本，API 網關就可以幫你來做這件事情。你可以配置10%的請求到新的版本，然後一旦你確保了新版本沒有bug，你可以把流量切換到100%。

API 網關架構

在我們的內部規劃中(部分功能未實現)，我們的 API 網關主要會分為三個部分，也就是上圖中綠色的幾部分：

1.多網關集群(Backends for frontends)

我們針對不同的客戶端，都有相應的網關層來接入。現階段這一部分已經實現的功能主要是：用戶登錄，鑑權，服務發現註冊，協議轉換，接口版本控制等。後續我們還規劃的功能有：監控，APM調用鏈，日誌，流控策略等。

2.聚合服務(Merge Service)

在某些客戶端的需求中，比如上面提到的商品詳情的頁面，我們需要從多個服務拉取數據，為了減少客戶端的複雜度，以及加快客戶端的訪問速度，我們會在前面加一個聚合層，用來做聚合查詢，在某些接口中可以把多個服務的數據一次性返回給客戶端。

3.儀表盤管理端(Dashboard)

Dashboard 提供可視化的分析平臺，包括服務的管理，監控數據報警配置，日誌查詢，灰度發佈操作，API文檔管理等，這些功能對於開發和日常運維來說是非常重要的。