微服務架構實踐（API Gateway）

服務的劃分可能隨著時間或者需求變更而變化

服務例項會動態變化

服務的api粒度，相對而言在微服務架構中，每個服務都只提供相對細粒度的api

這種情況下，我們就需要：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文件管理等，這些功能對於開發和日常運維來說是非常重要的。