作者：fredalxin
地址：https://fredal.xin/build-api-gateway
隨著這些年微服務的流行，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介面到網關管控平臺，而無需手動添加，此外也支持多種格式的檔案匯入，(我們的微服務注冊模型會包括api資訊等元資料)
- 各個環境之間通過流轉功能發布api，而無需重復添加
- 對各個狀態的篩選展示
- 與devops平臺配合，在應用發布流轉時同步提醒進行api管理的發布流轉，
限流隔離/熔斷降級
Api網關作為南北流量的唯一入口，一般具有較高并發度，以及流量復雜性，所以對入口流量進行整治管理是很有必要的，
我們的限流隔離/熔斷降級均基于穩定性平臺與配置中心實作，穩定性平臺是我們基于Sentinel二次開發的，整個結構如下圖所示：
穩定性相關的功能主要包括限流隔離以及熔斷降級，限流隔離主要是作用在流入方向服務端測的流量控制，其中限流主要是控制qps，隔離主要是控制并發數，熔斷降級則是作用在流出方向客戶端測的流量控制，可以配置在一定錯誤率情況下進行熔斷，并配合降級資料快速回傳，
以上規則均可以通過穩定性平臺配置，然后由配置中心分發到api網關，再進行熱更新重繪記憶體快取，每次請求時sentinel sdk都會幫我們做好資料統計并判斷是否符合規則，同時被限流隔離、熔斷降級的流量都會通過相關sdk(基于prometheus)暴露metrics資料給監控平臺，以便我們隨時觀察到流量控制水平，
安全策略
時常我們會遇見一些例外流量，典型的就是惡意爬蟲，所以完善一些基礎的安全策略是必要的，
整個安全策略的結構如上所示，用戶可以在網關管控平臺手動進行規則配置，經由配置中心下發到api網關的securityControl進行熱更新，在請求來臨時由securityControl判斷是否符合規則，被封禁的流量同樣暴露metrics資料給監控平臺供我們隨時查看，
此外，手動配置封禁規則在某些場景可能比較低效，我們同時還會將網關日志實時采集至大資料分析平臺，經分析后如果判斷某個ip或者用戶存在例外情況，會自動配置安全策略規則至網關管控平臺，同時觸發一個報警提醒業務owner，
在安全策略目標方面，我們目前支持包括根據客戶端IP、用戶ID、其余http header/attribute等，策略行為方面目前支持快速失敗以及驗證碼，后者用戶會在前端被跳轉到一個人機驗證碼的頁面，
監控報警/呼叫鏈追蹤
與其他微服務應用一樣，我們的api網關也有完善的監控報警、呼叫鏈追蹤、日志查詢等功能，這里監控主要指的是查詢metrics資訊，呼叫鏈主要指查詢tracing資訊，日志顧名思義就是logging，三者是監控領域很典型的資訊了：
報警這塊除了針對metrics資訊/錯誤日志的報警，還可以支持主機層面的報警，
得意于監控平臺以及呼叫鏈埋點sdk，api網關幾乎不需要改造成本即可接入，整體結構如下所示，api網關內嵌了metrics sdk暴露metrics資訊到endpoint供監控中心拉取，tracing sdk負責埋點列印tracing日志，tracing日志和業務日志均會通過日志采集器輸入監控中心處理，在監控平臺上，用戶可以查詢呼叫鏈、監控、日志資訊，api網關發生的主機例外或者業務例外也會報警給owner，
這里值得一提的是，當網關呼叫后端微服務應用發生例外時，例如超時、連接池耗盡等，這些錯誤發生在客戶端即api網關，所以觸發的報警也會報給api網關的owner，但是api網關僅僅作為一個轉發服務，其超時很大程度是因為后端微服務rt過高，所以報警應該同時報給后端微服務owner，為此我們開發了雙端告警，一份告警會同時發送給客戶端和服務端雙方，
一些總結
當然api網關還有許多沒有展開說的
- 我們還支持websocket協議，本次沒有詳細說
- 在多云部署環境下，網關承載了一個多云流量調度服務的角色，
以及未來可以優化的地方
- 首先是我們的高并發能力并未怎么經過實際驗證，由于tob商業模式公司沒有太多高并發的場景，
- 考慮引入規則引擎來應付各種下發的規則，包括安全策略、穩定性、路由規則等，
- 安全策略考慮會支持更多一些，例如IP網段，及支持各種邏輯與或非
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2021最新版)
2.終于靠開源專案弄到 IntelliJ IDEA 激活碼了，真香！
3.阿里 Mock 工具正式開源，干掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式發布，全新顛覆性版本！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/288857.html
標籤：其他
下一篇：3.Java入門