通過之前發(fā)布的《Spring Cloud構(gòu)建微服務(wù)架構(gòu)（五）服務(wù)網(wǎng)關(guān)》一文撬码，相信大家對于Spring Cloud Zuul已經(jīng)有了一個(gè)基礎(chǔ)的認(rèn)識(shí)。通過前文的介紹拢切，我們對于Zuul的第一印象通常是這樣的：它包含了對請求的路由和過濾兩個(gè)功能，其中路由功能負(fù)責(zé)將外部請求轉(zhuǎn)發(fā)到具體的微服務(wù)實(shí)例上葡缰，是實(shí)現(xiàn)外部訪問統(tǒng)一入口的基礎(chǔ)淆衷；而過濾器功能則負(fù)責(zé)對請求的處理過程進(jìn)行干預(yù)颠放，是實(shí)現(xiàn)請求校驗(yàn)、服務(wù)聚合等功能的基礎(chǔ)吭敢。然而實(shí)際上，路由功能在真正運(yùn)行時(shí)暮芭，它的路由映射和請求轉(zhuǎn)發(fā)都是由幾個(gè)不同的過濾器完成的鹿驼。其中，路由映射主要通過pre類型的過濾器完成辕宏，它將請求路徑與配置的路由規(guī)則進(jìn)行匹配畜晰，以找到需要轉(zhuǎn)發(fā)的目標(biāo)地址；而請求轉(zhuǎn)發(fā)的部分則是由route類型的過濾器來完成瑞筐，對pre類型過濾器獲得的路由地址進(jìn)行轉(zhuǎn)發(fā)凄鼻。所以，過濾器可以說是Zuul實(shí)現(xiàn)API網(wǎng)關(guān)功能最為核心的部件聚假，每一個(gè)進(jìn)入Zuul的HTTP請求都會(huì)經(jīng)過一系列的過濾器處理鏈得到請求響應(yīng)并返回給客戶端块蚌。

下面，我們就通過本文來詳細(xì)了解一下Spring Cloud Zuul的過濾器膘格！以下內(nèi)容節(jié)選自《Spring Cloud微服務(wù)實(shí)戰(zhàn)》，稍做加工。

過濾器

在Spring Cloud Zuul中實(shí)現(xiàn)的過濾器必須包含4個(gè)基本特征：過濾類型痴脾、執(zhí)行順序牙言、執(zhí)行條件、具體操作菜秦。這些元素看著似乎非常的熟悉甜害，實(shí)際上它就是ZuulFilter接口中定義的四個(gè)抽象方法：

String filterType();
    
int filterOrder();
    
boolean shouldFilter();
    
Object run();

它們各自的含義與功能總結(jié)如下：

• filterType：該函數(shù)需要返回一個(gè)字符串來代表過濾器的類型，而這個(gè)類型就是在HTTP請求過程中定義的各個(gè)階段球昨。在Zuul中默認(rèn)定義了四種不同生命周期的過濾器類型尔店，具體如下：
  • pre：可以在請求被路由之前調(diào)用。
  • routing：在路由請求時(shí)候被調(diào)用褪尝。
  • post：在routing和error過濾器之后被調(diào)用闹获。
  • error：處理請求時(shí)發(fā)生錯(cuò)誤時(shí)被調(diào)用。
• filterOrder：通過int值來定義過濾器的執(zhí)行順序河哑，數(shù)值越小優(yōu)先級(jí)越高避诽。
• shouldFilter：返回一個(gè)boolean類型來判斷該過濾器是否要執(zhí)行。我們可以通過此方法來指定過濾器的有效范圍璃谨。
• run：過濾器的具體邏輯沙庐。在該函數(shù)中鲤妥，我們可以實(shí)現(xiàn)自定義的過濾邏輯，來確定是否要攔截當(dāng)前的請求拱雏，不對其進(jìn)行后續(xù)的路由棉安，或是在請求路由返回結(jié)果之后，對處理結(jié)果做一些加工等铸抑。

請求生命周期

