整體架構

我們的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。

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，為此我們開發了雙端告警，一份告警會同時發送給客戶端和服務端雙方。