Spring中如何使用责任链模式
关于责任链模式，其有两种形式，一种是通过外部调用的方式对链的各个节点调用进行控制，从而进行链的各个节点之间的切换；另一种是链的每个节点自由控制是否继续往下传递链的进度，这种比较典型的使用方式就是Netty中的责任链模式。本文主要讲解我们如何在Spring中使用这两种责任链模式。
1. 外部控制模式
对于外部控制的方式，这种方式比较简单，链的每个节点只需要专注于各自的逻辑即可，而当前节点调用完成之后是否继续调用下一个节点，这个则由外部控制逻辑进行。这里我们以一个过滤器的实现逻辑为例进行讲解，在平常工作中，我们经常需要根据一系列的条件对某个东西进行过滤，比如任务服务的设计，在执行某个任务时，其需要经过诸如时效性检验，风控拦截，任务完成次数等过滤条件的检验之后才能判断当前任务是否能够执行，只有在所有的过滤条件都完成之后，我们才能执行该任务。那么这里我们就可以抽象出一个Filter接口，其设计如下：
public interface Filter {
/**
* 用于对各个任务节点进行过滤
*/
boolean filter(Task task);
}
这里的Filter.filter()方法只有一个参数Task，主要就是控制当前task是否需要被过滤掉，其有一个boolean类型的返回值，通过该返回值以告知外部控制逻辑是否需要将该task过滤掉。对于该接口的子类，我们只需要将其声明为Spring所管理的一个bean即可：
// 时效性检验
@Component
public class DurationFilter implements Filter {
@Override
public boolean filter(Task task) {
System.out.println("时效性检验");
return true;
}
}
// 风控拦截
@Component
public class RiskFilter implements Filter {
@Override
public boolean filter(Task task) {
System.out.println("风控拦截");
return true;
}
}
// 次数限制校验
@Component
public class TimesFilter implements Filter {
@Override
public boolean filter(Task task) {
System.out.println("次数限制检验");
return true;
}
}
上面我们模拟声明了三个Filter的子类，用于设计一系列的控制当前task是否需要被过滤的逻辑，结构上的逻辑其实比较简单，主要就是需要将其声明为Spring所管理的一个bean。下面是我们的控制逻辑:
@Service
public class ApplicationService {
@Autowired
private List<Filter> filters;
public void mockedClient() {
Task task = new Task(); // 这里task一般是通过数据库查询得到的
for (Filter filter : filters) {
if (!filter.filter(task)) {
return;
}
}
// 过滤完成，后续是执行任务的逻辑
}
}
在上述的控制逻辑中，对于过滤器的获取，只需要通过Spring的自动注入即可，这里注入的是一个List<Filter>，也就是说，如果我们有新的Filter实例需要参与责任链的过滤，只需要将其声明为一个Spring容器所管理的bean即可。
这种责任链设计方式的优点在于链的控制比较简单，只需要实现一个统一的接口即可，其基本上能够满足大部分的逻辑控制，但是对于某些需要动态调整链的需求其就无能为力了。比如在执行到某个节点之后需要动态的判断是否执行下一个节点，或者说要执行某些分叉的节点等等。这个时候我们就需要将链节点的传递工作交由各个节点进行。
2. 节点控制模式
对于节点控制调用的方式，其主要有三个控制点：Handler，HandlerContext和Pipeline。Handler中是用于编写具体的业务代码的；HandlerContext则主要是用于对Handler进行包裹，并且用于控制进行下一个节点的调用的；Pipeline则主要是用于控制整体的流程调用的，比如对于任务的执行，其有任务的查询，任务的过滤和执行任务等等流程，这些流程整体的逻辑控制就是由Pipeline来控制的，在每个流程中又包含了一系列的子流程，这些子流程则是由一个个的HandlerContext和Handler进行梳理的。这种责任链的控制方式整体逻辑如下图所示：
从图中可以看出，我们将整个流程通过Pipeline对象进行了抽象，这里主要分为了三个步骤：查询task，过滤task和执行task。在每个步骤中，我们都使用了一系列的链式调用。图中需要注意的是，在每次调用链的下一个节点的时候，我们都是通过具体的Handler进行的，也就是说是否进行链的下一个节点的调用，我们是通过业务实现方来进行动态控制的。
关于该模式的设计，我们首先需要强调的就是Handler接口的设计，其设计如下所示：
public interface Handler {
/**
* 处理接收到前端请求的逻辑
*/
default void receiveTask(HandlerContext ctx, Request request) {
ctx.fireTaskReceived(request);
}
/**
* 查询到task之后，进行task过滤的逻辑
*/
default void filterTask(HandlerContext ctx, Task task) {
ctx.fireTaskFiltered(task);
}
/**
* task过滤完成之后，处理执行task的逻辑
*/
default void executeTask(HandlerContext ctx, Task task) {
ctx.fireTaskExecuted(task);
}
/**
* 当实现的前面的方法抛出异常时，将使用当前方法进行异常处理，这样可以将每个handler的异常
* 都只在该handler内进行处理，而无需额外进行捕获
*/
default void exceptionCaught(HandlerContext ctx, Throwable e) {
throw new RuntimeException(e);
}
/**
* 在整个流程中，保证最后一定会执行的代码，主要是用于一些清理工作
*/
default void afterCompletion(HandlerContext ctx) {
ctx.fireAfterCompletion(ctx);
}
}
这里的Handler接口主要是对具体的业务逻辑的一个抽象，对于该Handler主要有如下几点需要说明：
-
在前面图中
Pipeline的每个层级中对应于该Handler都有一个方法，在需要进行具体的业务处理的时候，用户只需要声明一个bean，具体实现某个当前业务所需要处理的层级的方法即可，而无需管其他的逻辑； -
每个层级的方法中，第一个参数都是一个
HandlerContext类型的，该参数主要是用于进行流程控制的，比如是否需要将当前层级的调用链往下继续传递，这里链的传递工作主要是通过ctx.fireXXX()方法进行的； -
每个层级的方法都有默认实现，默认实现方式就是将链的调用继续往下进行传递；
-
每个
Handler中都有一个exceptionCaught()方法和afterCompletion()方法，这两个方法分别用于异常控制和所有调用完成后的清理的，这里的异常控制主要是捕获当前Handler中的异常，而afterCompletion()方法则会保证在所有步骤之后一定会进行调用的，无论是否抛出异常； -
对于
Handler的使用，我们希望能够达到的目的是，适用方只需要实现该接口，并且使用某个注解来将其标志为Spring的bean即可，而无需管整个Pipeline的组装和流程控制。通过这种方式，我们即保留了每个Spring提供给我们的便利性，也使用了Pipeline模式的灵活性。
上述流程代码中，我们注意到，每个层级的方法中都有一个HandlerContext用于传递链相关的控制信息，这里我们来看一下其源码：
@Component
@Scope("prototype")
public class HandlerContext {
HandlerContext prev;
HandlerContext next;
Handler handler;
private Task task;
public void fireTaskReceived(Request request) {
invokeTaskReceived(next(), request);
}
/**
* 处理接收到任务的事件
*/
static void invokeTaskReceived(HandlerContext ctx, Request request) {
if (ctx != null) {
try {
ctx.handler().receiveTask(ctx, request);
} catch (Throwable e) {
ctx.handler().exceptionCaught(ctx, e);
}
}
}
public void fireTaskFiltered(Task task) {
invokeTaskFiltered(next(), task);
}
/**
* 处理任务过滤事件
*/
static void invokeTaskFiltered(HandlerContext ctx, Task task) {
if (null != ctx) {
try {
ctx.handler().filterTask(ctx, task);
} catch (Throwable e) {
ctx.handler().exceptionCaught(ctx, e);
}
}
}
public void fireTaskExecuted(Task task) {
invokeTaskExecuted(next(), task);
}
/**
* 处理执行任务事件
*/
static void invokeTaskExecuted(HandlerContext ctx, Task task) {
if (null != ctx) {
try {
ctx.handler().executeTask(ctx, task);
} catch (Exception e) {
ctx.handler().exceptionCaught(ctx, e);
}
}
}
public void fireAfterCompletion(HandlerContext ctx) {
invokeAfterCompletion(next());
}
static void invokeAfterCompletion(HandlerContext ctx) {
if (null != ctx) {
ctx.handler().afterCompletion(ctx);
}
}
private HandlerContext next() {
return next;
}
private Handler handler() {
return handler;
}
}
在HandlerContext中，我们需要说明如下几点：
-
之前
Handler接口默认实现的ctx.fireXXX()方法，在这里都委托给了对应的invokeXXX()方法进行调用，而且我们需要注意到，在传递给invokeXXX()方法的参数里，传入的HandlerContext对象都是通过next()方法获取到的。也就是说我们在Handler中调用ctx.fireXXX()方法时，都是在调用当前handler的下一个handler对应层级的方法，通过这种方式我们就实现了链的往下传递。 -
在上一点中我们说到，在某个
Handler中如果想让链往下传递，只需要调用ctx.fireXXX()方法即可，也就是说，如果我们在某个Handler中，如果根据业务，当前层级已经调用完成，而无需调用后续的Handler，那么我们就不需要调用ctx.fireXXX()方法即可； -
在
HandlerContext中，我们也实现了invokeXXX()方法，该方法的主要作用是供给外部的Pipeline进行调用的，以开启每个层级的链； -
在每个
invokeXXX()方法中，我们都使用try…catch将当前层级的调用抛出的异常给捕获了，然后调用ctx.handler().exceptionCaught()方法处理该异常，这也就是我们前面说的，如果想处理当前Handler中的异常，只需要实现该Handler中的exceptionCaught()方法即可，异常捕获流程就是在这里的HandlerContext中进行处理的； -
在
HandlerContext的声明处，我们需要注意到，其使用了@Component和@Scope("prototype")注解进行标注了，这说明我们的HandlerContext是由Spring所管理的一个bean，并且由于我们每一个Handler实际上都由一个HandlerContext维护着，所以这里必须声明为prototype类型。通过这种方式，我们的HandlerContext也就具备了诸如Spring相关的bean的功能，也就能够根据业务需求进行一些额外的处理了；
前面我们讲解了Handler和HandlerContext的具体实现，以及实现的过程中需要注意的问题，下面我们就来看一下进行流程控制的Pipeline是如何实现的，如下是Pipeline接口的定义：
public interface Pipeline {
Pipeline fireTaskReceived();
Pipeline fireTaskFiltered();
Pipeline fireTaskExecuted();
Pipeline fireAfterCompletion();
}
这里 主要是定义了一个Pipeline接口，该接口定义了一系列的层级调用，是每个层级的入口方法。如下是该接口的一个实现类：
@Component("pipeline")
@Scope("prototype")
public class DefaultPipeline implements Pipeline, ApplicationContextAware, InitializingBean {
// 创建一个默认的handler，将其注入到首尾两个节点的HandlerContext中，其作用只是将链往下传递
private static final Handler DEFAULT_HANDLER = new Handler() {};
// 将ApplicationContext注入进来的主要原因在于，HandlerContext是prototype类型的，因而需要
// 通过ApplicationContext.getBean()方法来获取其实例
private ApplicationContext context;
// 创建一个头结点和尾节点，这两个节点内部没有做任何处理，只是默认的将每一层级的链往下传递，
// 这里头结点和尾节点的主要作用就是用于标志整个链的首尾，所有的业务节点都在这两个节点中间
private HandlerContext head;
private HandlerContext tail;
// 用于业务调用的request对象，其内部封装了业务数据
private Request request;
// 用于执行任务的task对象
private Task task;
// 最初始的业务数据需要通过构造函数传入，因为这是驱动整个pipeline所需要的数据，
// 一般通过外部调用方的参数进行封装即可
public DefaultPipeline(Request request) {
this.request = request;
}
// 这里我们可以看到，每一层级的调用都是通过HandlerContext.invokeXXX(head)的方式进行的，
// 也就是说我们每一层级链的入口都是从头结点开始的，当然在某些情况下，我们也需要从尾节点开始链
// 的调用，这个时候传入tail即可。
@Override
public Pipeline fireTaskReceived() {
HandlerContext.invokeTaskReceived(head, request);
return this;
}
// 触发任务过滤的链调用
@Override
public Pipeline fireTaskFiltered() {
HandlerContext.invokeTaskFiltered(head, task);
return this;
}
// 触发任务执行的链执行
@Override
public Pipeline fireTaskExecuted() {
HandlerContext.invokeTaskExecuted(head, task);
return this;
}
// 触发最终完成的链的执行
@Override
public Pipeline fireAfterCompletion() {
HandlerContext.invokeAfterCompletion(head);
return this;
}
// 用于往Pipeline中添加节点的方法，读者朋友也可以实现其他的方法用于进行链的维护
void addLast(Handler handler) {
HandlerContext handlerContext = newContext(handler);
tail.prev.next = handlerContext;
handlerContext.prev = tail.prev;
handlerContext.next = tail;
tail.prev = handlerContext;
}
// 这里通过实现InitializingBean接口来达到初始化Pipeline的目的，可以看到，这里初始的时候
// 我们通过ApplicationContext实例化了两个HandlerContext对象，然后将head.next指向tail节点，
// 将tail.prev指向head节点。也就是说，初始时，整个链只有头结点和尾节点。
@Override
public void afterPropertiesSet() throws Exception {
head = newContext(DEFAULT_HANDLER);
tail = newContext(DEFAULT_HANDLER);
head.next = tail;
tail.prev = head;
}
// 使用默认的Handler初始化一个HandlerContext
private HandlerContext newContext(Handler handler) {
HandlerContext context = this.context.getBean(HandlerContext.class);
context.handler = handler;
return context;
}
// 注入ApplicationContext对象