背景
html
利用微服務模式構建一套在線商店，並要包含產品細節頁面，須要爲產品信息用戶界面開發出多個版本：後端
- 基於HTML5/JavaScript的用戶界面，用於桌面與移動瀏覽器 —— HTML由服務器端Web應用生成。
- 原生Android與iPhone客戶端——這些客戶端經過REST API與服務器進行交互。
另外，在線商店必須經過REST API發佈產品細節，以供第三方應用程序使用。api
產品細節UI能夠顯示出大量產品信息。舉例來講，Amazon.com的POJOs in Action 圖書詳情頁面中會顯示：瀏覽器
- 此書的基本信息，如標題、做者、價格等
- 書籍的購買記錄
- 庫存
- 購買選項
- 常常與此書籍搭配購買的貨品
- 買過此書的買家常常購買的其它貨品
- 客戶評論
- 賣家排名
- …
在使用微服務模式的在線商店中，產品詳情數據會分佈在多項服務之間，例如：安全
- 產品信息服務—產品的基本信息，如標題與做者等
- 價格服務—產品價格
- 訂單服務—產品的購買歷史
- 庫存服務—當前產品的可購買數量
- 評論服務—客戶評論……
所以，顯示產品詳情的代碼須要從這些服務中獲取信息。服務器
問題網絡
微服務架構的應用客戶端如何訪問各項服務？架構
需求ide
- 微服務提供的API粒度一般與客戶端須要的有所不一樣。微服務一般提供的是細粒度API，這意味着客戶端須要同多項服務進行交互。舉例來講，如以前所提到的，客戶端須要從多項服務處獲取數據方可得到產品詳情。
- 不一樣客戶端須要不一樣的數據。舉例來講，有產品詳情頁面的桌面瀏覽器版本一般較移動版複雜。
- 不一樣客戶端的網絡性能亦有所區別。舉例來講，移動網絡一般較非移動網絡速度更慢且更延遲。固然，廣域網速度也必然低於局域網。這意味着原生移動客戶端所使用的網絡在性能上與服務器端Web應用採用的局域網徹底不一樣。服務器端Web應用可以向後端服務發送多條請求，並且不會影響到用戶體驗，但移動客戶端則只能發送少許請求。
- 服務實例數量與其位置（主機與端口）會發生動態變化。
- 服務的劃分方式會隨時間的推移而改變，且不該被客戶端所感知。
方案微服務
使用API網關做爲所有客戶端的單一入口點。該API網關經過如下兩種方式之一處理請求。部分請求會被直接代理/路由至對應的服務，另外一部分請求則須要接入多項服務。
相比提供知足全部需求的API，API網關能夠針對不一樣客戶端提供出不一樣的API。舉例來講，Netflix API網關運行的是客戶端特定適配代碼，這種代碼可以爲各客戶端提供最符合其需求的API。
API網關還可以實現安全防禦，例如驗證當前客戶端是否有權執行該請求。
示例
結果
API網關有如下優點：
- 確保客戶端沒法察覺應用程序是如何被拆分爲多項微服務的。
- 確保客戶端不受服務實例的位置的影響。
- 爲每套客戶端提供最優API。
- 下降請求/往返次數。舉例來講，API網關可以確保客戶端在單次往返中就從多項服務中檢索出數據。請求數量更少意味着運行負擔更低且用戶體驗更好。API網關對於移動應用而言是必不可少的。
- 將從客戶端調用多項服務的邏輯轉換爲從API網關處調用，從而簡化整個客戶端。
API網關模式也有一些弊端：
- 複雜性高—API網關是另一種須要開發、部署與管理的活動部件。
- API網關會形成多餘的網絡跳轉，從而增長響應時間—不過對於大多數應用程序而言，一次多餘的往返並不會形成什麼影響。
問題：
- 如何實現API網關？若是須要不斷擴展以處理高負載量，那麼事件驅動型/響應型方案是最理想的選擇。在JVM上，Netty、Spring Reactor等基於NIO的庫大有用處。Node.JS也是一個可行的選項。
相關模式
- 微服務模式的存在催生出了對此模式的需求。
- API網關必須使用客戶端發現模式或者服務器端發現模式，從而將請求路由至可用的服務實例處。
已知用例