淺談API網關如何承載API經濟生態鏈

08-10

淺談API網關如何承載API經濟生態鏈

1 人贊了文章

序言

? API經濟生態鏈已經在全球範圍覆蓋，絕大多數企業都已經走在數字化轉型的道路上，API成為企業連接業務的核心載體，併產生巨大的盈利空間。快速增長的API規模以及調用量，使得企業IT在架構上、模式上面臨著更多的挑戰。關於如何承載現有快速發展的API生態鏈，本文接下來介紹API網關在其中扮演的角色。

先介紹一下API

? 應用編程介面（Application Programming Interface，簡稱：API），就是軟體系統不同組成部分銜接的約定【維基百科】。簡單的例子：您每次登陸微信，需要提供賬號信息才能訪問，微信提供的這個認證載體就是一個API。 API已經無處不在，金融、IT、物聯網等，發展趨勢相當迅速，無形之中貫穿著我們的生活。

縱觀這幾年的發展，API在不斷的技術迭代中形成了幾股共同的趨勢：

API開放數量不斷增加
這點毋庸置疑，隨著企業的數據化進展，微服務改造，不同領域的API層出不窮，早在2014年ProgrammableWeb便預測API矢量可達到100,000到200,000，並會不斷增長。API開發數量的增加給邊緣系統帶來機會，也隨即演變了API網關的出現。大規模的API管理系統成為核心的發展趨勢。

（圖片來源：The API Economy Disruption and the Business of APIs，Nordic APIs）

API服務平台多樣化

最初的API主要針對不同單體應用的網路單元之間信息交互，現已演變到服務間快速通訊。隨著人工智慧EI， IOT的不斷演進，依賴API的平台不斷更新，如Web， Mobile，終端等，未來將會出現更多的服務體系。

逐步替換原有企業的服務模式，API即商品

賣計算，賣軟體，賣能力，最終的企業的銷售模式會逐步轉變，能力變現，釋放數據價值，依託不同的API管理平台創造新的盈利。

API網關為何誕生

? 隨著API的整體趨勢發展，每個歷史時代都面臨著不同的挑戰，架構也隨之變化，可以參考一下：

? 從最原始的「傳輸協議通訊」 -> 「簡單的介面集成」 -> 「消息中間件」 -> 「標準REST」，可以看到API的發展更趨向於簡潔，集成，規範化，這也促使更多的系統邊界組件不斷湧現，在承載了萬億級的API經濟的背景下， API網關應運而生。

Gartner 報告中提到：如果沒有合適的API管理工具， API經濟不可能順利開展。同時提出了對於API管理系統的生命周期定義： planning（規劃）, design（設計）， implementation（實施）， publication（發布），operation（運維）, consumption（消費）, maintenance（維護） and retirement of APIs（下架）【來源：Magic Quadrant for Full Life Cycle API Management，Gartner發表於2016-10-27】。

API網關貫穿整個流程，並提供豐富的管理特性。

高性能，可橫向擴展
高可靠，業務不中斷
插件化的API安全控制
靈活的數據編排
精細化流控
API版本管理
API數據分析
高效插件化路由演算法
安全認證，防攻擊
API訪問控制
Swagger導入導出
…

API網關的核心設計實踐

? 提供一個可參考的高性能API網關架構，在設計API網關的時候把整體分為兩個平面， API Consumer使用的稱之為數據平面， API Provider使用的稱之為管理平面，可在一定程度上對業務請求跟管理請求進行有效隔離。

先談一下數據平面

? API網關最核心設計理念：保證數據面的業務不中斷。由於對接API網關的服務是多樣的，客戶API跟應用的設計不可控，你很難能要求每個接入的服務以及客戶端都具備容錯能力，特別是一些比較傳統的業務。這就要求網關盡量保證能正常處理每個請求，且滿足較高的SLA（Service-Level Agreement），現在業界的API網關分為幾種：直接使用雲服務， Nginx系列， Golang系列， Java系列等，選擇比較多，如果想要自構建，推薦使用Nginx系，主要考慮如下：

支持熱重啟
? 數據面的組件升級是一個高風險動作，一旦出現異常就可能導致連接中斷，系統異常，除非你的前端LB（負載均衡）能具備快速排水的能力，當然即使如此，還是可能導致正在處理的請求被強制中斷。所以數據面的熱重啟非常關鍵。
支持訂閱式動態路由
API路由變化相對頻繁，及時性也要求比較高，如果採用定期同步方案，一次性同步幾萬條的數據會拖慢你的系統，因此增加一個訂閱式的路由服務中心非常關鍵，我們可以快速訂閱ETCD中的路由數據並實時生效。而且只拿增量數據性能壓力不會太大。
支持插件化管理
? Nginx在插件方面提供了豐富的生態。不同的API，不同的用戶所需要的處理流程不完全一致，如果每個請求過來都按照相同流程處理，必定帶來相關的冗餘操作。插件化管理可以在一定程度上提升性能，還能保障在升級過程中能快速添加處理鏈。
高性能的轉發能力
? API網關一般工作在多後端API反向代理模式，很多自研的API網關在性能上容易出現瓶頸，因此nginx優異的性能和高效的流量吞吐是其核心競爭力。
無狀態可橫向擴展：
? API網關承載的是整個系統所有請求的集合，需要根據業務規模進行彈性伸縮，採用服務中心配合Nginx配置管理可以快速增刪已有的集群，並同步到LVS，實現快速的橫向擴展能力。

