原文地址：http://chuansong.me/n/465796751848
Chris Richardson曾經在他的博客上詳細介紹過API網關，包括API網關的背景、解決方案以及案例。對於大多數基於微服務的應用程序而言，API網關都應該是系統的入口，它會負責服務請求路由、組合及協議轉換。如Chris所言，在微服務的應用程序中，客戶端和微服務之間的交互，有如下幾個挑戰：
-
微服務提供的API粒度通常與客戶端的需求不同，微服務一般提供細粒度的API，也就是說客戶端需要與多個服務進行交互。
-
不同的客戶端需要不同的數據，不同類型客戶端的網絡性能不同。
-
服務的划分可能會隨時間而變化，因此需要對客戶端隱藏細節。
那API網關具體是如何解決這些問題的，在API網關的落地上，需要注意哪些地方，就這些問題，InfoQ編輯采訪了普元主任架構師王延炯，與他一起探討了API網關的來龍去脈（文末有嘉賓聯系方式，更多更深入問題，可以加他私聊）。
InfoQ：談談你所理解的API網關，以及API網關出現的背景？
王延炯：API Gateway（API GW / API 網關），顧名思義，是出現在系統邊界上的一個面向API的、串行集中式的強管控服務，這里的邊界是企業IT系統的邊界。
在微服務概念的流行之前，API GW的實體就已經誕生了，這時的主要應用場景是OpenAPI，也就是開放平台，面向的是企業外部合作伙伴，對於這個應用場景，相信接觸的人會比較多。當在微服務概念流行起來之后，API網關似乎成了在上層應用層集成的標配組件。
其實，在我所經歷過的項目中，API GW的定位主要有五類：
1、面向Web App
這類場景，在物理形態上類似前后端分離，此時的Web App已經不是全功能的Web App，而是根據場景定制、場景化的App。
2、面向Mobile App
這類場景，移動App是后端Service的使用者，此時的API GW還需要承擔一部分MDM（此處是指移動設備管理，不是主數據管理）的職能。
3、面向Partner OpenAPI
這類場景，主要為了滿足業務形態對外開放，與企業外部合作伙伴建立生態圈，此時的API GW需要增加配額、流控、令牌等一系列安全管控功能。
4、面向Partner ExternalAPI
這類場景，業界提的比較少，很多時候系統的建設，都是為了滿足企業自身業務的需要，實現對企業自有業務的映射。當互聯網形態逐漸影響傳統企業時，很多系統都會為了導入流量或者內容，依賴外部合作伙伴的能力，一些典型的例子就是使用「合作方賬號登錄」、「使用第三方支付平台支付」等等，這些對於企業內部來說，都是一些外部能力。此時的API GW就需要在邊界上，為企業內部Service 統一調用外部的API做統一的認證、（多租戶形式的）授權、以及訪問控制。
5、面向IoT SmartDevice
這類場景，業界就提的更少了，但在傳統企業，尤其是工業企業，傳感器、物理設備從工業控制協議向IP轉換，導致具備信息處理能力的「智能產品」在被客戶激活使用直至報廢過程中，信息的傳輸不能再基於VPN或者企業內部專線，導致物理鏈路上會存在一部分公網鏈路。此時的API GW所需要滿足的，就是不是前三種單向的由外而內的數據流，也不是第四種由內而外的數據流，「內外兼修」的雙向數據流，對於企業的系統來說終端設備很多情況下都不是直連網關，而是進過一個「客戶側」的集中網關在和企業的接入網關進行通信。
InfoQ：在一個微服務架構中，API網關會在架構中的那一層？他主要的作用是什么？
王延炯：接續前一個話題，我把API GW分為了五類，對於當前的企業而言被關注的是前三類或者前四類API GW。顯然，它們都會出現在企業系統的邊界上，也就是和企業外部交互的「獨木橋」上。
它們除了保證數據的交換之外，還需要實現對接入客戶端的身份認證、防報文重放與防數據篡改、功能調用的業務鑒權、響應數據的脫敏、流量與並發控制，甚至基於API調用的計量或者計費。
InfoQ：你有研究過Netflix的API網關嗎？在實現方式上，你覺得他們的方式有什么巧妙之處嗎？
王延炯：Netflix 的API GW，主要是指Zuul, Netflix 將他們用於自己的三大場景： Website Service, API Service, Streaming Service。其中前兩個定位與我的前兩個分類：Web App, Mobile App比較類似，第三個Streaming Service主要是netflix的核心視頻業務所形成的特有形態。
Netflix在Zuul的實現上，主要特色是：Filter的PRE ROUTING POST ERROR（PRPE 模型），以及采用Groovy腳本的Filter實現機制、采用Cassandra作為filter repository的機制。
Filter 以及 Filter的PRPE模型，是典型的「前正后反模型」的實現，為集成的標准化做好了框架層面的鋪墊。
Netflix其實並沒有對API GW進行深入的功能實現（或者說面相業務友好的相關功能），整體上它只提供了一個技術框架、和一些標准的filter實例實現，相信了解過filter chain原理的分布式中間件工程師也能搭出這樣的框架。這么做的原因，我認為很大原因是API GW所扮演的角色是一個業務平台，而非技術平台，將行業特征很強的業務部分開源，對於受眾意義也不是特別大。另外，除了Netflix Zuul，在商業產品上還有apigee公司所提供的方案，在輕量級開源實現上還有基於Nginx的kong，kong其實提供了19個插件式的功能實現，涵蓋的面主要在於安全、監控等領域，但缺少對報文轉換的能力（為什么缺 也很顯而易見——避免產生業務場景的耦合，更通用）。
另外，還有基於TCP協議的GW，比如攜程無線應用的后端實現有HTTP和TCP兩種，有興趣的讀者也可以深入關注。
InfoQ：在API網關的設計上，需要包含哪些要素？
王延炯：從三個方面說吧，API網關本身以及API網關客戶端，還有配套的自助服務平台。具體如下：
API GW本身
NIO接入，異步接出
流控與屏蔽
秘鑰交換
客戶端認證與報文加解密
業務路由框架
報文轉換
HTTP DNS/ Direct IP
API GW 客戶端 SDK / Library
基本通信
秘鑰交換與Cache
身份認證與報文加解密
配套的在線自助服務平台
代碼生成
文檔生成
沙盒調測
InfoQ：在API網關的落地上，你有可行的方案嗎？在API網關的落地上，難點是什么？
王延炯：在我所服務過的阿里系、非電商互聯網公司里，內部的分布式服務調用采用的是Dubbo，但移動應用是iOS和Android，基本上沒有PC Web端的客戶端，在這種條件下，API GW所承擔的一個重要角色就是報文轉換，並且是跨語言、跨運行平台的報文轉換。報文就是數據，在跨平台、跨語言的條件下，對於數據的描述——元數據——也就是類定義，對於API GW的系統性挑戰是巨大的：傳輸時，報文內不能傳輸類定義，跨語言的類定義轉換、生成與加載。
API GW的落地技術基本貫通沒有太大的難度，但形成最佳的實踐，有一些外圍的前置條件，比如：
后端API粒度
能和原子業務能力找到映射最好，一定要避免「萬能接口」的出現。
業務路由的實現和含報文轉換的API不停機發布
盡可能的在報文頭里面存放業務路由所需要的信息，避免對報文體進行解析。
API GW上線后，面臨的很大問題都是后端服務如何自助發布到外部，同時不能重啟網關服務，以保障業務的連續。在此過程中，如果涉及到報文格式的轉換，那對API網關實現的技術要求比較高。如果讓網關完成報文轉換，第一種方案，網關需要知道報文的具體格式（也就是報文的元數據，或者是類定義），這部分要支持熱更新。第二種方案，需要客戶端在報文內另外附加元數據，網關通過運行期加載元數據對報文進行解析在進行報文的轉換，這種方案性能不會很好。第三種方案，就是在運行期首次報文轉換的時候，根據元數據生成報文轉換代碼並加載，這種方案對技術實現要求比較高，對網關外圍平台支撐力度要求也不低。
客戶端的秘鑰管理
很多人都會把安全問題簡單的用加密算法來解決，這是一個嚴重的誤區，很多時候都存在對秘鑰進行系統性管理的短板。打個比方，加密算法就好比家里的保險箱，而秘鑰是保險箱的鑰匙，而缺乏秘鑰管理的安全方案，就好比把鑰匙放在自家的客廳茶幾上。更何況，安全方案里加解密也只是其中的一部分。
InfoQ：你認為一個設計良好的API網關應該做到什么？
王延炯：目前業界關注的API GW，主要是在前三類，下文對於API網關的設計上，側重於「面向接入」的API GW。
在API網關的設計上，僅僅有類似Zuul這樣的「面向接入」的運行期框架是遠遠不夠的，因為一個完整的、「面向接入」的API GW需要包含以下功能：
面向運行期
對客戶端實現身份認證
通信會話的秘鑰協商，報文的加密與解密
日常流控與應急屏蔽
內部響應報文的場景化裁剪
支持「前正后反模型」的集成框架
報文格式的轉換
業務路由的支撐
客戶端優先的超時機制
全局流水號的生成與應用
面向客戶端支持HTTP DNS / Direct IP
面向開發期
自助的沙盒測試環境
面向客戶端友好的 SDK / Library以及示例
能夠根據后端代碼直接生成客戶端業務代碼框架
完善的報文描述能力（元數據），支撐配置型的報文裁剪
面向運維與運營
支持面向接入方的獨立部署與快速水平擴展
面向業務場景或合作伙伴的自助API開通
對外接口性能與線上環境故障定位自助平台