[譯]API網關(API Gateway)

This a translation of an article ( http://microservices.io/patterns/apigateway.html) originally written and copyrighted by Chris Richardson ( http://twitter.com/crichardson).

模式：API網關

背景

咱們假設你使用微服務模式建立一個在線商店，並正在實現商品詳情頁面。你須要開發多個版本的商品詳情用戶界面：

• 用於桌面和手機瀏覽器的基於HTML5/JavaScript的UI - HTML經過服務端web應用生成

• 本地Android和iPhone客戶端 - 這些客戶端經過REST API與服務器交互

另外，在線商店應該經過REST API爲第三方公開商品詳情。

商品詳情能夠展現商品的許多信息。好比，Amazon.com上POJOs in Action詳情頁顯示：

• 圖書的基本信息，如標題，做者，價格等

• 圖書的購買歷史

• 是否有貨

• 購買參數

• 與這本書同時被購買的商品

• 購買了這本書的用戶還買了什麼

• 用戶評論

• 銷售者的評分

• ...

既然在線商店使用了微服務模式，商品詳情數據經過服務來展開。如：

• 商品信息服務(Product Info Service) - 商品基本信息如標題，做者

• 價格服務(Pricing Service) - 商品價格

• 訂單服務(Order service) - 商品購買歷史

• 庫存服務(Inventory service) - 商品是否有貨

• 評論服務(Review service) - 用戶評論 ...

所以，顯示商品詳情的代碼須要從全部這些服務獲取信息。

問題

基於微服務應用的客戶端如何訪問這些獨立服務？

推進力

• 微服務提供的API粒度一般與客戶端的需求不一樣。微服務通常提供細粒度的API，這意味着客戶端須要與多個服務進行交互。好比上面提到的，須要商品詳情的客戶端要從大量服務拉取數據。

• 不一樣的客戶端須要不一樣的數據。好比，商品詳情頁面的桌面版一般比手機版更詳細。

• 不一樣類型客戶端的網絡性能不一樣。如，移動網絡通常比非移動網絡更慢，延遲更高。固然，廣域網(WAN)比局域網(LAN)要慢得多。這意味着手機本地客戶端使用的網絡與服務端web應用的LAN的性能特色區別很大。服務端web應用能夠在不影響用戶體驗的狀況下，向後端服務發送大量請求，但手機客戶端只能發送少許的請求。

• 服務的劃分可能會隨時間而變化，所以須要對客戶端隱藏。

解決方案

實現一個API網關做爲全部客戶端的惟一入口。API網關有兩種方式來處理請求。有些請求被簡單地代理/路由到合適的服務上，其餘的請求被轉給到一組服務。

相比於提供普適的API，API網關根據不一樣的客戶端開放不一樣的API。好比，Netflix API網關運行着客戶端特定的適配器代碼，會向客戶端提供最適合其需求的API。

API網關也能夠實現安全性，好比驗證客戶端是否被受權進行某請求。

舉例

Netflix API網關

結果

使用API網關有以下好處：

• 向客戶端隱藏了應用如何被劃分到微服務的

• 向每一個客戶端提供最優API

• 將調用大量服務的邏輯轉到API網關，於是簡化了客戶端

• 減小了請求/往返數量。好比，API使客戶端能夠在一趟請求中向多個服務拉取數據。請求少了，開銷就少了，所以提高了用戶體驗。API網關對手機應用來講是很是必要的。

API網關模式也有一些缺點：

• 增長了複雜度 - API網關自身也是一個須要被開發、部署和管理的部分。

• 增長了響應時間，由於多了API網關這個網絡躍點 - 可是，對絕大部分應用，多一次往返的開銷是不明顯的。

問題：

• 如何實現API網關？若是爲了伸縮以處理高負載，事件驅動/反應式(reactive)方法是最好的。在JVM上，基於NIO的庫，如Netty, Spring Reactor也能夠。NodeJS是另外一選擇。

相關模式

微服務模式提供了對該模式的需求。

已知用戶

• Netflix API網關

變動

未定

第一篇：一體化架構(Monolithic Architecture)

第二篇：微服務架構(Microservices Architecure)

            伸縮立方(Scale Cube)

第三篇：API網關(API Gateway)