淺談API網關如何承載API經濟生態鏈
全文共3770 字，預計閱讀時間： 10 分鐘
寫在前面
API經濟生態鏈已經在全球範圍覆蓋， 絕大多數企業都已經走在數字化轉型的道路上，API成為企業連接業務的核心載體， 併產生巨大的盈利空間。快速增長的API規模以及調用量，使得企業IT在架構上、模式上面臨著更多的挑戰。關於如何承載現有快速發展的API生態鏈，本文接下來介紹API網關在其中扮演的角色。
API是什麼
應用編程介面（Application Programming Interface，簡稱：API），就是軟體系統不同組成部分銜接的約定（維基百科）。舉個簡單的例子： 您每次登陸微信， 需要提供賬號信息才能訪問， 微信提供的這個認證載體就是一個API。 API已經無處不在，金融、IT、物聯網等，發展趨勢相當迅速， 無形之中貫穿著我們的生活。
縱觀這幾年的發展，API在不斷的技術迭代中形成了幾股共同的趨勢：
01
API開放數量不斷增加
毋庸置疑， 隨著企業的數據化進展，微服務改造，不同領域的API層出不窮， 早在2014年ProgrammableWeb便預測API矢量可達到100,000到200,000， 並會不斷增長。API開發數量的增加給邊緣系統帶來機會， 也隨即演變了API網關的出現。大規模的API管理系統成為核心的發展趨勢。
API發展趨勢
02
API服務平台多樣化
最初的API主要針對不同單體應用的網路單元之間信息交互， 現已演變到服務間快速通訊。隨著人工智慧EI， IOT的不斷演進， 依賴API的平台不斷更新， 如Web， Mobile， 終端等，未來將會出現更多的服務體系。
03
逐步替換原有企業的服務模式，
API即商品
賣計算， 賣軟體， 賣能力， 最終的企業的銷售模式會逐步轉變，能力變現， 釋放數據價值，依託不同的API管理平台創造新的盈利。
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）， 為此我們選擇了Nginx+openresty，主要考慮如下：
1.支持熱重啟
數據面的組件升級是一個高風險動作， 一旦出現異常就可能導致連接中斷，系統異常， 除非你的前端LB（負載均衡）能具備快速排水的能力，當然即使如此，還是可能導致正在處理的請求被強制中斷。所以數據面的熱重啟非常關鍵。
2.支持訂閱式動態路由
API路由變化相對頻繁，及時性也要求比較高， 如果採用定期同步方案， 一次性同步幾萬條的數據會拖慢你的系統， 因此增加一個訂閱式的路由服務中心非常關鍵， Openresty自研可以快速訂閱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按照Nginx集群節點計算Hash值，確保每個API都能負載到其中一個集群節點上。 假設有A， B，C三台Nginx， 如果某個API計算的一致性hash值為A節點， 當請求發送到A節點時直接從這台節點轉發，並記錄一個流控值， 當請求發送到B/C節點的時候都會轉發到A節點計算一個流控值再往後轉發。 這樣同一個API的流控請求就會全部記錄到一台Nginx上。可以藉助Nginx的單機流控能力。單機流控的演算法也是插件化的，可以採用計數，漏桶等。
當然本地流控也會帶來一定問題，當所有的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網關架構很多， Kong,，Tyk， Zuul等，開源軟體都有一個共同的特點： 量級，安全，運維分析相對匱乏， 而且真正要滿足生產環境需求，還需要投入較高的研發成本。術業有專攻，找一個完善的API管理解決方案對於企業能力變現非常重要。
華為雲API網關服務提供完整的API生命周期管理解決方案， 支持多種使用場景， 提供便捷的管理服務。讓API的上線，發布，管理到最後售賣的流程不再複雜，快速完成企業能力變現。 歡迎點擊「閱讀原文」體驗： 華為雲-API 網關
點我立即體驗
TAG:中間件小哥 |