建設(shè)微服務(wù)API網(wǎng)關(guān)的一些實(shí)踐



目前API網(wǎng)關(guān)實(shí)現(xiàn)的功能包括請(qǐng)求分發(fā)、條件路由、API管理、限流隔離、熔斷降級(jí)、安全策略、監(jiān)控報(bào)警以及調(diào)用鏈追蹤等。

我們的API網(wǎng)關(guān)基于RxNetty開發(fā),整個(gè)流程是異步響應(yīng)式的,可以達(dá)到較高的單機(jī)并發(fā)?;谏僭燧喿拥睦砟?,API網(wǎng)關(guān)的大部分功能都是結(jié)合現(xiàn)有平臺(tái)實(shí)現(xiàn)。包括請(qǐng)求分發(fā)、條件路由基于微服務(wù)框架,限流隔離、熔斷降級(jí)基于穩(wěn)定性平臺(tái),監(jiān)控報(bào)警基于監(jiān)控平臺(tái)等,安全策略基于大數(shù)據(jù)分析平臺(tái)等。注冊(cè)中心與配置中心則分別負(fù)責(zé)服務(wù)注冊(cè)核心信息與第三方配置信息的下發(fā)。

經(jīng)過一系列url規(guī)范化行動(dòng)后,我們的url目前不同的應(yīng)用都會(huì)采取不同的前綴,同時(shí)這個(gè)前綴信息會(huì)隨著應(yīng)用注冊(cè)到注冊(cè)中心。這樣網(wǎng)關(guān)進(jìn)行服務(wù)發(fā)現(xiàn)時(shí)會(huì)給不同的url前綴以及微服務(wù)應(yīng)用構(gòu)建不同的namespace對(duì)象,在進(jìn)行請(qǐng)求匹配時(shí)候只需根據(jù)url前綴選取到對(duì)應(yīng)的namespace即可匹配到對(duì)應(yīng)微服務(wù)應(yīng)用,后續(xù)就是現(xiàn)有微服務(wù)框架SDK的功能:路由、負(fù)載均衡直至完成整個(gè)調(diào)用。

這里還涉及到另一個(gè)問題,網(wǎng)關(guān)選擇服務(wù)發(fā)現(xiàn)的應(yīng)用是哪些?即我需要拉取哪些應(yīng)用信息以構(gòu)建namespace?我們這里對(duì)服務(wù)發(fā)現(xiàn)對(duì)象進(jìn)行了管理,用戶可在管控平臺(tái)上控制微服務(wù)應(yīng)用在網(wǎng)關(guān)層的上下線,這會(huì)通過我們的配置中心推送到網(wǎng)關(guān)并進(jìn)行一次熱更新,刷新內(nèi)存緩存,這樣就做到了請(qǐng)求分發(fā)服務(wù)的動(dòng)態(tài)增減。


同樣的,在基于Nginx開發(fā)的網(wǎng)關(guān)中,一般是維護(hù)多套u(yù)pstream列表,然后通過某種策略將不同請(qǐng)求代理到不同upstream。
在我們的實(shí)現(xiàn)中,條件路由依然是復(fù)用現(xiàn)有的微服務(wù)框架,避免重復(fù)造輪子。每個(gè)應(yīng)用都可以根據(jù)一些規(guī)則創(chuàng)建一些分組,分組中有若干實(shí)例。在網(wǎng)關(guān)進(jìn)行服務(wù)發(fā)現(xiàn)初始化時(shí)會(huì)給每個(gè)應(yīng)用創(chuàng)建Invoker代理對(duì)象,Invoker內(nèi)會(huì)根據(jù)不同的分組創(chuàng)建不同的Space空間,請(qǐng)求調(diào)用時(shí)會(huì)對(duì)這些Space空間進(jìn)行規(guī)則匹配,從而決定是否路由到特定分組上。整個(gè)過程都是微服務(wù)框架完成的,沒有額外的開發(fā)工作。
目前我們支持按照特定內(nèi)容或者流量比例兩種方式進(jìn)行請(qǐng)求來源規(guī)則的匹配,特定內(nèi)容包括http請(qǐng)求的header、attribute等等。我們目前的實(shí)例分組主要是根據(jù)“版本”這個(gè)標(biāo)來區(qū)分的,所以分配規(guī)則主要是支持“版本”維度,未來考慮支持到Kubernetes的Pod label。

實(shí)現(xiàn)上和之前的應(yīng)用上下線類似,額外依賴了DB存儲(chǔ),用戶在管控平臺(tái)進(jìn)行API發(fā)布等操作會(huì)先存儲(chǔ)在DB中,隨后通過配置中心pub/sub通知到網(wǎng)關(guān)。我們?cè)趎amespace匹配前加入了一層filter以過濾刪除/未上線的API,所以熱更新該filter對(duì)象即可。

用戶體驗(yàn)方面我們也做了一些工作,包括:
-
從微服務(wù)管控平臺(tái)直接同步新增的API接口到網(wǎng)關(guān)管控平臺(tái),而無需手動(dòng)添加。此外也支持多種格式的文件導(dǎo)入。(我們的微服務(wù)注冊(cè)模型會(huì)包括API信息等元數(shù)據(jù))
-
各個(gè)環(huán)境之間通過流轉(zhuǎn)功能發(fā)布API,而無需重復(fù)添加
-
對(duì)各個(gè)狀態(tài)的篩選展示
-
與DevOps平臺(tái)配合,在應(yīng)用發(fā)布流轉(zhuǎn)時(shí)同步提醒進(jìn)行API管理的發(fā)布流轉(zhuǎn)。