上一節(jié)中贡耽，對于Spring Cloud Zuul中的過濾器類型filterType，我們已經(jīng)做過一些簡單的介紹鹊汛，Zuul默認(rèn)定義了四個(gè)不同的過濾器類型蒲赂，它們覆蓋了一個(gè)外部HTTP請求到達(dá)API網(wǎng)關(guān)，直到返回請求結(jié)果的全部生命周期刁憋。下圖源自Zuul的官方WIKI中關(guān)于請求生命周期的圖解滥嘴，它描述了一個(gè)HTTP請求到達(dá)API網(wǎng)關(guān)之后，如何在各個(gè)不同類型的過濾器之間流轉(zhuǎn)的詳細(xì)過程至耻。

請求生命周期官方圖解

從上圖中若皱，我們可以看到，當(dāng)外部HTTP請求到達(dá)API網(wǎng)關(guān)服務(wù)的時(shí)候尘颓，首先它會(huì)進(jìn)入第一個(gè)階段pre走触，在這里它會(huì)被pre類型的過濾器進(jìn)行處理，該類型的過濾器主要目的是在進(jìn)行請求路由之前做一些前置加工疤苹，比如請求的校驗(yàn)等饺汹。在完成了pre類型的過濾器處理之后，請求進(jìn)入第二個(gè)階段routing痰催，也就是之前說的路由請求轉(zhuǎn)發(fā)階段兜辞，請求將會(huì)被routing類型過濾器處理，這里的具體處理內(nèi)容就是將外部請求轉(zhuǎn)發(fā)到具體服務(wù)實(shí)例上去的過程夸溶，當(dāng)服務(wù)實(shí)例將請求結(jié)果都返回之后逸吵，routing階段完成，請求進(jìn)入第三個(gè)階段post缝裁，此時(shí)請求將會(huì)被post類型的過濾器進(jìn)行處理扫皱，這些過濾器在處理的時(shí)候不僅可以獲取到請求信息，還能獲取到服務(wù)實(shí)例的返回信息捷绑，所以在post類型的過濾器中韩脑，我們可以對處理結(jié)果進(jìn)行一些加工或轉(zhuǎn)換等內(nèi)容。另外粹污，還有一個(gè)特殊的階段error段多，該階段只有在上述三個(gè)階段中發(fā)生異常的時(shí)候才會(huì)觸發(fā)，但是它的最后流向還是post類型的過濾器壮吩，因?yàn)樗枰ㄟ^post過濾器將最終結(jié)果返回給請求客戶端（實(shí)際實(shí)現(xiàn)上還有一些差別进苍，后續(xù)介紹）加缘。

核心過濾器

在Spring Cloud Zuul中，為了讓API網(wǎng)關(guān)組件可以更方便的上手使用觉啊，它在HTTP請求生命周期的各個(gè)階段默認(rèn)地實(shí)現(xiàn)了一批核心過濾器拣宏，它們會(huì)在API網(wǎng)關(guān)服務(wù)啟動(dòng)的時(shí)候被自動(dòng)地加載和啟用。我們可以在源碼中查看和了解它們杠人，它們定義于spring-cloud-netflix-core模塊的org.springframework.cloud.netflix.zuul.filters包下勋乾。

默認(rèn)實(shí)現(xiàn)的核心過濾器

如上圖所示，在默認(rèn)啟用的過濾器中包含了三種不同生命周期的過濾器嗡善，這些過濾器都非常重要市俊，可以幫助我們理解Zuul對外部請求處理的過程，以及幫助我們?nèi)绾卧诖嘶A(chǔ)上擴(kuò)展過濾器去完成自身系統(tǒng)需要的功能滤奈。下面，我們將逐個(gè)地對這些過濾器做一些詳細(xì)的介紹：

pre過濾器

