zuul 的概念和原理
https://zhuanlan.zhihu.com/p/80372029
一、zuul是什麼
zuul 是netflix開源的一個API Gateway 伺服器, 本質上是一個web servlet應用。
Zuul 在雲平臺上提供動態路由,監控,彈性,安全等邊緣服務的框架。Zuul 相當於是裝置和 Netflix 流應用的 Web 網站後端所有請求的前門。
zuul的例子可以參考 netflix 在github上的 simple webapp,可以按照netflix 在github wiki 上文件說明來進行使用。
二、zuul的工作原理
1、過濾器機制
zuul的核心是一系列的filters, 其作用可以類比Servlet框架的Filter,或者AOP。
Zuul提供了一個框架,可以對過濾器進行動態的載入,編譯,執行。
Zuul的過濾器之間沒有直接的相互通訊,他們之間通過一個RequestContext的靜態類來進行資料傳遞的。RequestContext類中有ThreadLocal變數來記錄每個Request所需要傳遞的資料。
Zuul的過濾器是由Groovy寫成,這些過濾器檔案被放在Zuul Server上的特定目錄下面,Zuul會定期輪詢這些目錄,修改過的過濾器會動態的載入到Zuul Server中以便過濾請求使用。
Zuul大部分功能都是通過過濾器來實現的。Zuul中定義了四種標準過濾器型別,這些過濾器型別對應於請求的典型生命週期。
(1) PRE:這種過濾器在請求被路由之前呼叫。我們可利用這種過濾器實現身份驗證、在叢集中選擇請求的微服務、記錄除錯資訊等。
(2) ROUTING:這種過濾器將請求路由到微服務。這種過濾器用於構建傳送給微服務的請求,並使用Apache HttpClient或Netfilx Ribbon請求微服務。
(3) POST:這種過濾器在路由到微服務以後執行。這種過濾器可用來為響應新增標準的HTTP Header、收集統計資訊和指標、將響應從微服務傳送給客戶端等。
內建的特殊過濾器
zuul還提供了一類特殊的過濾器,分別為:StaticResponseFilter和SurgicalDebugFilter
StaticResponseFilter:StaticResponseFilter允許從Zuul本身生成響應,而不是將請求轉發到源。
SurgicalDebugFilter:SurgicalDebugFilter允許將特定請求路由到分隔的除錯叢集或主機。
自定義的過濾器
除了預設的過濾器型別,Zuul還允許我們建立自定義的過濾器型別。
例如,我們可以定製一種STATIC型別的過濾器,直接在Zuul中生成響應,而不將請求轉發到後端的微服務。
2、過濾器的生命週期
Zuul請求的生命週期如圖,該圖詳細描述了各種型別的過濾器的執行順序。
3、過濾器排程過程
4、動態載入過濾器
三、zuul 能做什麼?
Zuul可以通過載入動態過濾機制,從而實現以下各項功能:
- 驗證與安全保障: 識別面向各類資源的驗證要求並拒絕那些與要求不符的請求。
- 審查與監控: 在邊緣位置追蹤有意義資料及統計結果,從而為我們帶來準確的生產狀態結論。
- 動態路由: 以動態方式根據需要將請求路由至不同後端叢集處。
- 壓力測試: 逐漸增加指向叢集的負載流量,從而計算效能水平。
- 負載分配: 為每一種負載型別分配對應容量,並棄用超出限定值的請求。
- 靜態響應處理: 在邊緣位置直接建立部分響應,從而避免其流入內部叢集。
- 多區域彈性: 跨越AWS區域進行請求路由,旨在實現ELB使用多樣化並保證邊緣位置與使用者儘可能接近。
除此之外,Netflix公司還利用Zuul的功能通過金絲雀版本實現精確路由與壓力測試。
四、zuul 與應用的整合方式
1、ZuulServlet - 處理請求(排程不同階段的filters,處理異常等)ZuulServlet
類似SpringMvc的DispatcherServlet
,所有的Request都要經過ZuulServlet
的處理
三個核心的方法preRoute()
,route()
,postRoute()
,zuul對request處理邏輯都在這三個方法裡ZuulServlet
交給ZuulRunner
去執行。
由於ZuulServlet
是單例,因此ZuulRunner
也僅有一個例項。ZuulRunner
直接將執行邏輯交由FilterProcessor
處理,FilterProcessor
也是單例,其功能就是依據filterType執行filter的處理邏輯FilterProcessor
對filter的處理邏輯。
- 首先根據Type獲取所有輸入該Type的filter,
List<ZuulFilter> list
。 - 遍歷該list,執行每個filter的處理邏輯,
processZuulFilter(ZuulFilter filter)
RequestContext
對每個filter的執行狀況進行記錄,應該留意,此處的執行狀態主要包括其執行時間、以及執行成功或者失敗,如果執行失敗則對異常封裝後丟擲。- 到目前為止,zuul框架對每個filter的執行結果都沒有太多的處理,它沒有把上一filter的執行結果交由下一個將要執行的filter,僅僅是記錄執行狀態,如果執行失敗丟擲異常並終止執行。
2、ContextLifeCycleFilter - RequestContext 的生命週期管理
ContextLifecycleFilter的核心功能是為了清除RequestContext; 請求上下文RequestContext通過ThreadLocal儲存,需要在請求完成後刪除該物件。RequestContext
提供了執行filter Pipeline所需要的Context,因為Servlet是單例多執行緒,這就要求RequestContext即要執行緒安全又要Request安全。
context使用ThreadLocal
儲存,這樣每個w
一、zuul是什麼
zuul 是netflix開源的一個API Gateway 伺服器, 本質上是一個web servlet應用。
Zuul 在雲平臺上提供動態路由,監控,彈性,安全等邊緣服務的框架。Zuul 相當於是裝置和 Netflix 流應用的 Web 網站後端所有請求的前門。
zuul的例子可以參考 netflix 在github上的 simple webapp,可以按照netflix 在github wiki 上文件說明來進行使用。
二、zuul的工作原理
1、過濾器機制
zuul的核心是一系列的filters, 其作用可以類比Servlet框架的Filter,或者AOP。
zuul把Request route到 使用者處理邏輯 的過程中,這些filter參與一些過濾處理,比如Authentication,Load Shedding等。
Zuul提供了一個框架,可以對過濾器進行動態的載入,編譯,執行。
Zuul的過濾器之間沒有直接的相互通訊,他們之間通過一個RequestContext的靜態類來進行資料傳遞的。RequestContext類中有ThreadLocal變數來記錄每個Request所需要傳遞的資料。
Zuul的過濾器是由Groovy寫成,這些過濾器檔案被放在Zuul Server上的特定目錄下面,Zuul會定期輪詢這些目錄,修改過的過濾器會動態的載入到Zuul Server中以便過濾請求使用。
下面有幾種標準的過濾器型別:
Zuul大部分功能都是通過過濾器來實現的。Zuul中定義了四種標準過濾器型別,這些過濾器型別對應於請求的典型生命週期。
(1) PRE:這種過濾器在請求被路由之前呼叫。我們可利用這種過濾器實現身份驗證、在叢集中選擇請求的微服務、記錄除錯資訊等。
(2) ROUTING:這種過濾器將請求路由到微服務。這種過濾器用於構建傳送給微服務的請求,並使用Apache HttpClient或Netfilx Ribbon請求微服務。
(3) POST:這種過濾器在路由到微服務以後執行。這種過濾器可用來為響應新增標準的HTTP Header、收集統計資訊和指標、將響應從微服務傳送給客戶端等。
(4) ERROR:在其他階段發生錯誤時執行該過濾器。
內建的特殊過濾器
zuul還提供了一類特殊的過濾器,分別為:StaticResponseFilter和SurgicalDebugFilter
StaticResponseFilter:StaticResponseFilter允許從Zuul本身生成響應,而不是將請求轉發到源。
SurgicalDebugFilter:SurgicalDebugFilter允許將特定請求路由到分隔的除錯叢集或主機。
自定義的過濾器
除了預設的過濾器型別,Zuul還允許我們建立自定義的過濾器型別。
例如,我們可以定製一種STATIC型別的過濾器,直接在Zuul中生成響應,而不將請求轉發到後端的微服務。
2、過濾器的生命週期
Zuul請求的生命週期如圖,該圖詳細描述了各種型別的過濾器的執行順序。
3、過濾器排程過程
4、動態載入過濾器
三、zuul 能做什麼?
Zuul可以通過載入動態過濾機制,從而實現以下各項功能:
- 驗證與安全保障: 識別面向各類資源的驗證要求並拒絕那些與要求不符的請求。
- 審查與監控: 在邊緣位置追蹤有意義資料及統計結果,從而為我們帶來準確的生產狀態結論。
- 動態路由: 以動態方式根據需要將請求路由至不同後端叢集處。
- 壓力測試: 逐漸增加指向叢集的負載流量,從而計算效能水平。
- 負載分配: 為每一種負載型別分配對應容量,並棄用超出限定值的請求。
- 靜態響應處理: 在邊緣位置直接建立部分響應,從而避免其流入內部叢集。
- 多區域彈性: 跨越AWS區域進行請求路由,旨在實現ELB使用多樣化並保證邊緣位置與使用者儘可能接近。
除此之外,Netflix公司還利用Zuul的功能通過金絲雀版本實現精確路由與壓力測試。
四、zuul 與應用的整合方式
1、ZuulServlet - 處理請求(排程不同階段的filters,處理異常等)ZuulServlet
類似SpringMvc的DispatcherServlet
,所有的Request都要經過ZuulServlet
的處理
三個核心的方法preRoute()
,route()
,postRoute()
,zuul對request處理邏輯都在這三個方法裡ZuulServlet
交給ZuulRunner
去執行。
由於ZuulServlet
是單例,因此ZuulRunner
也僅有一個例項。ZuulRunner
直接將執行邏輯交由FilterProcessor
處理,FilterProcessor
也是單例,其功能就是依據filterType執行filter的處理邏輯FilterProcessor
對filter的處理邏輯。
- 首先根據Type獲取所有輸入該Type的filter,
List<ZuulFilter> list
。 - 遍歷該list,執行每個filter的處理邏輯,
processZuulFilter(ZuulFilter filter)
RequestContext
對每個filter的執行狀況進行記錄,應該留意,此處的執行狀態主要包括其執行時間、以及執行成功或者失敗,如果執行失敗則對異常封裝後丟擲。- 到目前為止,zuul框架對每個filter的執行結果都沒有太多的處理,它沒有把上一filter的執行結果交由下一個將要執行的filter,僅僅是記錄執行狀態,如果執行失敗丟擲異常並終止執行。
2、ContextLifeCycleFilter - RequestContext 的生命週期管理
ContextLifecycleFilter的核心功能是為了清除RequestContext; 請求上下文RequestContext通過ThreadLocal儲存,需要在請求完成後刪除該物件。RequestContext
提供了執行filter Pipeline所需要的Context,因為Servlet是單例多執行緒,這就要求RequestContext即要執行緒安全又要Request安全。
context使用ThreadLocal
儲存,這樣每個worker執行緒都有一個與其繫結的RequestContext
,因為worker僅能同時處理一個Request,這就保證了Request Context 即是執行緒安全的由是Request安全的。
3、GuiceFilter - GOOLE-IOC(Guice是Google開發的一個輕量級,基於Java5(主要運用泛型與註釋特性)的依賴注入框架(IOC)。Guice非常小而且快。)
4、StartServer - 初始化 zuul 各個元件 (ioc、外掛、filters、資料庫等)
5、FilterScriptManagerServlet - uploading/downloading/managing scripts, 實現熱部署
Filter原始碼檔案放在zuul 服務特定的目錄, zuul server會定期掃描目錄下的檔案的變化,動態的讀取\編譯\執行這些filter,
如果有Filter檔案更新,原始檔會被動態的讀取,編譯載入進入服務,接下來的Request處理就由這些新加入的filter處理。
orker執行緒都有一個與其繫結的RequestContext
,因為worker僅能同時處理一個Request,這就保證了Request Context 即是執行緒安全的由是Request安全的。
3、GuiceFilter - GOOLE-IOC(Guice是Google開發的一個輕量級,基於Java5(主要運用泛型與註釋特性)的依賴注入框架(IOC)。Guice非常小而且快。)
4、StartServer - 初始化 zuul 各個元件 (ioc、外掛、filters、資料庫等)
5、FilterScriptManagerServlet - uploading/downloading/managing scripts, 實現熱部署
Filter原始碼檔案放在zuul 服務特定的目錄, zuul server會定期掃描目錄下的檔案的變化,動態的讀取\編譯\執行這些filter,
如果有Filter檔案更新,原始檔會被動態的讀取,編譯載入進入服務,接下來的Request處理就由這些新加入的filter處理。