摘要：關于如何承載現有快速發展的API生态鍊，本文接下來介紹API網關在其中扮演的角色。
API經濟生态鍊已經在全球範圍覆寫， 絕大多數企業都已經走在數字化轉型的道路上，API成為企業連接配接業務的核心載體， 并産生巨大的盈利空間。快速增長的API規模以及調用量，使得企業IT在架構上、模式上面臨着更多的挑戰。關于如何承載現有快速發展的API生态鍊，本文接下來介紹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 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 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 網關
歡迎持續關注華為雲DevCloud，搜尋公衆号：HWDevCloud，擷取更多幹貨資訊！
點選關注，第一時間了解華為雲新鮮技術~