• ServletDetectionFilter：它的執(zhí)行順序?yàn)?3撩满，是最先被執(zhí)行的過濾器蜒程。該過濾器總是會(huì)被執(zhí)行，主要用來檢測當(dāng)前請求是通過Spring的DispatcherServlet處理運(yùn)行伺帘，還是通過ZuulServlet來處理運(yùn)行的昭躺。它的檢測結(jié)果會(huì)以布爾類型保存在當(dāng)前請求上下文的isDispatcherServletRequest參數(shù)中，這樣在后續(xù)的過濾器中伪嫁，我們就可以通過RequestUtils.isDispatcherServletRequest()和RequestUtils.isZuulServletRequest()方法判斷它以實(shí)現(xiàn)做不同的處理领炫。一般情況下，發(fā)送到API網(wǎng)關(guān)的外部請求都會(huì)被Spring的DispatcherServlet處理张咳，除了通過/zuul/路徑訪問的請求會(huì)繞過DispatcherServlet帝洪，被ZuulServlet處理，主要用來應(yīng)對處理大文件上傳的情況脚猾。另外葱峡，對于ZuulServlet的訪問路徑/zuul/，我們可以通過zuul.servletPath參數(shù)來進(jìn)行修改龙助。
• Servlet30WrapperFilter：它的執(zhí)行順序?yàn)?2砰奕，是第二個(gè)執(zhí)行的過濾器。目前的實(shí)現(xiàn)會(huì)對所有請求生效提鸟，主要為了將原始的HttpServletRequest包裝成Servlet30RequestWrapper對象军援。
• FormBodyWrapperFilter：它的執(zhí)行順序?yàn)?1，是第三個(gè)執(zhí)行的過濾器称勋。該過濾器僅對兩種類請求生效胸哥，第一類是Content-Type為application/x-www-form-urlencoded的請求，第二類是Content-Type為multipart/form-data并且是由Spring的DispatcherServlet處理的請求（用到了ServletDetectionFilter的處理結(jié)果）赡鲜。而該過濾器的主要目的是將符合要求的請求體包裝成FormBodyRequestWrapper對象烘嘱。
• DebugFilter：它的執(zhí)行順序?yàn)?昆禽，是第四個(gè)執(zhí)行的過濾器。該過濾器會(huì)根據(jù)配置參數(shù)zuul.debug.request和請求中的debug參數(shù)來決定是否執(zhí)行過濾器中的操作蝇庭。而它的具體操作內(nèi)容則是將當(dāng)前的請求上下文中的debugRouting和debugRequest參數(shù)設(shè)置為true醉鳖。由于在同一個(gè)請求的不同生命周期中，都可以訪問到這兩個(gè)值哮内，所以我們在后續(xù)的各個(gè)過濾器中可以利用這兩值來定義一些debug信息盗棵，這樣當(dāng)線上環(huán)境出現(xiàn)問題的時(shí)候，可以通過請求參數(shù)的方式來激活這些debug信息以幫助分析問題北发。另外纹因，對于請求參數(shù)中的debug參數(shù)，我們也可以通過zuul.debug.parameter來進(jìn)行自定義琳拨。
• PreDecorationFilter：它的執(zhí)行順序?yàn)?瞭恰，是pre階段最后被執(zhí)行的過濾器。該過濾器會(huì)判斷當(dāng)前請求上下文中是否存在forward.to和serviceId參數(shù)狱庇，如果都不存在惊畏，那么它就會(huì)執(zhí)行具體過濾器的操作（如果有一個(gè)存在的話，說明當(dāng)前請求已經(jīng)被處理過了密任，因?yàn)檫@兩個(gè)信息就是根據(jù)當(dāng)前請求的路由信息加載進(jìn)來的）颜启。而它的具體操作內(nèi)容就是為當(dāng)前請求做一些預(yù)處理，比如：進(jìn)行路由規(guī)則的匹配浪讳、在請求上下文中設(shè)置該請求的基本信息以及將路由匹配結(jié)果等一些設(shè)置信息等缰盏，這些信息將是后續(xù)過濾器進(jìn)行處理的重要依據(jù)，我們可以通過RequestContext.getCurrentContext()來訪問這些信息淹遵。另外口猜，我們還可以在該實(shí)現(xiàn)中找到一些對HTTP頭請求進(jìn)行處理的邏輯，其中包含了一些耳熟能詳?shù)念^域透揣，比如：X-Forwarded-Host暮的、X-Forwarded-Port。另外淌实，對于這些頭域的記錄是通過zuul.addProxyHeaders參數(shù)進(jìn)行控制的冻辩，而這個(gè)參數(shù)默認(rèn)值為true，所以Zuul在請求跳轉(zhuǎn)時(shí)默認(rèn)地會(huì)為請求增加X-Forwarded-*頭域拆祈，包括：X-Forwarded-Host恨闪、X-Forwarded-Port、X-Forwarded-For放坏、X-Forwarded-Prefix咙咽、X-Forwarded-Proto。我們也可以通過設(shè)置zuul.addProxyHeaders=false關(guān)閉對這些頭域的添加動(dòng)作淤年。

