任何成熟的架構都是有生命週期的，zuul也是這樣。一起了解下。
原始碼：https://github.com/limingios/netFuture/tree/master/原始碼/『網際網路架構』軟體架構-zuul微服務閘道器（下）（102）/
（一）zuul請求的生命週期
流程客戶端HTTP發來一個請求。spring框架經常使用會提到攔截器，過濾器，zuul也是如此，定製化微服務。通過前置過濾器"pre fiters" ，"routing fiters"訪問後端的微服務，"post fiters"返回給客戶端（二）zuul過濾器使用及詳解
過濾器(filter)是zuul的核心元件zuul大部分功能都是通過過濾器來實現的。 zuul中定義了4種標準過濾器型別，這些過濾器型別對應於請求的典型生命週期。
PRE這種過濾器在請求被路由之前呼叫。可利用這種過濾器實現身份驗證、在叢集中選擇請求的微服務、記錄除錯資訊等。
ROUTING這種過濾器將請求路由到微服務。這種過濾器用於構建傳送給微服務的請求，並使用 Apache HttpCIient或 Netfilx Ribbon請求微服務。
POST這種過濾器在路由到微服務以後執行。這種過濾器可用來為響應新增標準的 HTTP Header、收集統計資訊和指標、將響應從微服務傳送給客戶端等。
ERROR在其他階段發生錯誤時執行該過濾器。
原始碼08-ms-gateway-zuul-filter
由程式碼可知，自定義的 zuul Filter需實現以下幾個方法。
filterType返回過濾器的型別。有 pre、 route、 post、 error等幾種取值，分別對應上文的幾種過濾器。詳細可以參考 com.netflix.zuul.ZuulFilter.filterType()中的註釋。
filter0rder返回一個 int值來指定過濾器的執行順序，不同的過濾器允許返回相同的數字。
shouldFilter返回一個 boolean值來判斷該過濾器是否要執行， true表示執行， false表示不執行。
run過濾器的具體邏輯。本例中讓它列印了請求的 HTTP方法以及請求的地址。
程式碼示例1.08-ms-provider-user
2.08-ms-gateway-zuul-filter
3.08-ms-eureka-server
4.08-ms-consumer-order-ribbon
直接原始碼執行就可以了，上幾次文章都演示了，這次不演示了。直接main方法執行起來就可以了。
執行專案訪問地址：http://localhost:8040/microservice-provider-user/getIpAndPort 可以看到zuul服務的後臺正常列印了run方法裡的日誌。
禁用zuul過濾器Spring Cloud預設為Zuul編寫並啟用了一些過濾器，例如DebugFilter、
FormBodyWrapperFilter等，這些過濾器都存放在spring-cloud-netflix-core這個jar包裡，一些場景下，想要禁用掉部分過濾器，該怎麼辦呢？
只需在application.yml裡設定
zuul.<SimpleClassName>.<filterType>.disable=true
例如，要禁用上面我們寫的過濾器，這樣配置就行了：zuul.PreRequestLogFilter.pre.disable=truezuul的容錯與回退老鐵！如果zuul代理的後端微服務掛了會出現什麼情況？zuul預設已經整合了hystrix，也就是zuul也是可以利用hystrix做降級容錯處理的，但是zuul監控的粒度是微服務級別，而不是某個API。
原始碼：08-ms-gateway-zuul-fallback
編寫zuul的降級回退類<MyFallbackProvider>如下
啟動專案
1.08-ms-gateway-zuul-fallback
2.08-ms-eureka-server
3.08-ms-consumer-order-ribbon
注意：這裡不啟動記住不啟動 08-ms-provider-user
關閉zuul代理的使用者微服務，再執行本專案，訪問地址：http://localhost:8040/microservice-provider-user/getIpAndPort，將會返回如下內容
（三）zuul的高可用
zuul客戶端也註冊到了Eureka Server上這種情況下，Zuul的高可用非常簡單，只需將多個Zuul節點註冊到Eureka Server上，就可實現Zuul的高可用。此時，Zuul的高可用與其他微服務的高可用沒什麼區別。
zuul客戶端未註冊到Eureka Server上當zuul客戶端也註冊到Eureka Server上時，只需部署多個Zuul節點即可實現其高可用。zuul客戶端會自動從Eureka Server中查詢zuul Server的列表，並使用Ribbon負載均衡地請求Zuul叢集。
現實中，這種場景往往更常見，例如，zuul客戶端是一個手機APP——我們不可能讓所有的手機終端都註冊到Eureka Server上。這種情況下，我們可藉助一個額外的負載均衡器來實現Zuul的高可用，例如Nginx、HAProxy、F5等。
zuul客戶端將請求傳送到負載均衡器，負載均衡器將請求轉發到其代理的其中一個zuul節點。這樣，就可以實現Zuul的高可用。
PS：zuul 作為閘道器這麼重要的角色，高可用是非常有必要的。但是通常來說閘道器所面對的請求應該的是來於外部，所以雖然說閘道器可以註冊到Eureka Server上，但是外部的客戶端數量眾多，是不可能向Eureka Server註冊的。那麼要實現高可用的，要麼在閘道器前面再架一個前置代理（如Nginx）。