原文地址：http://chuansong.me/n/465796751848

Chris Richardson曾經(jīng)在他的博客上詳細介紹過API網(wǎng)關(guān)，包括API網(wǎng)關(guān)的背景、解決方案以及案例。對于大多數(shù)基于微服務(wù)的應(yīng)用程序而言，API網(wǎng)關(guān)都應(yīng)該是系統(tǒng)的入口，它會負責(zé)服務(wù)請求路由、組合及協(xié)議轉(zhuǎn)換。如Chris所言，在微服務(wù)的應(yīng)用程序中，客戶端和微服務(wù)之間的交互，有如下幾個挑戰(zhàn)：

微服務(wù)提供的API粒度通常與客戶端的需求不同，微服務(wù)一般提供細粒度的API，也就是說客戶端需要與多個服務(wù)進行交互。

不同的客戶端需要不同的數(shù)據(jù)，不同類型客戶端的網(wǎng)絡(luò)性能不同。

服務(wù)的劃分可能會隨時間而變化，因此需要對客戶端隱藏細節(jié)。

那API網(wǎng)關(guān)具體是如何解決這些問題的，在API網(wǎng)關(guān)的落地上，需要注意哪些地方，就這些問題，InfoQ編輯采訪了普元主任架構(gòu)師王延炯，與他一起探討了API網(wǎng)關(guān)的來龍去脈（文末有嘉賓聯(lián)系方式，更多更深入問題，可以加他私聊）。

