參考鏈接：

http://www.infoq.com/cn/news/2016/07/API-background-architecture-floo

APIGW除了要保證數據的交換外，還要實現對接入客戶端的身份認證、防報文重放與防數據篡改、功能調用的業務鑒權、響應數據的脫敏、流量與並發控制，甚至基於API調用的計量或者計費。

一、普元大咖

1、應用場景分類

1.1、面向Web App

這類場景，在物理形態上類似前後端分離，此時的Web App已經不是全功能的Web App，而是根據場景定制、場景化的App。

1.2、面向Mobile App

這類場景，移動App是後端Service的使用者，此時的API GW還需要承擔一部分MDM（此處是指移動設備管理，不是主數據管理）的職能。

1.3、面向Partner OpenAPI

這類場景，主要為了滿足業務形態對外開放，與企業外部合作夥伴建立生態圈，此時的API GW需要增加配額、流控、令牌等一系列安全管控功能。

1.4、面向Partner ExternalAPI

這類場景，業界提的比較少，很多時候系統的建設，都是為了滿足企業自身業務的需要，實現對企業自有業務的映射。當互聯網形態逐漸影響傳統企業時，很多系統都會為了導入流量或者內容，依賴外部合作夥伴的能力，一些典型的例子就是使用「合作方賬號登錄」、「使用第三方支付平臺支付」等等，這些對於企業內部來說，都是一些外部能力。此時的API GW就需要在邊界上，為企業內部Service 統一調用外部的API做統一的認證、（多租戶形式的）授權、以及訪問控制。

1.5、面向IoT SmartDevice

這類場景，業界就提的更少了，但在傳統企業，尤其是工業企業，傳感器、物理設備從工業控制協議向IP轉換，導致具備信息處理能力的「智能產品」在被客戶激活使用直至報廢過程中，信息的傳輸不能再基於VPN或者企業內部專線，導致物理鏈路上會存在一部分公網鏈路。此時的API GW所需要滿足的，就是不是前三種單向的由外而內的數據流，也不是第四種由內而外的數據流，「內外兼修」的雙向數據流，對於企業的系統來說終端設備很多情況下都不是直連網關，而是進過一個「客戶側」的集中網關在和企業的接入網關進行通信。

2、API網關的能力

API GW本身

• NIO接入，異步接出
• 流控與屏蔽
• 秘鑰交換
• 客戶端認證與報文加解密
• 業務路由框架
• 報文轉換
• HTTP DNS/ Direct IP

API GW 客戶端 SDK / Library

• 基本通信
• 秘鑰交換與Cache
• 身份認證與報文加解密

配套的在線自助服務平臺

• 代碼生成
• 文檔生成
• 沙盒調測

3、最佳實踐

後端API粒度：能和原子業務能力找到映射最好，一定要避免「萬能接口」的出現。

業務路由的實現和含報文轉換的API支持不停機發布，在報文頭裏面存放業務路由所需要的信息，避免對報文體進行解析。

API GW上線後，面臨的很大問題都是後端服務如何自助發布到外部，同時不能重啟網關服務，以保障業務的連續。在此過程中，如果涉及到報文格式的轉換，那對API網關實現的技術要求比較高。如果讓網關完成報文轉換，

• 第一種方案，網關需要知道報文的具體格式（也就是報文的元數據，或者是類定義），這部分要支持熱更新。
• 第二種方案，需要客戶端在報文內另外附加元數據，網關通過運行期加載元數據對報文進行解析在進行報文的轉換，這種方案性能不會很好。
• 第三種方案，就是在運行期首次報文轉換的時候，根據元數據生成報文轉換代碼並加載，這種方案對技術實現要求比較高，對網關外圍平臺支撐力度要求也不低。

客戶端的秘鑰管理

很多人都會把安全問題簡單的用加密算法來解決，這是一個嚴重的誤區，很多時候都存在對秘鑰進行系統性管理的短板。

打個比方，加密算法就好比家裏的保險箱，而秘鑰是保險箱的鑰匙，而缺乏秘鑰管理的安全方案，就好比把鑰匙放在自家的客廳茶幾上。更何況，安全方案裏加解密也只是其中的一部分。

4、一個好的API網關

在API網關的設計上，僅僅有類似Zuul這樣的「面向接入」的運行期框架是遠遠不夠的，因為一個完整的、「面向接入」的API GW需要包含以下功能：

面向運行期

• 對客戶端實現身份認證
• 通信會話的秘鑰協商，報文的加密與解密
• 日常流控與應急屏蔽
• 內部響應報文的場景化裁剪
• 支持「前正後反模型」的集成框架
• 報文格式的轉換
• 業務路由的支撐
• 客戶端優先的超時機制
• 全局流水號的生成與應用
• 面向客戶端支持HTTP DNS / Direct IP

面向開發期

• 自助的沙盒測試環境
• 面向客戶端友好的 SDK / Library以及示例
• 能夠根據後端代碼直接生成客戶端業務代碼框架
• 完善的報文描述能力（元數據），支撐配置型的報文裁剪

面向運維與運營

• 支持面向接入方的獨立部署與快速水平擴展
• 面向業務場景或合作夥伴的自助API開通
• 對外接口性能與線上環境故障定位自助平臺

二、其他觀點

1、API網關負責服務請求路由、組合及協議轉換。

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

API網關還能為每個客戶端提供一個定制的API。通常，它會向移動客戶端暴露一個粗粒度的API。

例如，考慮下產品詳情的場景。API網關可以提供一個端點（/productdetails?productid=xxx），使移動客戶端可以通過一個請求獲取所有的產品詳情。API網關通過調用各個服務（產品信息、推薦、評論等等）並合並結果來處理請求。

2、API的優缺點

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

3、服務調用

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

4、服務發現

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

5、問題記錄

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

6、API目錄管理

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

API網關之業界漫談