建設微服務 API 網關的一些實踐

隨着這些年微服務的流行，API 網關已經成爲微服務架構中不可或缺的一環。一方面它承擔着服務對外的唯一門戶，一方面它提取了許多應用的共性功能。

整體架構

我們的 Api 網關目前的架構如上所示，可以看到 Api 網關處於一個什麼位置，往上承接所有的南北流量，往下會分發流量到微服務應用或者 BFF 聚合應用，在 BFF 規範化之前我們仍然將其視爲一個普通微服務應用。

目前 Api 網關實現的功能包括請求分發、條件路由、Api 管理、限流隔離、熔斷降級、安全策略、監控報警以及調用鏈追蹤等。

我們的 Api 網關基於 RxNetty 開發，整個流程是異步響應式的，可以達到較高的單機併發。基於少造輪子的理念，Api 網關的大部分功能都是結合現有平臺實現。包括請求分發、條件路由基於微服務框架，限流隔離、熔斷降級基於穩定性平臺，監控報警基於監控平臺等，安全策略基於大數據分析平臺等。註冊中心與配置中心則分別負責服務註冊核心信息與第三方配置信息的下發。

請求分發

請求的分發路由應該是一個網關最基本的功能，在絕大多數基於 nginx 開發的網關上，這部分功能通常基於動態更新代理的 upstream。而在我們的實現中，認爲網關是一個只訂閱不註冊的微服務而已，區別是微服務應用發起 rpc 調用指定了調用服務，而網關接收請求分發只有 url 信息。這可以通過簡單的改造來複用已有微服務框架的服務發現功能。

經過一系列 url 規範化行動後，我們的 url 目前不同的應用都會採取不同的前綴，同時這個前綴信息會隨着應用註冊到註冊中心。這樣網關進行服務發現時會給不同的 url 前綴以及微服務應用構建不同的 namespace 對象，在進行請求匹配時候只需根據 url 前綴選取到對應的 namespace 即可匹配到對應微服務應用，後續就是現有微服務框架 sdk 的功能：路由、負載均衡直至完成整個調用。

這裏還涉及到另一個問題，網關選擇服務發現的應用是哪些？即我需要拉取哪些應用信息以構建 namespace? 我們這裏對服務發現對象進行了管理，用戶可在管控平臺上控制微服務應用在網關層的上下線，這會通過我們的配置中心推送到網關並進行一次熱更新，刷新內存緩存，這樣就做到了請求分發服務的動態增減。

條件路由 & 灰度發佈

條件路由意味着可以對具有特定內容 (或者一定流量比例) 的請求進行篩選並分發到特定實例組上，是實現灰度發佈、藍綠髮布、ABTest 等功能的基礎。

同樣的，在基於 nginx 開發的網關中，一般是維護多套 upstream 列表，然後通過某種策略將不同請求代理到不同 upstream。

在我們的實現中，條件路由依然是複用現有的微服務框架，避免重複造輪子。每個應用都可以根據一些規則創建一些分組，分組中有若干實例。在網關進行服務發現初始化時會給每個應用創建 Invoker 代理對象，Invoker 內會根據不同的分組創建不同的 Space 空間，請求調用時會對這些 Space 空間進行規則匹配，從而決定是否路由到特定分組上。整個過程都是微服務框架完成的，沒有額外的開發工作。

目前我們支持按照特定內容或者流量比例兩種方式進行請求來源規則的匹配，特定內容包括 http 請求的 header、attribute 等等。我們目前的實例分組主要是根據 "版本" 這個標來區分的，所以分配規則主要是支持 "版本" 維度，未來考慮支持到 k8s 的 pod label。

條件路由的功能結合 devops 平臺發佈管理可以很容易實現灰度發佈。如下圖所示我們將用戶 id 是 100 的請求分發到灰度版本上進行內部測試。

Api 管理