InfoQ：談?wù)勀闼斫獾腁PI網(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的、串行集中式的強管控服務(wù)，這里的邊界是企業(yè)IT系統(tǒng)的邊界。

在微服務(wù)概念的流行之前，API GW的實體就已經(jīng)誕生了，這時的主要應(yīng)用場景是OpenAPI，也就是開放平臺，面向的是企業(yè)外部合作伙伴，對于這個應(yīng)用場景，相信接觸的人會比較多。當(dāng)在微服務(wù)概念流行起來之后，API網(wǎng)關(guān)似乎成了在上層應(yīng)用層集成的標(biāo)配組件。

其實，在我所經(jīng)歷過的項目中，API GW的定位主要有五類：

1、面向Web App

這類場景，在物理形態(tài)上類似前后端分離，此時的Web App已經(jīng)不是全功能的Web App，而是根據(jù)場景定制、場景化的App。

2、面向Mobile App

這類場景，移動App是后端Service的使用者，此時的API GW還需要承擔(dān)一部分MDM（此處是指移動設(shè)備管理，不是主數(shù)據(jù)管理）的職能。

3、面向Partner OpenAPI

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

4、面向Partner ExternalAPI

這類場景，業(yè)界提的比較少，很多時候系統(tǒng)的建設(shè)，都是為了滿足企業(yè)自身業(yè)務(wù)的需要，實現(xiàn)對企業(yè)自有業(yè)務(wù)的映射。當(dāng)互聯(lián)網(wǎng)形態(tài)逐漸影響傳統(tǒng)企業(yè)時，很多系統(tǒng)都會為了導(dǎo)入流量或者內(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)換，導(dǎo)致具備信息處理能力的「智能產(chǎn)品」在被客戶激活使用直至報廢過程中，信息的傳輸不能再基于VPN或者企業(yè)內(nèi)部專線，導(dǎo)致物理鏈路上會存在一部分公網(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：在一個微服務(wù)架構(gòu)中，API網(wǎng)關(guān)會在架構(gòu)中的那一層？他主要的作用是什么？

王延炯：接續(xù)前一個話題，我把API GW分為了五類，對于當(dāng)前的企業(yè)而言被關(guān)注的是前三類或者前四類API GW。顯然，它們都會出現(xiàn)在企業(yè)系統(tǒng)的邊界上，也就是和企業(yè)外部交互的「獨木橋」上。

它們除了保證數(shù)據(jù)的交換之外，還需要實現(xiàn)對接入客戶端的身份認證、防報文重放與防數(shù)據(jù)篡改、功能調(diào)用的業(yè)務(wù)鑒權(quán)、響應(yīng)數(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è)務(wù)所形成的特有形態(tài)。

Netflix在Zuul的實現(xiàn)上，主要特色是：Filter的PRE ROUTING POST ERROR（PRPE 模型），以及采用Groovy腳本的Filter實現(xiàn)機制、采用Cassandra作為filter repository的機制。

Filter 以及 Filter的PRPE模型，是典型的「前正后反模型」的實現(xiàn)，為集成的標(biāo)準(zhǔn)化做好了框架層面的鋪墊。

Netflix其實并沒有對API GW進行深入的功能實現(xiàn)（或者說面相業(yè)務(wù)友好的相關(guān)功能），整體上它只提供了一個技術(shù)框架、和一些標(biāo)準(zhǔn)的filter實例實現(xiàn)，相信了解過filter chain原理的分布式中間件工程師也能搭出這樣的框架。這么做的原因，我認為很大原因是API GW所扮演的角色是一個業(yè)務(wù)平臺，而非技術(shù)平臺，將行業(yè)特征很強的業(yè)務(wù)部分開源，對于受眾意義也不是特別大。另外，除了Netflix Zuul，在商業(yè)產(chǎn)品上還有apigee公司所提供的方案，在輕量級開源實現(xiàn)上還有基于Nginx的kong，kong其實提供了19個插件式的功能實現(xiàn)，涵蓋的面主要在于安全、監(jiān)控等領(lǐng)域，但缺少對報文轉(zhuǎn)換的能力（為什么缺 也很顯而易見——避免產(chǎn)生業(yè)務(wù)場景的耦合，更通用）。

另外，還有基于TCP協(xié)議的GW，比如攜程無線應(yīng)用的后端實現(xiàn)有HTTP和TCP兩種，有興趣的讀者也可以深入關(guān)注。

InfoQ：在API網(wǎng)關(guān)的設(shè)計上，需要包含哪些要素？

王延炯：從三個方面說吧，API網(wǎng)關(guān)本身以及API網(wǎng)關(guān)客戶端，還有配套的自助服務(wù)平臺。具體如下：

API GW本身

• NIO接入，異步接出

• 流控與屏蔽

• 秘鑰交換

• 客戶端認證與報文加解密

• 業(yè)務(wù)路由框架

• 報文轉(zhuǎn)換

• HTTP DNS/ Direct IP

API GW 客戶端 SDK / Library

• 基本通信

• 秘鑰交換與Cache

• 身份認證與報文加解密

配套的在線自助服務(wù)平臺

• 代碼生成

• 文檔生成

• 沙盒調(diào)測

InfoQ：在API網(wǎng)關(guān)的落地上，你有可行的方案嗎？在API網(wǎng)關(guān)的落地上，難點是什么？

王延炯：在我所服務(wù)過的阿里系、非電商互聯(lián)網(wǎng)公司里，內(nèi)部的分布式服務(wù)調(diào)用采用的是Dubbo，但移動應(yīng)用是iOS和Android，基本上沒有PC Web端的客戶端，在這種條件下，API GW所承擔(dān)的一個重要角色就是報文轉(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è)務(wù)能力找到映射最好，一定要避免「萬能接口」的出現(xiàn)。

業(yè)務(wù)路由的實現(xiàn)和含報文轉(zhuǎn)換的API不停機發(fā)布

盡可能的在報文頭里面存放業(yè)務(wù)路由所需要的信息，避免對報文體進行解析。

API GW上線后，面臨的很大問題都是后端服務(wù)如何自助發(fā)布到外部，同時不能重啟網(wǎng)關(guān)服務(wù)，以保障業(yè)務(wù)的連續(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īng)該做到什么？

王延炯：目前業(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é)商，報文的加密與解密

• 日常流控與應(yīng)急屏蔽

• 內(nèi)部響應(yīng)報文的場景化裁剪

• 支持「前正后反模型」的集成框架

• 報文格式的轉(zhuǎn)換

• 業(yè)務(wù)路由的支撐

• 客戶端優(yōu)先的超時機制

• 全局流水號的生成與應(yīng)用

• 面向客戶端支持HTTP DNS / Direct IP

面向開發(fā)期

• 自助的沙盒測試環(huán)境

• 面向客戶端友好的 SDK / Library以及示例

• 能夠根據(jù)后端代碼直接生成客戶端業(yè)務(wù)代碼框架

• 完善的報文描述能力（元數(shù)據(jù)），支撐配置型的報文裁剪

面向運維與運營

• 支持面向接入方的獨立部署與快速水平擴展

• 面向業(yè)務(wù)場景或合作伙伴的自助API開通

• 對外接口性能與線上環(huán)境故障定位自助平臺

?

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/6544656.html

總結(jié)

以上是生活随笔為你收集整理的谈API网关的背景、架构以及落地方案--转的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。