1、API閘道器介紹

API閘道器是一個伺服器，是系統的唯一入口。從面向物件設計的角度看，它與外觀模式類似。API閘道器封裝了系統內部架構，為每個客戶端提供一個定製的API。它可能還具有其它職責，如身份驗證、監控、負載均衡、快取、請求分片與管理、靜態響應處理。

API閘道器方式的核心要點是，所有的客戶端和消費端都通過統一的閘道器接入微服務，在閘道器層處理所有的非業務功能。通常，閘道器也是提供REST/HTTP的訪問API。服務端通過API-GW註冊和管理服務。

2、融入架構

API閘道器負責服務請求路由、組合及協議轉換。客戶端的所有請求都首先經過API閘道器，然後由它將請求路由到合適的微服務。API網管經常會通過呼叫多個微服務併合並結果來處理一個請求。它可以在Web協議（如HTTP與WebSocket）與內部使用的非Web友好協議之間轉換。

API閘道器還能為每個客戶端提供一個定製的API。通常，它會向移動客戶端暴露一個粗粒度的API。例如，考慮下產品詳情的場景。API閘道器可以提供一個端點（/productdetails?productid=xxx），使移動客戶端可以通過一個請求獲取所有的產品詳情。API閘道器通過呼叫各個服務（產品資訊、推薦、評論等等）併合並結果來處理請求。

3、API的優缺點

使用API閘道器的最大優點是，它封裝了應用程式的內部結構。客戶端只需要同閘道器互動，而不必呼叫特定的服務。API閘道器為每一類客戶端提供了特定的API。這減少了客戶端與應用程式間的互動次數，還簡化了客戶端程式碼。
API閘道器也有一些不足，它增加了一個我們必須開發、部署和維護的高可用元件。為了暴露每個微服務的端點，開發人員必須更新API閘道器。API閘道器的更新過程要儘可能地簡單，這很重要。否則，為了更新閘道器，開發人員將不得不排隊等待。不過，雖然有這些不足，但對於大多數現實世界的應用程式而言，使用API閘道器是合理的。

4、服務呼叫

基於微服務的應用程式是一個分散式系統，必須使用一種程序間通訊機制。有兩種型別的程序間通訊機制可供選擇。一種是使用非同步的、基於訊息傳遞的機制。有些實現使用諸如JMS或AMQP那樣的訊息代理，而其它的實現則沒有代理，服務間直接通訊。另一種程序間通訊型別是諸如HTTP或Thrift那樣的同步機制。通常，一個系統會同時使用非同步和同步兩種型別。它甚至還可能使用同一型別的多種實現。總之，API閘道器需要支援多種通訊機制。

5、服務發現

API閘道器需要知道它與之通訊的每個微服務的位置（IP地址和埠）。在傳統的應用程式中，或許可以硬連線這個位置，但在現代的、基於雲的微服務應用程式中，這並不是一個容易解決的問題。基礎設施服務（如訊息代理）通常會有一個靜態位置，可以通過OS環境變數指定。但是，確定一個應用程式服務的位置沒有這麼簡單。應用程式服務的位置是動態分配的。而且，單個服務的一組例項也會隨著自動擴充套件或升級而動態變化。總之，像系統中的其它服務客戶端一樣，API閘道器需要使用系統的服務發現機制，可以是伺服器端發現，也可以是客戶端發現。

6、問題記錄

在實現API閘道器時，還有一個問題需要處理，就是區域性失敗的問題。該問題在所有的分散式系統中都會出現，無論什麼時候，當一個服務呼叫另一個響應慢或不可用的服務，就會出現這個問題。API閘道器永遠不能因為無限期地等待下游服務而阻塞。不過，如何處理失敗取決於特定的場景以及哪個服務失敗。例如，在產品詳情場景下，如果推薦服務無響應，那麼API閘道器應該向客戶端返回產品詳情的其它內容，因為它們對使用者依然有用。推薦內容可以為空，也可以，比如說，用一個固定的TOP 10列表取代。不過，如果產品資訊服務無響應，那麼API閘道器應該向客戶端返回一個錯誤資訊。
如果快取資料可用，那麼API閘道器還可以返回快取資料。例如，由於產品價格不經常變化，所以如果價格服務不可用，API閘道器可以返回快取的價格資料。資料可以由API閘道器自己快取，也可以儲存在像Redis或Memcached那樣的外部快取中。通過返回預設資料或者快取資料，API閘道器可以確保系統故障不影響使用者的體驗。

7、API目錄管理

當需要編輯某個API的定義時，如果該API已經發布，對定義的修改不會對線上產生影響，定義修改後需要再次釋出才能把修改後的定義同步到線上環境。
當想要刪除某個API，如果該API已經發布，則不允許直接刪除API定義，需要先將API下線，然後刪除。
提供了複製定義的功能。可以從測試環境/線上環境複製線上的定義覆蓋當前的最新定義，然後重新點選編輯進行修改。