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
(圖片來源:The API Economy Disruption and the Business of APIs,Nordic APIs)緩存
2.API服務平臺多樣化安全
最初的API主要針對不一樣單體應用的網絡單元之間信息交互, 現已演變到服務間快速通信。隨着人工智能EI, IOT的不斷演進, 依賴API的平臺不斷更新, 如Web, Mobile, 終端等,將來將會出現更多的服務體系。微信
3.逐步替換原有企業的服務模式,API即商品網絡
賣計算, 賣軟件, 賣能力, 最終的企業的銷售模式會逐步轉變,能力變現, 釋放數據價值,依託不一樣的API管理平臺創造新的盈利。
API網關爲什麼誕生
隨着API的總體趨勢發展, 每一個歷史時代都面臨着不一樣的挑戰, 架構也隨之變化, 能夠參考一下:
(圖片來源: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使用的稱之爲管理平面, 可在必定程度上對業務請求跟管理請求進行有效隔離。
先談一下數據平面
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的集羣性能會成爲很大的瓶頸。
咱們從新設計了一套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。 域名存儲從最後一個「.」開始遍歷。 舉例: 匹配: www.test.com , 先匹配com, 匹配成功繼續遍歷test, 匹配成功遍歷www, 無www匹配失敗。 匹配: test.apig.com, 先匹配com, 匹配成功繼續遍歷apig, 匹配成功遍歷test, 無test, 遍歷*號, 匹配目標: *.apig.com URL的匹配爲前序匹配跟域名的匹配模式相反,可是遍歷算法一致。
總結
業界主流的開源API網關架構不少,可是開源軟件都有一個共同的特色: 量級,安全,運維分析相對匱乏, 真正要知足生產環境需求,還須要投入較高的研發成本。術業有專攻,找一個完善的API管理解決方案對於企業能力變現很是重要。
華爲雲API網關服務提供完整的API生命週期管理解決方案, 支持多種使用場景, 提供便捷的管理服務。讓API的上線,發佈,管理到最後售賣的流程再也不復雜,快速完成企業能力變現。 歡迎前往體驗: 華爲雲-API 網關
歡迎掃碼查看更多精彩: