談API網關的背景、架構以及落地方案

Chris Richardson曾經在他的博客上詳細介紹過API網關，包括API網關的背景、解決方案以及案例。對於大多數基於微服務的應用程序而言，API網關都應該是系統的入口，它會負責服務請求路由、組合及協議轉換。如Chris所言，在微服務的應用程序中，客戶端和微服務之間的交互，有如下幾個挑戰：

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

2.不同的客戶端需要不同的數據，不同類型客戶端的網絡性能不同。

3.服務的劃分可能會隨時間而變化，因此需要對客戶端隱藏細節。

那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開通

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