我們的限流隔離/熔斷降級(jí)均基于穩(wěn)定性平臺(tái)與配置中心實(shí)現(xiàn),穩(wěn)定性平臺(tái)是我們基于Sentinel二次開發(fā)的。整個(gè)結(jié)構(gòu)如下圖所示:

穩(wěn)定性相關(guān)的功能主要包括限流隔離以及熔斷降級(jí)。限流隔離主要是作用在流入方向服務(wù)端測(cè)的流量控制,其中限流主要是控制QPS,隔離主要是控制并發(fā)數(shù)。熔斷降級(jí)則是作用在流出方向客戶端測(cè)的流量控制,可以配置在一定錯(cuò)誤率情況下進(jìn)行熔斷,并配合降級(jí)數(shù)據(jù)快速返回。
以上規(guī)則均可以通過穩(wěn)定性平臺(tái)配置,然后由配置中心分發(fā)到API網(wǎng)關(guān),再進(jìn)行熱更新刷新內(nèi)存緩存。每次請(qǐng)求時(shí)sentinel sdk都會(huì)幫我們做好數(shù)據(jù)統(tǒng)計(jì)并判斷是否符合規(guī)則,同時(shí)被限流隔離、熔斷降級(jí)的流量都會(huì)通過相關(guān)SDK(基于Prometheus)暴露Metrics數(shù)據(jù)給監(jiān)控平臺(tái),以便我們隨時(shí)觀察到流量控制水平。


整個(gè)安全策略的結(jié)構(gòu)如上所示。用戶可以在網(wǎng)關(guān)管控平臺(tái)手動(dòng)進(jìn)行規(guī)則配置,經(jīng)由配置中心下發(fā)到API網(wǎng)關(guān)的securityControl進(jìn)行熱更新。在請(qǐng)求來臨時(shí)由securityControl判斷是否符合規(guī)則,被封禁的流量同樣暴露metrics數(shù)據(jù)給監(jiān)控平臺(tái)供我們隨時(shí)查看。
此外,手動(dòng)配置封禁規(guī)則在某些場(chǎng)景可能比較低效。我們同時(shí)還會(huì)將網(wǎng)關(guān)日志實(shí)時(shí)采集至大數(shù)據(jù)分析平臺(tái),經(jīng)分析后如果判斷某個(gè)IP或者用戶存在異常情況,會(huì)自動(dòng)配置安全策略規(guī)則至網(wǎng)關(guān)管控平臺(tái),同時(shí)觸發(fā)一個(gè)報(bào)警提醒業(yè)務(wù)owner。
在安全策略目標(biāo)方面,我們目前支持包括根據(jù)客戶端IP、用戶ID、其余http header/attribute等。策略行為方面目前支持快速失敗以及驗(yàn)證碼,后者用戶會(huì)在前端被跳轉(zhuǎn)到一個(gè)人機(jī)驗(yàn)證碼的頁面。


報(bào)警這塊除了針對(duì)Metrics信息/錯(cuò)誤日志的報(bào)警,還可以支持主機(jī)層面的報(bào)警。
得益于監(jiān)控平臺(tái)以及調(diào)用鏈埋點(diǎn)SDK,API網(wǎng)關(guān)幾乎不需要改造成本即可接入。整體結(jié)構(gòu)如下所示,API網(wǎng)關(guān)內(nèi)嵌了Metrics SDK暴露Metrics信息到Endpoint供監(jiān)控中心拉取,tracing sdk負(fù)責(zé)埋點(diǎn)打印tracing日志,tracing日志和業(yè)務(wù)日志均會(huì)通過日志采集器輸入監(jiān)控中心處理。在監(jiān)控平臺(tái)上,用戶可以查詢調(diào)用鏈、監(jiān)控、日志信息,API網(wǎng)關(guān)發(fā)生的主機(jī)異?;蛘邩I(yè)務(wù)異常也會(huì)報(bào)警給owner。

這里值得一提的是,當(dāng)網(wǎng)關(guān)調(diào)用后端微服務(wù)應(yīng)用發(fā)生異常時(shí),例如超時(shí)、連接池耗盡等,這些錯(cuò)誤發(fā)生在客戶端即API網(wǎng)關(guān),所以觸發(fā)的報(bào)警只會(huì)報(bào)給API網(wǎng)關(guān)的owner。但是API網(wǎng)關(guān)僅僅作為一個(gè)轉(zhuǎn)發(fā)服務(wù),其超時(shí)很大程度是因?yàn)楹蠖宋⒎?wù)rt過高,所以報(bào)警應(yīng)該同時(shí)報(bào)給后端微服務(wù)owner,為此我們開發(fā)了雙端告警,一份告警會(huì)同時(shí)發(fā)送給客戶端和服務(wù)端雙方。

-
我們還支持websocket協(xié)議,本次沒有詳細(xì)說。
-
在多云部署環(huán)境下,網(wǎng)關(guān)承載了一個(gè)多云流量調(diào)度服務(wù)的角色。
以及未來可以優(yōu)化的地方:
-
首先是我們的高并發(fā)能力并未怎么經(jīng)過實(shí)際驗(yàn)證,由于tob商業(yè)模式公司沒有太多高并發(fā)的場(chǎng)景。
-
考慮引入規(guī)則引擎來應(yīng)付各種下發(fā)的規(guī)則,包括安全策略、穩(wěn)定性、路由規(guī)則等。
-
安全策略考慮會(huì)支持更多一些,例如IP網(wǎng)段,及支持各種邏輯與或非。