责任链模式实践之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只实现一些基本的，公共的功能。

设计模式本身并没有那么神奇，滥用设计模式可能适得其反。设计模式只是一剂良药，但是并不是包治百病。清楚要做什么才是根本，设计模式只是一个工具，切勿本末倒置。

用一个设计模式，是因为清楚设计模式的缺点。不用，是因为清楚它的优点。