API是什麼
應用編程接口（Application Programming Interface，簡稱：API），就是軟件系統不同組成部分銜接的約定【維基百科】。簡單的例子： 您每次登陸微信， 需要提供賬號信息才能訪問， 微信提供的這個認證載體就是一個API。 API已經無處不在，金融、IT、物聯網等，發展趨勢相當迅速， 無形之中貫穿着我們的生活。
縱觀這幾年的發展，API在不斷的技術迭代中形成了幾股共同的趨勢：
1.API開放數量不斷增加
毋庸置疑， 隨着企業的數據化進展，微服務改造，不同領域的API層出不窮， 早在2014年ProgrammableWeb便預測API矢量可達到100,000到200,000， 並會不斷增長。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 網關
