序言
? API經(jīng)濟(jì)生態(tài)鏈已經(jīng)在全球范圍覆蓋， 絕大多數(shù)企業(yè)都已經(jīng)走在數(shù)字化轉(zhuǎn)型的道路上，API成為企業(yè)連接業(yè)務(wù)的核心載體爪喘， 并產(chǎn)生巨大的盈利空間【腊危快速增長的API規(guī)模以及調(diào)用量秉剑，使得企業(yè)IT在架構(gòu)上、模式上面臨著更多的挑戰(zhàn)稠诲。關(guān)于如何承載現(xiàn)有快速發(fā)展的API生態(tài)鏈侦鹏，本文接下來介紹API網(wǎng)關(guān)在其中扮演的角色。
先介紹一下API
? 應(yīng)用編程接口（Application Programming Interface臀叙，簡稱：API）略水，就是軟件系統(tǒng)不同組成部分銜接的約定【維基百科】。簡單的例子： 您每次登陸微信劝萤， 需要提供賬號信息才能訪問渊涝， 微信提供的這個認(rèn)證載體就是一個API。 API已經(jīng)無處不在床嫌，金融跨释、IT、物聯(lián)網(wǎng)等厌处，發(fā)展趨勢相當(dāng)迅速鳖谈， 無形之中貫穿著我們的生活。
縱觀這幾年的發(fā)展阔涉，API在不斷的技術(shù)迭代中形成了幾股共同的趨勢：
-
API開放數(shù)量不斷增加
這點毋庸置疑蚯姆， 隨著企業(yè)的數(shù)據(jù)化進(jìn)展，微服務(wù)改造洒敏，不同領(lǐng)域的API層出不窮龄恋， 早在2014年P(guān)rogrammableWeb便預(yù)測API矢量可達(dá)到100,000到200,000， 并會不斷增長凶伙。API開發(fā)數(shù)量的增加給邊緣系統(tǒng)帶來機(jī)會郭毕， 也隨即演變了API網(wǎng)關(guān)的出現(xiàn)。大規(guī)模的API管理系統(tǒng)成為核心的發(fā)展趨勢函荣。圖片來源：The API Economy Disruption and the Business of APIs涌矢，Nordic APIs -
API服務(wù)平臺多樣化
最初的API主要針對不同單體應(yīng)用的網(wǎng)絡(luò)單元之間信息交互肺孵， 現(xiàn)已演變到服務(wù)間快速通訊孙援。隨著人工智能EI检碗， IOT的不斷演進(jìn)， 依賴API的平臺不斷更新金拒， 如Web兽肤， Mobile套腹， 終端等，未來將會出現(xiàn)更多的服務(wù)體系资铡。
多樣化平臺 -
逐步替換原有企業(yè)的服務(wù)模式电禀，API即商品
賣計算， 賣軟件笤休， 賣能力尖飞， 最終的企業(yè)的銷售模式會逐步轉(zhuǎn)變，能力變現(xiàn)店雅， 釋放數(shù)據(jù)價值政基，依托不同的API管理平臺創(chuàng)造新的盈利。
API網(wǎng)關(guān)為何誕生
? 隨著API的整體趨勢發(fā)展闹啦， 每個歷史時代都面臨著不同的挑戰(zhàn)腋么， 架構(gòu)也隨之變化， 可以參考一下：
? 從最原始的“傳輸協(xié)議通訊” -> “簡單的接口集成” -> “消息中間件” -> “標(biāo)準(zhǔn)REST”亥揖， 可以看到API的發(fā)展更趨向于簡潔， 集成圣勒，規(guī)范化费变， 這也促使更多的系統(tǒng)邊界組件不斷涌現(xiàn)，在承載了萬億級的API經(jīng)濟(jì)的背景下圣贸， API網(wǎng)關(guān)應(yīng)運(yùn)而生挚歧。
Gartner 報告中提到： 如果沒有合適的API管理工具， API經(jīng)濟(jì)不可能順利開展吁峻。 同時提出了對于API管理系統(tǒng)的生命周期定義： planning（規(guī)劃）, design（設(shè)計）滑负， implementation（實施）， publication（發(fā)布）用含，operation（運(yùn)維）, consumption（消費(fèi)）, maintenance（維護(hù)） and retirement of APIs（下架）【來源：Magic Quadrant for Full Life Cycle API Management矮慕，Gartner發(fā)表于2016-10-27】。
API網(wǎng)關(guān)貫穿整個流程啄骇，并提供豐富的管理特性痴鳄。
- 高性能，可橫向擴(kuò)展
- 高可靠缸夹，業(yè)務(wù)不中斷
- 插件化的API安全控制
- 靈活的數(shù)據(jù)編排
- 精細(xì)化流控
- API版本管理
- API數(shù)據(jù)分析
- 高效插件化路由算法
- 安全認(rèn)證痪寻，防攻擊
- API訪問控制
- Swagger導(dǎo)入導(dǎo)出
- …
API網(wǎng)關(guān)的核心設(shè)計實踐
? 提供一個可參考的高性能API網(wǎng)關(guān)架構(gòu)， 在設(shè)計API網(wǎng)關(guān)的時候把整體分為兩個平面虽惭， API Consumer使用的稱之為數(shù)據(jù)平面橡类， API Provider使用的稱之為管理平面， 可在一定程度上對業(yè)務(wù)請求跟管理請求進(jìn)行有效隔離芽唇。
先談一下數(shù)據(jù)平面
? API網(wǎng)關(guān)最核心設(shè)計理念： 保證數(shù)據(jù)面的業(yè)務(wù)不中斷顾画。由于對接API網(wǎng)關(guān)的服務(wù)是多樣的， 客戶API跟應(yīng)用的設(shè)計不可控， 你很難能要求每個接入的服務(wù)以及客戶端都具備容錯能力亲雪， 特別是一些比較傳統(tǒng)的業(yè)務(wù)勇凭。 這就要求網(wǎng)關(guān)盡量保證能正常處理每個請求， 且滿足較高的SLA（Service-Level Agreement）义辕，現(xiàn)在業(yè)界的API網(wǎng)關(guān)分為幾種： 直接使用云服務(wù)虾标， Nginx系列， Golang系列灌砖， Java系列等璧函， 選擇比較多，如果想要自構(gòu)建基显， 推薦使用Nginx系蘸吓，主要考慮如下：
- 支持熱重啟
數(shù)據(jù)面的組件升級是一個高風(fēng)險動作， 一旦出現(xiàn)異常就可能導(dǎo)致連接中斷撩幽，系統(tǒng)異常库继， 除非你的前端LB（負(fù)載均衡）能具備快速排水的能力，當(dāng)然即使如此窜醉，還是可能導(dǎo)致正在處理的請求被強(qiáng)制中斷宪萄。所以數(shù)據(jù)面的熱重啟非常關(guān)鍵。 - 支持訂閱式動態(tài)路由
API路由變化相對頻繁榨惰，及時性也要求比較高拜英， 如果采用定期同步方案， 一次性同步幾萬條的數(shù)據(jù)會拖慢你的系統(tǒng)琅催， 因此增加一個訂閱式的路由服務(wù)中心非常關(guān)鍵居凶， 我們可以快速訂閱ETCD中的路由數(shù)據(jù)并實時生效。而且只拿增量數(shù)據(jù)性能壓力不會太大藤抡。 - 支持插件化管理
Nginx在插件方面提供了豐富的生態(tài)侠碧。不同的API，不同的用戶所需要的處理流程不完全一致缠黍， 如果每個請求過來都按照相同流程處理舆床，必定帶來相關(guān)的冗余操作。 插件化管理可以在一定程度上提升性能嫁佳，還能保障在升級過程中能快速添加處理鏈挨队。 - 高性能的轉(zhuǎn)發(fā)能力
API網(wǎng)關(guān)一般工作在多后端API反向代理模式，很多自研的API網(wǎng)關(guān)在性能上容易出現(xiàn)瓶頸蒿往，因此nginx優(yōu)異的性能和高效的流量吞吐是其核心競爭力盛垦。 - 無狀態(tài)可橫向擴(kuò)展：
API網(wǎng)關(guān)承載的是整個系統(tǒng)所有請求的集合，需要根據(jù)業(yè)務(wù)規(guī)模進(jìn)行彈性伸縮瓤漏，采用服務(wù)中心配合Nginx配置管理可以快速增刪已有的集群腾夯，并同步到LVS颊埃，實現(xiàn)快速的橫向擴(kuò)展能力。
再說一下管理面
相對于數(shù)據(jù)面蝶俱， 管理面的約束就沒有那么明顯了班利， 管理面考慮更多應(yīng)該在于數(shù)據(jù)的存儲跟展示能力。一開始就定義好API的規(guī)范至關(guān)重要榨呆， Swagger作為現(xiàn)在最為主流的API描述模式罗标，擁有非常完整的生態(tài)，AWS的整個API網(wǎng)關(guān)模型就是參考Swagger來構(gòu)建的积蜻。
核心架構(gòu)實現(xiàn)
API網(wǎng)關(guān)的相關(guān)實現(xiàn)闯割， 我們今天就流控和路由遍歷進(jìn)行說明，其他相關(guān)的核心設(shè)計后續(xù)的文章中會陸續(xù)提供竿拆。
精細(xì)化秒級流控
? 分鐘級以上的流控宙拉，相對來說都比較好處理， 但是提升到秒級流控丙笋，對于系統(tǒng)的性能跟處理能力就是一個很大的挑戰(zhàn)谢澈。網(wǎng)上的流控方案很多， 同步的御板，異步的各有優(yōu)勢锥忿， 但是都會遇到共同的問題： 性能與準(zhǔn)確度。
以下是一種最為常見的流控方案（集群流控）稳吮， 使用Redis共享存儲記錄所有的流控請求并實時訪問， 該架構(gòu)存在一個很明顯的問題：當(dāng)集群數(shù)量跟請求量很大的時候井濒，Redis的集群性能會成為很大的瓶頸灶似。
? 我們重新設(shè)計了一套API流控架構(gòu)， 混合使用多種流控方案瑞你， 按照業(yè)務(wù)需求自動調(diào)整酪惭。這里我們拆分為本地流控和集群流控。 對于流量敏感的應(yīng)用者甲，會要求流控精度越精確春感，計算及時性高，時間維度低（秒級）虏缸， 采用本地流控鲫懒。對于時間周期長， 訪問頻率較低的API我們采用集群流控刽辙， 降低對共享存儲的操作頻率窥岩。
注：上圖展示具體流控架構(gòu)，與API網(wǎng)關(guān)的集成請參考本章節(jié)開頭的API網(wǎng)關(guān)架構(gòu)全景宰缤。
- 本地流控
即單機(jī)流控颂翼，適用流量敏感型業(yè)務(wù)晃洒。 API按照API-Core集群節(jié)點計算Hash值，確保每個API都能負(fù)載到其中一個集群節(jié)點上朦乏。 假設(shè)有A球及， B，C三臺API-Core呻疹， 如果某個API計算的一致性hash值為A節(jié)點吃引， 當(dāng)請求發(fā)送到A節(jié)點時直接從這臺節(jié)點轉(zhuǎn)發(fā)，并記錄一個流控值诲宇， 當(dāng)請求發(fā)送到B/C節(jié)點的時候都會轉(zhuǎn)發(fā)到A節(jié)點計算一個流控值再往后轉(zhuǎn)發(fā)际歼。 這樣同一個API的流控請求就會全部記錄到一臺API-Core上」美叮可以借助API-Core的單機(jī)流控能力鹅心。單機(jī)流控的算法也是插件化的，可以采用計數(shù)纺荧，漏桶等旭愧。
當(dāng)然本地流控也會帶來一定問題，當(dāng)所有的API都負(fù)載到一個節(jié)點上宙暇，如果一個API的訪問量特別大输枯， 那就可能導(dǎo)致負(fù)載不太均勻。還有就是如果流控時間記錄很長占贫，比如12次/天桃熄， 計數(shù)時間周期太長了也不太適合本地流控。 - 集群流控
集群流控適用計數(shù)周期長型奥， 流控精度要求不高的業(yè)務(wù)瞳收。跟本地流控相輔相成， 按照不同的業(yè)務(wù)選擇不同的流控厢汹， 相關(guān)的流控處理流程跟上述的本地流控基本相同螟深，但是會在本地會先緩存一段時間的流控數(shù)據(jù)再統(tǒng)一上報流控中心。
基于樹形結(jié)構(gòu)的路由遍歷算法
? API網(wǎng)關(guān)數(shù)據(jù)面的主要流程包含路由匹配算法烫葬， 路由的所有數(shù)據(jù)都會緩存在ETCD中界弧，為提升數(shù)據(jù)面性能， 存儲的結(jié)構(gòu)至關(guān)重要搭综。在存儲過程中我們分為兩部分： 域名樹垢箕， URI樹
? 從第一個樹形結(jié)構(gòu)中我們可以遍歷到有以下幾個域名： www.apig.com, test.com, *.apig.com, .com。 域名存儲從最后一個“.”開始遍歷兑巾。 舉例：
? 匹配： www.test.com 舰讹， 先匹配com， 匹配成功繼續(xù)遍歷test闪朱， 匹配成功遍歷www月匣， 無www匹配失敗钻洒。
? 匹配： test.apig.com, 先匹配com， 匹配成功繼續(xù)遍歷apig锄开， 匹配成功遍歷test素标， 無test， 遍歷號萍悴， 匹配目標(biāo)： *.apig.com
? URL的匹配為前序匹配跟域名的匹配模式相反头遭，但是遍歷算法一致。
總結(jié)
? 業(yè)界主流的開源API網(wǎng)關(guān)架構(gòu)很多癣诱， Kong,计维，Tyk， Zuul等撕予，開源軟件都有一個共同的特點： 量級鲫惶，安全，運(yùn)維分析相對匱乏实抡， 而且真正要滿足生產(chǎn)環(huán)境需求欠母，還需要投入較高的研發(fā)成本。術(shù)業(yè)有專攻吆寨，找一個完善的API管理解決方案對于企業(yè)能力變現(xiàn)非常重要赏淌。
? 華為云API網(wǎng)關(guān)服務(wù)提供完整的API生命周期管理解決方案， 支持多種使用場景啄清， 提供便捷的管理服務(wù)六水。讓API的上線，發(fā)布辣卒，管理到最后售賣的流程不再復(fù)雜掷贾，快速完成企業(yè)能力變現(xiàn)。 歡迎前往體驗： 華為云-API 網(wǎng)關(guān)