《Spring Cloud實(shí)戰(zhàn)小貼士：Zuul處理Cookie和重定向》 一文中提到的加載敏感頭信息加入到忽略頭信息的操作調(diào)用就在PreDecorationFilter過濾器中實(shí)現(xiàn)钧敞。

route過濾器

• RibbonRoutingFilter：它的執(zhí)行順序?yàn)?0蜡豹，是route階段第一個(gè)執(zhí)行的過濾器。該過濾器只對請求上下文中存在serviceId參數(shù)的請求進(jìn)行處理溉苛，即只對通過serviceId配置路由規(guī)則的請求生效镜廉。而該過濾器的執(zhí)行邏輯就是面向服務(wù)路由的核心，它通過使用Ribbon和Hystrix來向服務(wù)實(shí)例發(fā)起請求愚战，并將服務(wù)實(shí)例的請求結(jié)果返回娇唯。
• SimpleHostRoutingFilter：它的執(zhí)行順序?yàn)?00，是route階段第二個(gè)執(zhí)行的過濾器寂玲。該過濾器只對請求上下文中存在routeHost參數(shù)的請求進(jìn)行處理塔插，即只對通過url配置路由規(guī)則的請求生效。而該過濾器的執(zhí)行邏輯就是直接向routeHost參數(shù)的物理地址發(fā)起請求拓哟，從源碼中我們可以知道該請求是直接通過httpclient包實(shí)現(xiàn)的想许，而沒有使用Hystrix命令進(jìn)行包裝，所以這類請求并沒有線程隔離和斷路器的保護(hù)断序。
• SendForwardFilter：它的執(zhí)行順序?yàn)?00流纹，是route階段第三個(gè)執(zhí)行的過濾器。該過濾器只對請求上下文中存在forward.to參數(shù)的請求進(jìn)行處理逢倍，即用來處理路由規(guī)則中的forward本地跳轉(zhuǎn)配置。

post過濾器

• SendErrorFilter：它的執(zhí)行順序?yàn)?景图，是post階段第一個(gè)執(zhí)行的過濾器较雕。該過濾器僅在請求上下文中包含error.status_code參數(shù)（由之前執(zhí)行的過濾器設(shè)置的錯(cuò)誤編碼）并且還沒有被該過濾器處理過的時(shí)候執(zhí)行。而該過濾器的具體邏輯就是利用請求上下文中的錯(cuò)誤信息來組織成一個(gè)forward到API網(wǎng)關(guān)/error錯(cuò)誤端點(diǎn)的請求來產(chǎn)生錯(cuò)誤響應(yīng)挚币。
• SendResponseFilter：它的執(zhí)行順序?yàn)?000亮蒋，是post階段最后執(zhí)行的過濾器。該過濾器會(huì)檢查請求上下文中是否包含請求響應(yīng)相關(guān)的頭信息妆毕、響應(yīng)數(shù)據(jù)流或是響應(yīng)體慎玖，只有在包含它們其中一個(gè)的時(shí)候就會(huì)執(zhí)行處理邏輯。而該過濾器的處理邏輯就是利用請求上下文的響應(yīng)信息來組織需要發(fā)送回客戶端的響應(yīng)內(nèi)容笛粘。

這里不列出具體代碼了趁怔，讀者可自行根據(jù)類名來查看源碼了解詳細(xì)處理過程。下圖是對上述過濾器根據(jù)順序薪前、名稱润努、功能、類型做了綜合的整理示括，可以幫助我們在自定義過濾器或是擴(kuò)展過濾器的時(shí)候用來參考并全面地考慮整個(gè)請求生命周期的處理過程铺浇。

核心過濾器總結(jié)

本文節(jié)選自《Spring Cloud微服務(wù)實(shí)戰(zhàn)》，部分稍做加工垛膝，轉(zhuǎn)載請注明出處

本文由 程序猿DD-翟永超 創(chuàng)作鳍侣，采用 CC BY 3.0 CN協(xié)議 進(jìn)行許可丁稀。 可自由轉(zhuǎn)載、引用倚聚，但需署名作者且注明文章出處线衫。
原文首發(fā)于：http://blog.didispace.com/spring-cloud-source-zuul/