引言
全局過濾器無疑是作用于所有經過網關轉發的請求的，對于設計者來說被設計成全局過濾器實現的功能組件也即是設計者認為此功能是網關所必備的功能組件，這點非常重要的，對于引入spring-cloud-gateway做二次封裝的時候，我們應該秉承作者的設計思想，即如果需要增加一個全局過濾組件的時候應該實現一個全局過濾器（即實現GlobalFilter接口）。
我們可以通過gateway內嵌的endpoint來查看GlobalFilter列表（/actuator/gateway/globalfilters）：
從api結果可以看到一個全局過濾器列表，并且沒一個過濾器都有一個排序id，gateway是通過同時實現Ordered接口來實現控制過濾器的過濾順序的，其中id越小其代表的優先級越高。
預覽GlobalFilter、Ordered
從GlobalFilter接口的聲明來看，其作用及其明確，就是定義了一個filter行為，用于攔截web請求和實現一些跨領域，與應用無關的需求，比如安全驗證、超時判斷和其他的一些功能性行為。
Ordered接口是spring框架的一個規范接口，用于元素排序或者需要有序的對象實現該接口。
從endpoint api的結果中我們將org.springframework.cloud.gateway.filter.包下的全局過濾器羅列出來，org.iblog.enhance.gateway.filter.**包下的均是增強實現的攔截功能（本文對于自增實現只簡單提及，后續章節會詳細解釋）。
- org.iblog.enhance.gateway.filter.MarkRequestFilter@75c589f2: -2147483647,
- org.springframework.cloud.gateway.filter.AdaptCachedBodyGlobalFilter@7c8f803d: -2147482648,
- org.iblog.enhance.gateway.filter.logging.LoggingRequestBodyFilter@6db04a6: -1000,
- org.iblog.enhance.gateway.filter.convert.ConvertRequestBodyFilter@1bba9862: -900,
- org.iblog.enhance.gateway.filter.extract.ExtractRequestBodyFilter@565c887e: -800,
- org.iblog.enhance.gateway.filter.async.AsyncProcessingFilter@1317ac2c: -700,
- org.iblog.enhance.gateway.filter.convert.ConvertResponseBodyFilter@451a4187: -25,
- org.iblog.enhance.gateway.filter.logging.LoggingResponseBodyFilter@8f374de: -20,
- org.iblog.enhance.gateway.filter.extract.ExtractResponseBodyFilter@5c215642: -10,
- org.springframework.cloud.gateway.filter.NettyWriteResponseFilter@4e26c308: -1,
- org.springframework.cloud.gateway.filter.ForwardPathFilter@7c6ab057: 0,
- org.springframework.cloud.gateway.filter.GatewayMetricsFilter@1f7557fe: 0,
- org.iblog.enhance.gateway.filter.logging.LoggingResponseStatusFilter@426913c4: 1,
- org.springframework.cloud.gateway.filter.RouteToRequestUrlFilter@176e839e: 10000,
- org.springframework.cloud.gateway.filter.LoadBalancerClientFilter@363ba634: 10100,
- org.iblog.enhance.gateway.filter.logging.LoggingRealPathFilter@416c1b0: 10101
- org.springframework.cloud.gateway.filter.WebsocketRoutingFilter@7ce4498f: 2147483646,
- org.springframework.cloud.gateway.filter.ForwardRoutingFilter@4ac0d49: 2147483647,
展示官方的架構設計圖，所有的filtter則按照圖中filter模塊進行工作，處于handler-proxied模塊之間，而且是一個雙向的工作關系：
MarkRequestFilter | 優先級：-2147483647
這是我個人實現的一個GlobalFilter，這是為自己在后續功能實現而準備的一個過濾器；為每一個request第一時間分配一個uniqueue_key，并且set到exchange的attributes屬性列表當中。
AdaptCachedBodyGlobalFilter | 優先級：-2147482648
gateway內置的一個GlobalFilter，其作用是從exchange的attributes中或者cachedRequestBody屬性值作為request的body，注意使用此功能首先必須預設cachedRequestBody屬性至attributes中，這個必須要手動設置，無法通過配置來設置的，可以在優先級更高的filter中來設置cachedRequestBody；當然也可以自己寫一個FilterFactory類來做成配置化；我個人覺得暫時這個過濾器作用場景還不太明確，可以不用太考慮。
LoggingRequestBodyFilter | 優先級： -1000
這個GlobalFilter是我自己實現的，其功能是對于gateway透傳的每一個請求進行日志跟蹤并且記錄至持久化層，這里會將request的基礎信息logging下來，初始化一個日志實體存儲。
ConvertRequestBodyFilter | 優先級： -900
屬于enhance-gateway自己的實現，這個功能在還是比較常見的，尤其是面向B端客戶需求的時候，會有接口對接時報文轉換的需求，在這個filter中就是實現了這種應用無感知的轉換。
ExtractRequestBodyFilter | 優先級：-800
屬于enhance-gateway自己的實現，這個功能與ConvertRequestBodyFilter類似，只不過這里不是報文轉換，而是實現從報文中抽取一些關鍵詞，這個filter從某個角度上其實可以考慮與ConvertRequestBodyFilter合并成一個filter實現，這個取決于需求的復雜性。
AsyncProcessingFilter | 優先級：-700
屬于enhance-gateway自己的實現，這里是一種針對性的需求，接受調用方一個請求，而調用方對于處理結果的處理進度沒有時間敏感或者任務處理時常過長的情況，采用即時反饋而異步作處理的方式來處理。
ConvertResponseBodyFilter | 優先級：-25
屬于enhance-gateway自己的實現，與ConvertRequestBodyFilter對稱，對于response的body做輸出報文轉換的需求，這個視具體應用場景來定，算是一種比較常見的開發場景。
LoggingResponseBodyFilter | 優先級：-20
屬于enhance-gateway自己的實現，與LoggingRequestBodyFilter對稱，將response的body記錄進日志需求中。
ExtractResponseBodyFilter | 優先級：-10
屬于enhance-gateway自己的實現，與ExtractRequestBodyFilter對稱，將response的body中的關鍵詞記錄進日志需求中。
NettyWriteResponseFilter | 優先級：-1
將Netty代理調用的response數據流寫入ServerHttpResponse的body中，此外這個是一個先調用后發生的行為動作，流式編程的典型范例，也是驗證了之前所說的filter的鏈式調用是一個對稱的模型，對于優先級越高的行為定義其真實發生其實越晚，NettyWriteResponseFilter將結果數據流寫入ServerHttpResponse中發生在NettyRouting獲取到遠程調用的結果數據流之后，當NettyRouting拿到結果數據流之后會將其寫入當前請求exchange的attributes中，寫入發生在return語句。建議調試階段可以將log level設置為trace，這樣可以清楚地觀察請求的行為發生軌跡。
ForwardPathFilter | 優先級：0
這是一個條件過濾器，只有當請求的header scheme為forward的時候才會發生，否則會忽略沒有任何作用，當有轉發需求的時候會將request的請求path修改，從而修改了請求的目的地址。
GatewayMetricsFilter | 優先級：０
metrics實現，對于每個請求記錄其發生時間戳，包括開始和結束時間以及請求狀態，gateway集成了micrometer框架來實現的，個人覺得這個metrics實現并不是非常完美，micrometer實現其實依賴了dropwizard-metrics，dropwizard-metrics與微服務框架dropwizard之間可以無縫集成，效果非常好，監控數據是非常全面的，而micrometer實現比較精簡，感興趣的讀者可以學習一下dropwizard的使用，輕量級容易上手開發。
LoggingResponseStatusFilter | 優先級：１
屬于enhance-gateway自己的實現，與GatewayMetricsFilter記錄請求結果狀態一致，不過我是基于依賴做的二次開發，無法復用已有的邏輯部分；這里有個需要注意的地方，就是其優先級必須發生在NettyWriteResponseFilter之后，也就是要大于-1才能獲取到status，否則取到的會是null。
RouteToRequestUrlFilter | 優先級：10000
RouteToRequestUrlFilter是必須的全局過濾器，這個會在你通過注冊中心配置一個下游服務的時候起作用，請求進來的時候path的前綴是gateway的服務地址（ip+port或者是域名），但是對于真實的請求調用，必須將其uri映射至服務id上；比如將path的192.168.20.134:10080映射至服務lb://{serviceId}；而對于絕對路徑配置的服務exchange的GATEWAY_ROUTE_ATTR屬性將會是null，直接過濾到下一個過濾器，而不會發生path的真實映射。
LoadBalancerClientFilter | 優先級：10100
LoadBalancerClientFilter負責服務真實ip的映射，主要針對對個服務節點的情況進行負載均衡，默認采用的netflix-ribbon作為負載均衡器，首先如果scheme不是服務節點映射的話直接過濾，獲取服務節點，69行的choose函數是真實負載均衡發生的函數，獲取一個本次選出的服務server instance（如果是單節點則無負載計算），然后將服務的真實ip+port替換掉path中的lb://{serviceId}前綴。
LoggingRealPathFilter | 優先級：10101
屬于enhance-gateway自己的實現，發生在LoadBalancerClientFilter之后便可以獲取當前請求的真實path。
WebsocketRoutingFilter | 優先級：2147483646
WebsocketRoutingFilter過濾器實現了gateway對于websocket的支持，內部通過websocketClient實現將一個http請求協議換轉成websocket，實現調用方無感知的請求websocket的服務，只需要將schme設置成ws或者wss這么簡單。
ForwardRoutingFilter | 優先級：2147483647
ForwardRoutingFilter是一個結束操作，經過filter chain的鏈式調用，最終將exchange交還給web handler做http請求處理。
總結
源碼當中還有兩個GlobalFilter，分別是WebClientHttpRoutingFilter、WebClientWriteResponseFilter，/actuator/gateway/globalfilters結果當中不包含它們原因是沒有在GatewayAutoConfiguration依賴注入，作者還沒啟用。
整個filter的調用通過Ordered接口捆綁成一個鏈式結構，并且通過reactor流式編程將代碼精簡，這是一個非常優秀的思想，如果在自己的服務當中采用此編碼模型的話，會使得代碼清晰很多，感興趣的讀者可以參考學習reactor-core。
本文主要分析了gateway的GlobalFilter的源碼實現，對于enhance-gateway實現的GlobalFilter只是提及，這個是一種前后對應的設計思想，并不是很完美，計劃在后續通過一篇獨立的文章探討自己的思想，并進行優化。
注：enhance-gateway參考地址
