(五)-微服務之間的互動
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 很難重構微服務
2APIGateway.API GatewayAPIGateway
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會造成多餘的網路跳轉