原文地址：http://microservices.io/patterns/apigateway.html，以下是使用google翻譯對原文的翻譯。
讓我們想象一下你正在建立一個使用微服務模式的網上商店，你所用的產品詳細信息頁面。你需要開發多個版本的產品詳情界面：
l 由服務器端Web應用程序生成的HTML - HTML5/ JavaScript的桌面和移動瀏覽器用戶界面。
l 原生Android和iPhone客戶端 - 這些客戶端通過的REST API服務器交互。
此外，網上商店必須通過使用由第三方應用REST API公開的產品詳細信息。一個產品的詳細信息界面可以顯示很多有關產品的信息。例如，Amazon.com的詳細信息頁面包括：
l 關於這本書，如標題，作者，價格等基本信息
l 這本書購買歷史記錄
l 可用性
l 購買選項
l 購買這本書的客戶還買了那些
l 顧客評論
l 賣家排名
l ...
由於網上商店使用微服務模式的，產品詳細信息數據分布在多個服務。 例如，
l 產品信息 - 有關產品，如標題，作者基本信息
l 定價服務 - 產品價格
l 訂購服務 - 購買歷史記錄產品
l 庫存服務 - 產品供應
l 評論服務 - 客戶評論...
因此，顯示產品細節的代碼需要在所有這些服務中獲取信息。
難題
微服務的客戶端是如何訪問個體服務的？
考慮因素
l 通過微服務提供的API的粒度往往和客戶端需要的不同。微服務通常提供細粒度的API，這意味着客戶端需要與多個服務進行交互。例如，如上所述，客戶端需要的產品的細節需要從多種服務獲取數據。
l 不同的客戶端需要不同的數據。例如，產品詳情頁桌面瀏覽器的版本通常更復雜於移動版本。
l 網絡性能因為不同類型的客戶端而不同。例如，移動網絡通常要慢得多，並具有高得多的延遲。當然，任何廣域網是比一個局域網慢得多。這意味着手機本地客戶端使用的網絡與服務端web應用的LAN的性能特點區別很大。服務端web應用可以在不影響用戶體驗的情況下，向后端服務發送大量請求，但手機客戶端只能發送少量的請求。
l 服務實例數量和它們的位置（主機+端口）動態改變。
l 服務可能隨時間改變，所以要對客戶端隱藏細節。
解決方案
可以實現一個API 網關，他是所有客戶端的入口。 API網關有兩種方式來處理請求。有些請求被簡單地代理/路由到合適的服務上，其他的請求被轉給到一組服務。
該API網關可以為每個客戶端提供不同的API，而不是提供一個適合所有情況下的API。例如，Netflix的API網關運行客戶端特定適配器代碼，提供給每個客戶端它們需要的API。
API網關還可以實現安全性，例如： 驗證客戶端被授權執行請求。
結論
使用API網關具有以下優點：
l 使服務和客戶端解耦。
l 使客戶端和服務部署環境解耦。
l 提供了最佳的API給每個客戶端。
l 減少的請求/往返次數。例如，API網關可以一次性檢索多個服務的數據。更少的請求也意味着更少的開銷，提高了用戶體驗。一個API網關對於移動應用至關重要。
l 簡化了客戶端的調用，因為API網關可以組合服務，並提供組合后的façade接口。
API網關模式也有一些缺點：
l 增加的復雜性，API網關是必須開發、部署和管理的另一個應用。
l 增加的響應時間，因為通過API網關多了一層網絡跳轉。然而，對於大多數應用的額外往返的成本是微不足道的。
問題
如何實現API網關？API網關需要支持高並發、高負載，使用事件響應機制（IO兩種機制：一種是阻塞式的，另一種是事件響應式的，還有最新的一種是GO語言微線程方式）是最好的方法。在JVM上，可以基於NIO的庫如Netty，另外 NodeJS是另一個選擇。