建設(shè)微服務(wù)API網(wǎng)關(guān)的一些實踐
[導讀]隨著這些年微服務(wù)的流行，API網(wǎng)關(guān)已經(jīng)成為微服務(wù)架構(gòu)中不可或缺的一環(huán)。一方面它承擔著服務(wù)對外的唯一門戶，一方面它提取了許多應(yīng)用的共性功能。整體架構(gòu)我們的API網(wǎng)關(guān)目前的架構(gòu)如下圖所示，可以看到API網(wǎng)關(guān)處于一個什么位置，往上承接所有的南北流量，往下會分發(fā)流量到微服務(wù)應(yīng)用或者BFF...
目前API網(wǎng)關(guān)實現(xiàn)的功能包括請求分發(fā)、條件路由、API管理、限流隔離、熔斷降級、安全策略、監(jiān)控報警以及調(diào)用鏈追蹤等。
我們的API網(wǎng)關(guān)基于RxNetty開發(fā)，整個流程是異步響應(yīng)式的，可以達到較高的單機并發(fā)?；谏僭燧喿拥睦砟?，API網(wǎng)關(guān)的大部分功能都是結(jié)合現(xiàn)有平臺實現(xiàn)。包括請求分發(fā)、條件路由基于微服務(wù)框架，限流隔離、熔斷降級基于穩(wěn)定性平臺，監(jiān)控報警基于監(jiān)控平臺等，安全策略基于大數(shù)據(jù)分析平臺等。注冊中心與配置中心則分別負責服務(wù)注冊核心信息與第三方配置信息的下發(fā)。
經(jīng)過一系列url規(guī)范化行動后，我們的url目前不同的應(yīng)用都會采取不同的前綴，同時這個前綴信息會隨著應(yīng)用注冊到注冊中心。這樣網(wǎng)關(guān)進行服務(wù)發(fā)現(xiàn)時會給不同的url前綴以及微服務(wù)應(yīng)用構(gòu)建不同的namespace對象，在進行請求匹配時候只需根據(jù)url前綴選取到對應(yīng)的namespace即可匹配到對應(yīng)微服務(wù)應(yīng)用，后續(xù)就是現(xiàn)有微服務(wù)框架SDK的功能：路由、負載均衡直至完成整個調(diào)用。
這里還涉及到另一個問題，網(wǎng)關(guān)選擇服務(wù)發(fā)現(xiàn)的應(yīng)用是哪些？即我需要拉取哪些應(yīng)用信息以構(gòu)建namespace？我們這里對服務(wù)發(fā)現(xiàn)對象進行了管理，用戶可在管控平臺上控制微服務(wù)應(yīng)用在網(wǎng)關(guān)層的上下線，這會通過我們的配置中心推送到網(wǎng)關(guān)并進行一次熱更新，刷新內(nèi)存緩存，這樣就做到了請求分發(fā)服務(wù)的動態(tài)增減。
同樣的，在基于Nginx開發(fā)的網(wǎng)關(guān)中，一般是維護多套upstream列表，然后通過某種策略將不同請求代理到不同upstream。
在我們的實現(xiàn)中，條件路由依然是復用現(xiàn)有的微服務(wù)框架，避免重復造輪子。每個應(yīng)用都可以根據(jù)一些規(guī)則創(chuàng)建一些分組，分組中有若干實例。在網(wǎng)關(guān)進行服務(wù)發(fā)現(xiàn)初始化時會給每個應(yīng)用創(chuàng)建Invoker代理對象，Invoker內(nèi)會根據(jù)不同的分組創(chuàng)建不同的Space空間，請求調(diào)用時會對這些Space空間進行規(guī)則匹配，從而決定是否路由到特定分組上。整個過程都是微服務(wù)框架完成的，沒有額外的開發(fā)工作。
目前我們支持按照特定內(nèi)容或者流量比例兩種方式進行請求來源規(guī)則的匹配，特定內(nèi)容包括http請求的header、attribute等等。我們目前的實例分組主要是根據(jù)“版本”這個標來區(qū)分的，所以分配規(guī)則主要是支持“版本”維度，未來考慮支持到Kubernetes的Pod label。
實現(xiàn)上和之前的應(yīng)用上下線類似，額外依賴了DB存儲，用戶在管控平臺進行API發(fā)布等操作會先存儲在DB中，隨后通過配置中心pub/sub通知到網(wǎng)關(guān)。我們在namespace匹配前加入了一層filter以過濾刪除/未上線的API，所以熱更新該filter對象即可。
用戶體驗方面我們也做了一些工作，包括：
-
從微服務(wù)管控平臺直接同步新增的API接口到網(wǎng)關(guān)管控平臺，而無需手動添加。此外也支持多種格式的文件導入。（我們的微服務(wù)注冊模型會包括API信息等元數(shù)據(jù)）
-
各個環(huán)境之間通過流轉(zhuǎn)功能發(fā)布API，而無需重復添加
-
對各個狀態(tài)的篩選展示
-
與DevOps平臺配合，在應(yīng)用發(fā)布流轉(zhuǎn)時同步提醒進行API管理的發(fā)布流轉(zhuǎn)。
我們的限流隔離/熔斷降級均基于穩(wěn)定性平臺與配置中心實現(xiàn)，穩(wěn)定性平臺是我們基于Sentinel二次開發(fā)的。整個結(jié)構(gòu)如下圖所示：
穩(wěn)定性相關(guān)的功能主要包括限流隔離以及熔斷降級。限流隔離主要是作用在流入方向服務(wù)端測的流量控制，其中限流主要是控制QPS，隔離主要是控制并發(fā)數(shù)。熔斷降級則是作用在流出方向客戶端測的流量控制，可以配置在一定錯誤率情況下進行熔斷，并配合降級數(shù)據(jù)快速返回。
以上規(guī)則均可以通過穩(wěn)定性平臺配置，然后由配置中心分發(fā)到API網(wǎng)關(guān)，再進行熱更新刷新內(nèi)存緩存。每次請求時sentinel sdk都會幫我們做好數(shù)據(jù)統(tǒng)計并判斷是否符合規(guī)則，同時被限流隔離、熔斷降級的流量都會通過相關(guān)SDK（基于Prometheus）暴露Metrics數(shù)據(jù)給監(jiān)控平臺，以便我們隨時觀察到流量控制水平。
整個安全策略的結(jié)構(gòu)如上所示。用戶可以在網(wǎng)關(guān)管控平臺手動進行規(guī)則配置，經(jīng)由配置中心下發(fā)到API網(wǎng)關(guān)的securityControl進行熱更新。在請求來臨時由securityControl判斷是否符合規(guī)則，被封禁的流量同樣暴露metrics數(shù)據(jù)給監(jiān)控平臺供我們隨時查看。
此外，手動配置封禁規(guī)則在某些場景可能比較低效。我們同時還會將網(wǎng)關(guān)日志實時采集至大數(shù)據(jù)分析平臺，經(jīng)分析后如果判斷某個IP或者用戶存在異常情況，會自動配置安全策略規(guī)則至網(wǎng)關(guān)管控平臺，同時觸發(fā)一個報警提醒業(yè)務(wù)owner。
在安全策略目標方面，我們目前支持包括根據(jù)客戶端IP、用戶ID、其余http header/attribute等。策略行為方面目前支持快速失敗以及驗證碼，后者用戶會在前端被跳轉(zhuǎn)到一個人機驗證碼的頁面。
報警這塊除了針對Metrics信息/錯誤日志的報警，還可以支持主機層面的報警。
得益于監(jiān)控平臺以及調(diào)用鏈埋點SDK，API網(wǎng)關(guān)幾乎不需要改造成本即可接入。整體結(jié)構(gòu)如下所示，API網(wǎng)關(guān)內(nèi)嵌了Metrics SDK暴露Metrics信息到Endpoint供監(jiān)控中心拉取，tracing sdk負責埋點打印tracing日志，tracing日志和業(yè)務(wù)日志均會通過日志采集器輸入監(jiān)控中心處理。在監(jiān)控平臺上，用戶可以查詢調(diào)用鏈、監(jiān)控、日志信息，API網(wǎng)關(guān)發(fā)生的主機異?；蛘邩I(yè)務(wù)異常也會報警給owner。
這里值得一提的是，當網(wǎng)關(guān)調(diào)用后端微服務(wù)應(yīng)用發(fā)生異常時，例如超時、連接池耗盡等，這些錯誤發(fā)生在客戶端即API網(wǎng)關(guān)，所以觸發(fā)的報警只會報給API網(wǎng)關(guān)的owner。但是API網(wǎng)關(guān)僅僅作為一個轉(zhuǎn)發(fā)服務(wù)，其超時很大程度是因為后端微服務(wù)rt過高，所以報警應(yīng)該同時報給后端微服務(wù)owner，為此我們開發(fā)了雙端告警，一份告警會同時發(fā)送給客戶端和服務(wù)端雙方。
-
我們還支持websocket協(xié)議，本次沒有詳細說。
-
在多云部署環(huán)境下，網(wǎng)關(guān)承載了一個多云流量調(diào)度服務(wù)的角色。
以及未來可以優(yōu)化的地方：
-
首先是我們的高并發(fā)能力并未怎么經(jīng)過實際驗證，由于tob商業(yè)模式公司沒有太多高并發(fā)的場景。
-
考慮引入規(guī)則引擎來應(yīng)付各種下發(fā)的規(guī)則，包括安全策略、穩(wěn)定性、路由規(guī)則等。
-
安全策略考慮會支持更多一些，例如IP網(wǎng)段，及支持各種邏輯與或非。
下載文檔