Api 網關爲什麼前面要有 Api 幾個字，我覺得其中一個很重要的原因就是具有 Api 管理功能。當我們的大部分應用還是裸連網關，而不是經過 BFF 聚合時，我們有必要對每個 api 接口都進行管理，以區分哪些是微服務間內部調用，哪些是暴露給前端 / 客戶端調用。

實現上和之前的應用上下線類似，額外依賴了 DB 存儲，用戶在管控平臺進行 api 發佈等操作會先存儲在 DB 中，隨後通過配置中心 pub/sub 通知到網關。我們在 namespace 匹配前加入了一層 filter 以過濾刪除 / 未上線的 api，所以熱更新該 filter 對象即可。

用戶體驗方面我們也做了一些工作，包括：

限流隔離 / 熔斷降級

Api 網關作爲南北流量的唯一入口，一般具有較高併發度，以及流量複雜性。所以對入口流量進行整治管理是很有必要的。

我們的限流隔離 / 熔斷降級均基於穩定性平臺與配置中心實現，穩定性平臺是我們基於 Sentinel 二次開發的。整個結構如下圖所示：

穩定性相關的功能主要包括限流隔離以及熔斷降級。限流隔離主要是作用在流入方向服務端測的流量控制，其中限流主要是控制 qps，隔離主要是控制併發數。熔斷降級則是作用在流出方向客戶端測的流量控制，可以配置在一定錯誤率情況下進行熔斷，並配合降級數據快速返回。

以上規則均可以通過穩定性平臺配置，然後由配置中心分發到 api 網關，再進行熱更新刷新內存緩存。每次請求時 sentinel sdk 都會幫我們做好數據統計並判斷是否符合規則，同時被限流隔離、熔斷降級的流量都會通過相關 sdk(基於 prometheus) 暴露 metrics 數據給監控平臺，以便我們隨時觀察到流量控制水平。

安全策略

時常我們會遇見一些異常流量，典型的就是惡意爬蟲，所以完善一些基礎的安全策略是必要的。

整個安全策略的結構如上所示。用戶可以在網關管控平臺手動進行規則配置，經由配置中心下發到 api 網關的 securityControl 進行熱更新。在請求來臨時由 securityControl 判斷是否符合規則，被封禁的流量同樣暴露 metrics 數據給監控平臺供我們隨時查看。

此外，手動配置封禁規則在某些場景可能比較低效。我們同時還會將網關日誌實時採集至大數據分析平臺，經分析後如果判斷某個 ip 或者用戶存在異常情況，會自動配置安全策略規則至網關管控平臺，同時觸發一個報警提醒業務 owner。

在安全策略目標方面，我們目前支持包括根據客戶端 IP、用戶 ID、其餘 http header/attribute 等。策略行爲方面目前支持快速失敗以及驗證碼，後者用戶會在前端被跳轉到一個人機驗證碼的頁面。

監控報警 / 調用鏈追蹤

與其他微服務應用一樣，我們的 api 網關也有完善的監控報警、調用鏈追蹤、日誌查詢等功能。這裏監控主要指的是查詢 metrics 信息，調用鏈主要指查詢 tracing 信息，日誌顧名思義就是 logging，三者是監控領域很典型的信息了：

這裏值得一提的是，當網關調用後端微服務應用發生異常時，例如超時、連接池耗盡等，這些錯誤發生在客戶端即 api 網關，所以觸發的報警也會報給 api 網關的 owner。但是 api 網關僅僅作爲一個轉發服務，其超時很大程度是因爲後端微服務 rt 過高，所以報警應該同時報給後端微服務 owner，爲此我們開發了雙端告警，一份告警會同時發送給客戶端和服務端雙方。

一些總結

當然 api 網關還有許多沒有展開說的

以及未來可以優化的地方

作者：fredalxin

來源：https://fredal.xin/build-api-gateway

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Xbi5YCEyJUjZXCV8NZg17A

猜你喜歡