Zuul詳解
官方文檔：https://github.com/Netflix/zuul/wiki/How-it-Works
Zuul的中心是一系列過濾器，能夠在HTTP請求和響應的路由過程中執行一系列操作。
以下是Zuul過濾器的主要特征：
- 類型：通常在應用過濾器時在路由流程中定義階段（盡管它可以是任何自定義字符串）
- 執行順序：在類型中應用，定義跨多個過濾器的執行順序
- 標准：執行過濾器所需的條件
- 操作：滿足條件時要執行的操作
Zuul提供了一個動態讀取，編譯和運行這些過濾器的框架。過濾器不直接相互通信 - 而是通過RequestContext共享狀態，RequestContext對每個請求都是唯一的。
過濾器目前用Groovy編寫，盡管Zuul支持任何基於JVM的語言。每個Filter的源代碼都寫入Zuul服務器上的一組指定目錄，這些目錄會定期輪詢更改。更新的過濾器從磁盤讀取，動態編譯到正在運行的服務器中，並由Zuul為每個后續請求調用。
過濾類型
Zuul大部分功能都是通過過濾器來實現的。Zuul中定義了四種標准過濾器類型，這些過濾器類型對應於請求的典型生命周期：
- PRE：這種過濾器在請求被路由調用之前調用。我們可利用這種過濾器實現身份驗證、再集群中選擇請求的微服務、記錄調試信息等。
- ROUTING：這種過濾器將請求路由到微服務。用於構建發送給微服務的請求，並使用
Apache HttpClient或Netflix Ribbon構建和發送原始HTTP請求的位置。 - POST：請求在路由到微服務之后執行。示例包括向響應添加標准HTTP標頭、收集統計信息和指標、以及將響應從源傳輸到客戶端。
- ERROR：過濾器在其中一個階段發生錯誤時執行。
除了默認的過濾器類型，Zuul還允許我們創建自定義過濾器類型。例如，我們有一個自定義STATIC類型的過濾器，它直接在Zuul中生成響應，而不是將請求轉發到后端的微服務。
Zuul請求的生命周期
Zuul請求的生命周期如下圖所示，改圖詳細的描述了各種類型的過濾器執行順序。
常見的使用
/** * 過濾類型 */ filterType() { return FilterConstants.PRE_TYPE; } /** * 過濾順序 */ public int filterOrder() { return -4; } /** * 攔截需要過濾的請求 */ shouldFilter(){ …… } /** * 過濾需要做的處理 */ run(){ …… }
執行順序
- 1、按照filterType決定順序
Pre 優先 Post執行，此時filterOrder沒有作用。
- 2、filterType相同
filterOrder有作用，數字越小，越先執行。（負數也是這個規則，0和-1的話，-1先執行）
- 3、相同filterType,相同filterOrder，都執行，執行順序不清楚。
prefilter先執行了，post后執行了。
感覺不像是按照過濾請名稱排序的樣子。