背景

理論上，客戶端可以直接向微服務發送請求，每個微服務都有一個公開的URL，該URL將映射到微服務的負載均衡器，由它負責在可用實例之間分發請求。但這種方式存在如下缺陷：

1. 客戶端需求和微服務暴露的細粒度 API 不匹配

經常有一個業務調用很多個服務，假如客戶端發送許多請求，這在公網上可能會很低效，而且會使客戶端代碼變得更復雜。

2. 服務使用的協議不是 Web 友好的

有的服務可能使用二進制 RPC（比如 thrift），有的服務可能使用 AMQP 消息傳遞協議。不管哪種協議都不是瀏覽器友好或防火墻友好的，最好是內部使用。在防火墻之外，應用程序應該使用諸如 HTTP 和 WebSocket 之類的協議。

3. 難重構

隨著時間推移可能想要更改系統劃分成服務的方式。例如，合并兩個服務或者將一個服務拆分成兩個或更多服務。如果客戶端與微服務直接通信，那么執行這類重構就很困難。

由于以上問題，客戶端與微服務直接通信很少是合理的，更好的方法是使用 API 網關，由 API 網關作為后端服務系統的唯一入口。它封裝了系統內部架構，為每個客戶端提供一個定制的 API 。由它負責服務請求路由、組合及協議轉換。有的 API 網關還有其它職責，如身份驗證、監控、負載均衡、緩存。

整體架構

完備的服務網關應該包括三大部分：API 網關、網關控制臺、度量數據采集分析。實際形態各異，可以按需搭建，但肯定少不了 API 網關，網關控制臺的功能職責可能會放到服務注冊等地方而沒有單獨抽取出來，至于度量數據采集可能會在整個微服務架構中存一個通用的度量數據采集應用以監控所有類型應用。

API服務網關整體架構

API 網關的優缺點

1. 優點

封裝了應用程序的內部結構。客戶端只需要同網關交互，而不必調用特定的服務。API 網關為每一類客戶端提供了特定的 API ，從而減少客戶端與應用程序間的交互次數，簡化客戶端代碼的處理。

2. 缺點

增加了一個必須開發、部署和維護的高可用組件。還有一個風險是 API 網關變成了開發瓶頸。為了暴露每個微服務，開發人員必須更新 API 網關。API 網關的更新過程要盡可能地簡單，否則為了更新網關，開發人員將不得不排隊等待。不過，雖然有這些不足，但對于大多數現實世界的應用程序而言使用 API 網關是合理的。

實現的技術

1. 開發語言

對于大多數應用程序而言，API 網關的性能和可擴展性通常都非常重要。因此，API 網關將構建在一個支持異步、I/O 非阻塞的平臺上。JAVA系可以使用一種基于 NIO 的框架，比如Netty、Vertx、Spring Reactor ，還可以使用 Node.js、Nginx Plus。

2. 響應式編程

API 網關通過簡單地將請求路由給合適的后端服務來處理部分請求，而通過調用多個后端服務并合并結果來處理其它請求。對于沒有依賴關系的請求，API 網關應該并發執行以最小化響應時間。使用傳統的異步回調方法編寫 API 組合代碼會陷入回調地獄。代碼會變得混亂、難以理解、容易出錯。可以使用響應式編程以一種聲明式樣式編寫代碼。比如 Scala 中的Future 、Java 8 中的 CompletableFuture 和 JavaScript 中的 Promise ，還有最初是微軟為 .NET 平臺開發的 Reactive Extensions（RX）。Netflix 創建了 RxJava for JVM ，專門用于他們的 API 網關。

3. 進程通信模型

微服務的應用程序必定是一個分布式系統，所以必須使用進程間的通信機制。有兩種類型的進程間通信機制可供選擇。一種是使用異步的、基于消息傳遞的機制。有些實現使用諸如JMS 或 AMQP 那樣的消息代理，而其它的實現（如 Zeromq ）則沒有代理，服務間直接通信。另一種是諸如 HTTP 或 Thrift 那樣的同步機制。通常，一個系統會同時使用異步和同步兩種類型。它甚至還可能使用同一類型的多種實現。總之，API 網關需要支持多種通信機制。

4. 服務發現

API 網關需要知道它與之通信的每個微服務的位置（IP 地址和端口）。應用程序服務的位置是動態分配的。而且，單個服務的一組實例也會隨著自動擴展或升級而動態變化。API 網關需要使用系統的服務發現機制，可以是服務器端發現，也可以是客戶端發現。如果系統使用客戶端發現，那么 API 網關必須能夠查詢服務注冊中心，這是一個包含所有微服務實例及其位置的數據庫。

Spring cloud 提供了服務注冊和發現功能，如果需要自己實現，可以考慮用 Zookeeper 作為注冊表，客戶端用 Curator 。

5. 局部失敗

在實現 API 網關時，還有一個問題需要處理，就是局部失敗的問題。該問題在所有的分布式系統中都會出現，無論什么時候，當一個服務調用另一個響應慢或不可用的服務，就會出現這個問題。API 網關永遠不能因為無限期地等待下游服務而阻塞。不過，如何處理失敗取決于特定的場景以及哪個服務失敗。如果緩存數據可用，那么 API 網關還可以返回緩存數據。數據可以由API網關自己緩存，也可以存儲在像 redis 或 Memcached 那樣的外部緩存中。通過返回默認數據或者緩存數據，API 網關可以確保系統故障不影響用戶的體驗。

在編寫代碼調用遠程服務方面，Netflix Hystrix 是一個異常有用的庫。Hystrix 會將超出設定閥值的調用超時。它實現了一個“斷路器（circuit breaker）”模式，可以防止客戶端對無響應的服務進行不必要的等待。如果服務的錯誤率超出了設定的閥值，那么 Hystrix 會切斷斷路器，在一個指定的時間范圍內，所有請求都會立即失敗。Hystrix 允許用戶定義一個請求失敗后的后援操作，比如從緩存讀取數據，或者返回一個默認值。如果你正在使用 JVM，那么你絕對應該考慮使用 Hystrix 。而如果你正在使用一個非 JVM 環境，那么你應該使用一個等效的庫。

6.參考實現方案

以上列出在 diy 這個 API 網關時需要考慮的點，以及參考的技術實現。下面是幾種目前比較流行的 API 網關搭建的技術方案供參考，后續文章將給出這些方案搭建的例子

1）Nginx + Lua實現負載均衡、限流、服務發現等功能

2）使用 spring cloud 技術棧，其中 zuul 就是用作 API 網關的

3）Mashape 的開源 API 網關 Kong

7.網關控制臺

提供 domain 管理、應用管理、服務授權、服務監控、統計和度量數據展示、查看服務全局視圖等功能。服務消費者和服務提供者都要在網關控制臺進行應用注冊，控制臺為每個應用分配應用id(AppId唯一)和應用密鑰(appSecret)。注冊時需要提供的信息：應用名稱、應用描述、應用負責人相關信息。