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

序言

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

 

API是什麼nginx

 應用編程接口(Application Programming Interface,簡稱:API),就是軟件系統不一樣組成部分銜接的約定【維基百科】。簡單的例子: 您每次登錄微信, 須要提供帳號信息才能訪問, 微信提供的這個認證載體就是一個API。 API已經無處不在,金融、IT、物聯網等,發展趨勢至關迅速, 無形之中貫穿着咱們的生活。算法

縱觀這幾年的發展,API在不斷的技術迭代中造成了幾股共同的趨勢:編程

 

1.API開放數量不斷增長後端

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

               growth.png

          (圖片來源:The API Economy Disruption and the Business of APIs,Nordic APIs)緩存

      

2.API服務平臺多樣化安全

最初的API主要針對不一樣單體應用的網絡單元之間信息交互, 現已演變到服務間快速通信。隨着人工智能EI, IOT的不斷演進, 依賴API的平臺不斷更新, 如Web, Mobile, 終端等,將來將會出現更多的服務體系。微信

               provider.png

               

3.逐步替換原有企業的服務模式,API即商品網絡

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

 

 

 API網關爲什麼誕生

隨着API的總體趨勢發展, 每一個歷史時代都面臨着不一樣的挑戰, 架構也隨之變化, 能夠參考一下:

history.PNG

 (圖片來源:API economy From systems to business services)

 

 從最原始的「傳輸協議通信」 -> 「簡單的接口集成」 -> 「消息中間件」 -> 「標準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使用的稱之爲管理平面, 可在必定程度上對業務請求跟管理請求進行有效隔離。

jiagou.PNG

 

 先談一下數據平面

 API網關最核心設計理念: 保證數據面的業務不中斷。因爲對接API網關的服務是多樣的, 客戶API跟應用的設計不可控, 你很難能要求每一個接入的服務以及客戶端都具有容錯能力, 特別是一些比較傳統的業務。 這就要求網關儘可能保證能正常處理每一個請求, 且知足較高的SLA(Service-Level Agreement),如今業界的API網關分爲幾種: 直接使用雲服務, Nginx系列, Golang系列, Java系列等, 選擇比較多,若是想要自構建, 推薦使用Nginx系,主要考慮以下:

1.支持熱重啓

 數據面的組件升級是一個高風險動做, 一旦出現異常就可能致使鏈接中斷,系統異常, 除非你的前端LB(負載均衡)能具有快速排水的能力,固然即便如此,仍是可能致使正在處理的請求被強制中斷。因此數據面的熱重啓很是關鍵。

 

2.支持訂閱式動態路由

 API路由變化相對頻繁,及時性也要求比較高, 若是採用按期同步方案, 一次性同步幾萬條的數據會拖慢你的系統, 所以增長一個訂閱式的路由服務中心很是關鍵, 咱們能夠快速訂閱ETCD中的路由數據並實時生效。並且只拿增量數據性能壓力不會太大。

 

3.支持插件化管理

Nginx在插件方面提供了豐富的生態。不一樣的API,不一樣的用戶所須要的處理流程不徹底一致, 若是每一個請求過來都按照相同流程處理,一定帶來相關的冗餘操做。 插件化管理能夠在必定程度上提高性能,還能保障在升級過程當中能快速添加處理鏈。

 

4.高性能的轉發能力

API網關通常工做在多後端API反向代理模式,不少自研的API網關在性能上容易出現瓶頸,所以nginx優異的性能和高效的流量吞吐是其核心競爭力。

 

5.無狀態可橫向擴展

API網關承載的是整個系統全部請求的集合,須要根據業務規模進行彈性伸縮,採用服務中心配合Nginx配置管理能夠快速增刪已有的集羣,並同步到LVS,實現快速的橫向擴展能力。

 

再說一下管理面

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


核心架構實踐

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

 

精細化秒級流控

 分鐘級以上的流控,相對來講都比較好處理, 可是提高到秒級流控,對於系統的性能跟處理能力就是一個很大的挑戰。網上的流控方案不少, 同步的,異步的各有優點, 可是都會遇到共同的問題: 性能與準確度。

 

如下是一種最爲常見的流控方案(集羣流控), 使用Redis共享存儲記錄全部的流控請求並實時訪問, 該架構存在一個很明顯的問題:當集羣數量跟請求量很大的時候,Redis的集羣性能會成爲很大的瓶頸。

liukong1.PNG

 

咱們從新設計了一套API流控架構, 混合使用多種流控方案, 按照業務需求自動調整。這裏咱們拆分爲本地流控和集羣流控。 對於流量敏感的應用,會要求流控精度越精確,計算及時性高,時間維度低(秒級), 採用本地流控。對於時間週期長, 訪問頻率較低的API咱們採用集羣流控, 下降對共享存儲的操做頻率。

liukong2.PNG

注:上圖展現具體流控架構,與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樹

shu.PNG

 

 從第一個樹形結構中咱們能夠遍歷到有如下幾個域名: www.apig.com, test.com, *.apig.com, *.com。 域名存儲從最後一個「.」開始遍歷。 舉例:  匹配: www.test.com , 先匹配com, 匹配成功繼續遍歷test, 匹配成功遍歷www, 無www匹配失敗。  匹配: test.apig.com, 先匹配com, 匹配成功繼續遍歷apig, 匹配成功遍歷test, 無test, 遍歷*號, 匹配目標: *.apig.com   URL的匹配爲前序匹配跟域名的匹配模式相反,可是遍歷算法一致。

 

總結

業界主流的開源API網關架構不少,可是開源軟件都有一個共同的特色: 量級,安全,運維分析相對匱乏, 真正要知足生產環境需求,還須要投入較高的研發成本。術業有專攻,找一個完善的API管理解決方案對於企業能力變現很是重要。

 華爲雲API網關服務提供完整的API生命週期管理解決方案, 支持多種使用場景, 提供便捷的管理服務。讓API的上線,發佈,管理到最後售賣的流程再也不復雜,快速完成企業能力變現。 歡迎前往體驗: 華爲雲-API 網關

apig.PNG

 

    歡迎掃碼查看更多精彩:

中間件小哥.jpg

相關文章
相關標籤/搜索