Microservice架構模式中的“開”是各個服務的內部實現，而其中的“閉”則是各個服務之間相互溝通的方式

微服務必須使用程序間通訊機制來互動。微服務架構有兩類IPC機制可選，非同步訊息機制和同步請求/響應機制。當設計服務的通訊模式時，需要考慮幾個問題：服務如何互動，每個服務如何標識API，如何升級API，以及如何處理部分失敗。

1. API GateWay 模式

1.1 背景

 當決定將應用當作成一組微服務時，需要決定應用客戶端如何與服務端互動。方式有兩種：

（1）客戶端與服務端直接通訊

（2）採用API Gateway，客戶端與API Gateway互動，API Gateway封裝具體的服務細節，並提供API給各個客戶端。

1.2客戶端與服務端直接通訊

   一個客戶端可以直接給多個微服務中的任何一個發起請求。每一個微服務都會有一個對外服務端。這個URL可能會對映到微服務的負載均衡上，它再轉發請求道具體的節點上。

  缺點：

l  客戶端的需求量與微服務暴露的細粒度的API數量不匹配，客戶端需要發起多個請求才能獲取需與的完整資料。

l  客戶端請求的微服務的協議可能不是web友好型的，例如微服務是RPC或AMQP協議的，他們都不是web友好型的

l  很難重構微服務

1.3 API Gateway  

APIGateway是一個伺服器，也是進入系統的唯一節點。API Gateway封裝系統內部的架構，對每個客戶端提供API。

1.3.1 API Gateway的目標

 支援API介面動態釋出及運營，包括但不限於：

（1）安全認證

a. 應用申請稽核通過後生成公鑰，開放平臺需提供支援分散式系統的金鑰管理

服務可設定為兩個安全等級：需授權訪問和無需授權訪問（後者即任意客戶端都可以發起呼叫），預設所有API都需授權訪問。

b. 非正常狀態（禁用、停用、黑名單等）的應用直接拋異常不允許訪問——熔斷機制

c. 呼叫次數、呼叫頻率、併發數可執行時控制，避免某請求量過大影響其他應用的呼叫。

d. 可對某個應用某個API設定強制熔斷，所有請求無視閥值直接丟擲異常。

（2）API管理

所有API可後臺查詢管理，包括動態釋出、引數對映配置、後端服務介面配置、API禁用、啟用，多版本、分組、分級別等。

（3）應用管理

後臺管理開放平臺接入的應用（第三方應用），包括查詢、禁用、啟用、稽核。

（4）計費收費

a. API的呼叫統計，每筆請求時間，響應時間，響應狀態。

b. API的計費計算，按照請求量和請求資源計費，實現多種計費模型。（預付費，後收費。按量，按時間週期。）

（5）       熔斷

（6）       流量統計及限流

l  支援現有子系統RPC協議的API動態釋出及運營，外部請求透傳。

l  支援json、xml響應報文，可以請求時選取所需報文格式。

l  支援動態直接將後端SOA服務暴露為API。

l  支援動態將普通Web介面暴露為API。

l  支援動態將MQ服務暴露為API。

l  支援多個服務組合編排後暴露為API。

l  請求的轉發、合成和協議轉換

l  給客戶端提供一個定製化的API

1.3.2 API Gateway模式的優缺點

（1）優點：

l  特定的API。使客戶端只需跟Gateway打交道，減少客戶端與服務端的通訊次數，也簡化了客戶端的程式碼。

l  去報客戶端不需要受服例項位置的影響

l  為每套客戶端提供最優的API

l  降低請求/往返次數

（2）缺點

l  API Gateway是一個高可用的元件，必須要開發、部署和管理。開發者必須要更新API Gateway來提供新服務提供點來支援新暴露的微服務。

l  API Gateway會造成多餘的網路跳轉

2.3 API 版本管理