全文共3770 字，預計閱讀時間： 10 分鐘前端
寫在前面nginx
API經濟生態鏈已經在全球範圍覆蓋， 絕大多數企業都已經走在數字化轉型的道路上，API成爲企業鏈接業務的核心載體， 併產生巨大的盈利空間。快速增加的API規模以及調用量，使得企業IT在架構上、模式上面臨着更多的挑戰。關於如何承載現有快速發展的API生態鏈，本文接下來介紹API網關在其中扮演的角色。算法
API是什麼編程
應用編程接口（Application Programming Interface，簡稱：API），就是軟件系統不一樣組成部分銜接的約定（維基百科）。舉個簡單的例子： 您每次登錄微信， 須要提供帳號信息才能訪問， 微信提供的這個認證載體就是一個API。 API已經無處不在，金融、IT、物聯網等，發展趨勢至關迅速， 無形之中貫穿着咱們的生活。後端
縱觀這幾年的發展，API在不斷的技術迭代中造成了幾股共同的趨勢：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 網關