責任鏈模式實踐之Zuul責任鏈模式

 

責任鏈模式實踐之Zuul責任鏈模式

 

一，什麼是責任鏈模式

 

責任鏈（Chain of Responsibility）模式的定義：爲了避免請求發送者與多個請求處理者耦合在一起，將所有請求的處理者通過前一對象記住其下一個對象的引用而連成一條鏈；當有請求發生時，可將請求沿着這條鏈傳遞，直到有對象處理它爲止。

注意：責任鏈模式也叫職責鏈模式。

在責任鏈模式中，客戶只需要將請求發送到責任鏈上即可，無須關心請求的處理細節和請求的傳遞過程，所以責任鏈將請求的發送者和請求的處理者解耦了。

 

二，ZuulFilter

 

ZuulFilter類是Zuul責任鏈模式的實現基礎。

ZuulFilter是一個抽象類。ZuulFilter實現了IZuulFilter接口、Comparable接口。

 

繼承ZuulFilter的類需要實現下面4個方法：

filterType()：過濾器類型，可選值有4個，pre、route、post、error。

filterOrder()：過濾器執行的優先級。當某種類型的過濾器有多個時，根據優先級依次執行。

shouldFilter()：判斷過濾器是否需要執行。可以通過這個方法來限制過濾器的執行條件。

run()：過濾器的具體執行邏輯。

 

三，Zuul責任鏈模式的實現

 

Zuul責任鏈模式的實現和Zookeeper責任鏈模式的區別還是很大的。

ZuulFilter的實現有很多，這些實現類構成了Zuul的責任鏈。如何執行呢？

 

首先，Zuul把過濾器鏈分成了4類：pre過濾器、route過濾器、post過濾器、error過濾器。這個劃分的依據其實就是http請求的流程。ZuulFilter的實現類必須指定是哪種類型的過濾器，也就是filterType。ZuulFilter的實現了還必須指定過濾器的執行順序，也就是filterOrder。

 

接着ZuulServlet會依次執行pre過濾器、route過濾器、post過濾器，如果執行過程中出現異常，則執行error過濾器。注意這裏的執行順序：pre過濾器 -> route過濾器 -> post過濾器。

 

最後ZuulServlet把請求交給ZuulRunner，ZuulRunner再把請求交給FilterProcessor，FilterProcessor會根據類型遍歷所有的過濾器，然後循環調用執行。對於同一類型的過濾器而言，filterOrder的值越小，越先執行。

 

四，責任鏈模式對比：Zookeeper責任鏈模式和Zuul責任鏈模式

 

在對比二者之前我們先來看看這兩者都是做什麼的？

Zookeeper責任鏈模式：處理Zookeeper客戶端請求。

Zuul責任鏈模式：攔截客戶端請求並轉發給目標微服務。

 

1，是否解藕

 

是。Zookeeper責任鏈模式藉助阻塞隊列LinkedBlockingQueue來解藕。Zuul責任鏈模式藉助全局上下文RequestContext來解藕。

 

2，執行順序

 

Zookeeper責任鏈模式的執行順序必須由上一處理器來指定，Zookeeper指定PrepRequestProcessor爲第一個執行的處理器，FinalRequestProcessor爲最後一個執行的處理器，所有中間執行的處理器必須由其他處理器來調用。

 

Zuul責任鏈模式的執行順序由filterType和filterOrder共同決定。不同的類型執行順序爲：pre過濾器 -> route過濾器 -> post過濾器。同一類型的執行順序爲：按filterOrder值大小排序，filterOrder值越小，越先執行。

 

3，擴展性

 

Zookeeper責任鏈模式的擴展是有一定的代價的，如果新增一個處理器，必須要改動之前的處理器邏輯，因爲新增的這個處理器必須顯示的在已有的處理器中調用。並且，Zookeeper責任鏈模式不支持開發者進行擴展。這個其實也可以理解，畢竟處理客戶端請求的邏輯屬於Zookeeper框架的內容，對於使用者而言，無須修改。

 

Zuul責任鏈模式支持開發者進行擴展，並且還可以禁用Zuul框架提供的某些過濾器。並且這個擴展也很簡單，只需要繼承ZuulFilter類，實現其中的4個方法即可。這樣看來，我們發現Zuul的責任鏈模式更加簡單，更加易於擴展。

 

其實我們這種對比，沒有太大的意義，可能最大的意義就是方便學習，方便記憶。但是我們回到原點，來看看：

 

它是做什麼的？

 

Zookeeper的出現要早於Spring Cloud，Zookeeper的責任鏈是爲了處理Zookeeper客戶端的請求。注意，這裏處理的是Zookeeper客戶端的請求，是一種CS架構，這種請求不是客戶請求，而是服務器請求。所以Zookeeper沒有充分的考慮擴展性，因爲這不是Zookeeper的主要設計目標。

 

Zuul的責任鏈模式其實是處理瀏覽器請求的，是一種BS架構。Zuul的本質其實就是我們java的filter過濾器，主要是攔截並處理瀏覽器請求。由於不同的項目對請求的處理差異性較大，比如有的系統對安全性要求較高，所以決定了Zuul要把一部分處理交給開發者，Zuul只實現一些基本的，公共的功能。

 

設計模式本身並沒有那麼神奇，濫用設計模式可能適得其反。設計模式只是一劑良藥，但是並不是包治百病。清楚要做什麼纔是根本，設計模式只是一個工具，切勿本末倒置。

 

用一個設計模式，是因爲清楚設計模式的缺點。不用，是因爲清楚它的優點。