再說一下管理面

? 相對於數據面，管理面的約束就沒有那麼明顯了，管理面考慮更多應該在於數據的存儲跟展示能力。一開始就定義好API的規範至關重要， Swagger作為現在最為主流的API描述模式，擁有非常完整的生態，AWS的整個API網關模型就是參考Swagger來構建的。

核心架構實現

API網關的相關實現，我們今天就流控和路由遍歷進行說明，其他相關的核心設計後續的文章中會陸續提供。

精細化秒級流控

? 分鐘級以上的流控，相對來說都比較好處理，但是提升到秒級流控，對於系統的性能跟處理能力就是一個很大的挑戰。網上的流控方案很多，同步的，非同步的各有優勢，但是都會遇到共同的問題：性能與準確度。

以下是一種最為常見的流控方案（集群流控），使用Redis共享存儲記錄所有的流控請求並實時訪問，該架構存在一個很明顯的問題：當集群數量跟請求量很大的時候，Redis的集群性能會成為很大的瓶頸。

? 我們重新設計了一套API流控架構，混合使用多種流控方案，按照業務需求自動調整。這裡我們拆分為本地流控和集群流控。對於流量敏感的應用，會要求流控精度越精確，計算及時性高，時間維度低（秒級），採用本地流控。對於時間周期長，訪問頻率較低的API我們採用集群流控，降低對共享存儲的操作頻率。

註：上圖展示具體流控架構，與API網關的集成請參考本章節開頭的API網關架構全景。

本地流控

即單機流控，適用流量敏感型業務。 API按照API-Core集群節點計算Hash值，確保每個API都能負載到其中一個集群節點上。假設有A， B，C三台API-Core，如果某個API計算的一致性hash值為A節點，當請求發送到A節點時直接從這台節點轉發，並記錄一個流控值，當請求發送到B/C節點的時候都會轉發到A節點計算一個流控值再往後轉發。這樣同一個API的流控請求就會全部記錄到一台API-Core上。可以藉助API-Core的單機流控能力。單機流控的演算法也是插件化的，可以採用計數，漏桶等。

? 當然本地流控也會帶來一定問題，當所有的API都負載到一個節點上，如果一個API的訪問量特別大，那就可能導致負載不太均勻。還有就是如果流控時間記錄很長，比如12次/天，計數時間周期太長了也不太適合本地流控。

集群流控

? 集群流控適用計數周期長，流控精度要求不高的業務。跟本地流控相輔相成，按照不同的業務選擇不同的流控，相關的流控處理流程跟上述的本地流控基本相同，但是會在本地會先緩存一段時間的流控數據再統一上報流控中心。

基於樹形結構的路由遍歷演算法

? API網關數據面的主要流程包含路由匹配演算法，路由的所有數據都會緩存在ETCD中，為提升數據面性能，存儲的結構至關重要。在存儲過程中我們分為兩部分：域名樹， URI樹

? 從第一個樹形結構中我們可以遍歷到有以下幾個域名： www.apig.com, test.com, .apig.com, .com。域名存儲從最後一個「.」開始遍歷。舉例：

? 匹配： http://www.test.com ，先匹配com，匹配成功繼續遍歷test，匹配成功遍歷www，無www匹配失敗。

? 匹配： test.apig.com, 先匹配com，匹配成功繼續遍歷apig，匹配成功遍歷test，無test，遍歷號，匹配目標： .http://apig.com

? URL的匹配為前序匹配跟域名的匹配模式相反，但是遍歷演算法一致。

總結

? 業界主流的開源API網關架構很多，但是開源軟體都有一個共同的特點：量級，安全，運維分析相對匱乏，真正要滿足生產環境需求，還需要投入較高的研發成本。術業有專攻，找一個完善的API管理解決方案對於企業能力變現非常重要。

? 華為雲API網關服務提供完整的API生命周期管理解決方案，支持多種使用場景，提供便捷的管理服務。讓API的上線，發布，管理到最後售賣的流程不再複雜，快速完成企業能力變現。

歡迎關注我的公眾號：中間件小哥（zhongjianjianxiaoge）