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