microservice架構模式中的「開」是各個服務的內部實現，而其中的「閉」則是各個服務之間相互溝通的方式
微服務必須使用程序間通訊機制來互動。微服務架構有兩類ipc機制可選，非同步訊息機制和同步請求/響應機制。當設計服務的通訊模式時，需要考慮幾個問題：服務如何互動，每個服務如何標識api，如何公升級api，以及如何處理部分失敗。
1. api gateway 模式
1.1 背景
當決定將應用當作成一組微服務時，需要決定應用客戶端如何與服務端互動。方式有兩種：
（1）客戶端與服務端直接通訊
（2）採用api gateway，客戶端與api gateway互動，api gateway封裝具體的服務細節，並提供api給各個客戶端。
乙個客戶端可以直接給多個微服務中的任何乙個發起請求。每乙個微服務都會有乙個對外服務端。這個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 版本管理
微服務理論與實踐 六 服務註冊與發現
l 服務的客戶端 包括api閘道器或者其他服務 如何獲取服務端例項的位置 l 每個服務端例項都會在特定的位置 主機及埠 通過http rest或者thrift等方式發布乙個遠端api l 服務端例項的具體數量和位置會發生動態變化 l 虛擬機器與容器通常會被分配動態ip位址 向某一服務傳送請求時，客戶...
五 微服務之間的互動
microservice架構模式中的 開 是各個服務的內部實現，而其中的 閉 則是各個服務之間相互溝通的方式 微服務必須使用程序間通訊機制來互動。微服務架構有兩類ipc機制可選，非同步訊息機制和同步請求 響應機制。當設計服務的通訊模式時，需要考慮幾個問題 服務如何互動，每個服務如何標識api，如何公...
微服務與微服務架構
微服務 微服務強調的是服務的大小，它關注的是某乙個點，是具體解決某乙個問題 提供落地對應服務的乙個服務應用,狹意的看,可以看作eclipse裡面的乙個個微服務工程 或者module。例如 訂單服務 支付服務 微服務架構 馬丁.福勒 martin fowler 微服務架構介紹 微服務架構是 種架構模式...