Question

在本章一开始的快速入门示例中，我们已经介绍了一部分关于请求过滤的功能。在本节中，我们将对Zuul的请求过滤器功能做进一步的介绍和总结。

过滤器

通过快速入门的示例，我们对于Zuul的第一印象通常是这样的：它包含了对请求的路由和过滤两个功能，其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础；而过滤器功能则负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础。然而实际上，路由功能在真正运行时，它的路由映射和请求转发都是由几个不同的过滤器完成的。其中，路由映射主要通过pre类型的过滤器完成，它将请求路径与配置的路由规则进行匹配，以找到需要转发的目标地址；而请求转发的部分则是由route类型的过滤器来完成，对pre类型过滤器获得的路由地址进行转发。所以，过滤器可以说是Zuul实现API网关功能最为核心的部件，每一个进入Zuul的HTTP请求都会经过一系列的过滤器处理链得到请求响应并返回给客户端。

在Spring Cloud Zuul中实现的过滤器必须包含4个基本特征：过滤类型、执行顺序、执行条件、具体操作。这些元素看起来非常熟悉，实际上它就是ZuulFilter接口中定义的4个抽象方法：

String filterType（）;

int filterOrder（）;

boolean shouldFilter（）;

Object run（）;

它们各自的含义与功能总结如下。

- filterType：该函数需要返回一个字符串来代表过滤器的类型，而这个类型就是在HTTP请求过程中定义的各个阶段。在Zuul中默认定义了4种不同生命周期的过滤器类型，具体如下所示。

- pre：可以在请求被路由之前调用。

- routing：在路由请求时被调用。

- post：在routing和error过滤器之后被调用。

- error：处理请求时发生错误时被调用。

- filterOrder：通过int值来定义过滤器的执行顺序，数值越小优先级越高。

- shouldFilter：返回一个boolean值来判断该过滤器是否要执行。我们可以通过此方法来指定过滤器的有效范围。

- run：过滤器的具体逻辑。在该函数中，我们可以实现自定义的过滤逻辑，来确定是否要拦截当前的请求，不对其进行后续的路由，或是在请求路由返回结果之后，对处理结果做一些加工等。

请求生命周期

对于Zuul中的过滤器类型filterType，我们已经做过一些简单的介绍。Zuul默认定义了4种不同的过滤器类型，它们覆盖了一个外部HTTP请求到达API网关，直到返回请求结果的全部生命周期。下图源自Zuul的官方WiKi中关于请求生命周期的图解，它描述了一个HTTP请求到达API网关之后，如何在各种不同类型的过滤器之间流转的详细过程。

从上图中我们可以看到，当外部HTTP请求到达API网关服务的时候，首先它会进入第一个阶段pre，在这里它会被pre类型的过滤器进行处理，该类型过滤器的主要目的是在进行请求路由之前做一些前置加工，比如请求的校验等。在完成了pre类型的过滤器处理之后，请求进入第二个阶段routing，也就是之前说的路由请求转发阶段，请求将会被routing类型过滤器处理。这里的具体处理内容就是将外部请求转发到具体服务实例上去的过程，当服务实例将请求结果都返回之后，routing 阶段完成，请求进入第三个阶段post。此时请求将会被post类型的过滤器处理，这些过滤器在处理的时候不仅可以获取到请求信息，还能获取到服务实例的返回信息，所以在 post 类型的过滤器中，我们可以对处理结果进行一些加工或转换等内容。另外，还有一个特殊的阶段error，该阶段只有在上述三个阶段中发生异常的时候才会触发，但是它的最后流向还是post类型的过滤器，因为它需要通过post过滤器将最终结果返回给请求客户端（对于error过滤器的处理，在Spring Cloud Zuul的过滤链中实际上有一些不同，后续我们在介绍核心过滤器时会做详细分析）。

核心过滤器

在Spring Cloud Zuul中，为了让API网关组件可以被更方便地使用，它在HTTP请求生命周期的各个阶段默认实现了一批核心过滤器，它们会在API网关服务启动的时候被自动加载和启用。我们可以在源码中查看和了解它们，它们定义于 spring-cloud netflix-core 模块的 org.springframework.cloud.netflix.zuul.filters包下。

如下图所示，在默认启用的过滤器中包含三种不同生命周期的过滤器，这些过滤器都非常重要，可以帮助我们理解Zuul对外部请求处理的过程，以及帮助我们在此基础上扩展过滤器去完成自身系统需要的功能。下面，我们将逐个对这些过滤器做详细的介绍。

pre过滤器

- ServletDetectionFilter：它的执行顺序为-3，是最先被执行的过滤器。该过滤器总是会被执行，主要用来检测当前请求是通过Spring的DispatcherServlet处理运行的，还是通过ZuulServlet来处理运行的。它的检测结果会以布尔类型保存在当前请求上下文的isDispatcherServletRequest参数中，这样在后续的过滤器中，我们就可以通过 RequestUtils.isDispatcherServletRequest（）和 RequestUtils.isZuulServletRequest（）方法来判断请求处理的源头，以实现后续不同的处理机制。一般情况下，发送到 API 网关的外部请求都会被 Spring的 DispatcherServlet 处理，除了通过/zuul/*路径访问的请求会绕过DispatcherServlet，被ZuulServlet处理，主要用来应对处理大文件上传的情况。另外，对于 ZuulServlet 的访问路径/zuul/*，我们可以通过zuul.servletPath参数来进行修改。

- Servlet30WrapperFilter：它的执行顺序为-2，是第二个执行的过滤器。目前的实现会对所有请求生效，主要为了将原始的httpServletRequest 包装成Servlet30RequestWrapper对象。

- FormBodyWrapperFilter：它的执行顺序为-1，是第三个执行的过滤器。该过滤器仅对两类请求生效，第一类是 Content-Type 为application/x-wwwform-urlencoded 的请求，第二类是 Content-Type 为multipart/formdata 并且是由 Spring 的 DispatcherServlet 处理的请求（用到了ServletDetectionFilter的处理结果）。而该过滤器的主要目的是将符合要求的请求体包装成FormBodyRequestWrapper对象。

- DebugFilter：它的执行顺序为1，是第四个执行的过滤器。该过滤器会根据配置参数zuul.debug.request和请求中的debug参数来决定是否执行过滤器中的操作。而它的具体操作内容则是将当前请求上下文中的 debugRouting 和debugRequest参数设置为true。由于在同一个请求的不同生命周期中都可以访问到这两个值，所以我们在后续的各个过滤器中可以利用这两个值来定义一些debug 信息，这样当线上环境出现问题的时候，可以通过请求参数的方式来激活这些debug信息以帮助分析问题。另外，对于请求参数中的debug参数，我们也可以通过zuul.debug.parameter来进行自定义。

- PreDecorationFilter：它的执行顺序为5，是pre阶段最后被执行的过滤器。该过滤器会判断当前请求上下文中是否存在forward.to和serviceId参数，如果都不存在，那么它就会执行具体过滤器的操作（如果有一个存在的话，说明当前请求已经被处理过了，因为这两个信息就是根据当前请求的路由信息加载进来的）。而它的具体操作内容就是为当前请求做一些预处理，比如，进行路由规则的匹配、在请求上下文中设置该请求的基本信息以及将路由匹配结果等一些设置信息等，这些信息将是后续过滤器进行处理的重要依据，我们可以通过 RequestContext.getCurrentContext（）来访问这些信息。另外，我们还可以在该实现中找到一些对http 头请求进行处理的逻辑，其中包含了一些耳熟能详的头域，比如X-Forwarded-Host、X-Forwarded-Port。另外，对于这些头域的记录是通过zuul.addProxyHeaders 参数进行控制的，而这个参数的默认值为true，所以Zuul在请求跳转时默认会为请求增加X-Forwarded-*头域，包括X-ForwardedHost、X-Forwarded-Port、X-Forwarded-For、X-Forwarded-Prefix、X-Forwarded-Proto。也可以通过设置zuul.addProxyHeaders=false关闭对这些头域的添加动作。

route过滤器

- RibbonRoutingFilter：它的执行顺序为10，是route阶段第一个执行的过滤器。该过滤器只对请求上下文中存在serviceId参数的请求进行处理，即只对通过serviceId配置路由规则的请求生效。而该过滤器的执行逻辑就是面向服务路由的核心，它通过使用Ribbon和Hystrix来向服务实例发起请求，并将服务实例的请求结果返回。

- SimpleHostRoutingFilter：它的执行顺序为100，是route阶段第二个执行的过滤器。该过滤器只对请求上下文中存在routeHost参数的请求进行处理，即只对通过 url 配置路由规则的请求生效。而该过滤器的执行逻辑就是直接向routeHost 参数的物理地址发起请求，从源码中我们可以知道该请求是直接通过httpclient包实现的，而没有使用Hystrix命令进行包装，所以这类请求并没有线程隔离和断路器的保护。

- SendForwardFilter：它的执行顺序为500，是route阶段第三个执行的过滤器。该过滤器只对请求上下文中存在forward.to参数的请求进行处理，即用来处理路由规则中的forward本地跳转配置。

post过滤器

- SendErrorFilter：它的执行顺序为0，是 post 阶段第一个执行的过滤器。该过滤器仅在请求上下文中包含 error.status_code 参数（由之前执行的过滤器设置的错误编码）并且还没有被该过滤器处理过的时候执行。而该过滤器的具体逻辑就是利用请求上下文中的错误信息来组成一个forward到API网关/error错误端点的请求来产生错误响应。

- SendResponseFilter：它的执行顺序为1000，是post阶段最后执行的过滤器。该过滤器会检查请求上下文中是否包含请求响应相关的头信息、响应数据流或是响应体，只有在包含它们其中一个的时候执行处理逻辑。而该过滤器的处理逻辑就是利用请求上下文的响应信息来组织需要发送回客户端的响应内容。

下图对上述过滤器根据顺序、名称、功能、类型做了综合整理，可以帮助我们在自定义过滤器或是扩展过滤器的时候用来参考并全面地考虑整个请求生命周期的处理过程。

异常处理

通过上面请求生命周期和核心过滤器的介绍，我们会发现在核心过滤器中并没有实现error阶段的过滤器。那么当过滤器出现异常的时候需要如何处理呢？我们不妨在快速入门示例中做一个简单的试验，来看看过滤器中的异常需要被如何处理。

首先，我们尝试创建一个pre类型的过滤器，并在该过滤器的run方法实现中抛出一个异常。比如下面的实现，在 run 方法中调用的 doSomething 方法将抛出RuntimeException异常。

@Component

public class ThrowExceptionFilter extends ZuulFilter {

private static Logger log=

LoggerFactory.getLogger（ThrowExceptionFilter.class）;

@Override

public String filterType（）{

return "pre";

}

@Override

public int filterOrder（）{

return 0;

}

@Override

public boolean shouldFilter（）{

return true;

}

@Override

public Object run（）{

log.info（"This is a pre filter,it will throw a RuntimeException"）;

doSomething（）;

return null;

}

private void doSomething（）{

throw new RuntimeException（"Exist some errors..."）;

}

}

注意在该类的定义上添加@Component注解，让Spring能够创建该过滤器实例，或者也可以像快速入门的例子中那样使用@Bean注解在应用主类中为其创建实例。

在添加了上面的过滤器之后，我们可以将该应用以及之前的相关应用运行起来，并根据网关配置的路由规则访问服务接口，比如http://localhost:5555/api-a/hello。此时我们会发现，在API网关服务的控制台中输出了ThrowExceptionFilter的过滤逻辑中的日志信息，但是并没有输出任何异常信息，同时发起的请求也没有获得任何响应结果。为什么会出现这样的情况呢？我们又该如何在过滤器中处理异常呢？翻遍 Spring Cloud Zuul的文档以及Netflix Zuul的Wiki都没有找到相关的内容，但是这个问题却又是开发过程中普遍存在的。所以在本节中，我们将详细分析核心过滤器的异常处理机制以及如何在自定义过滤器中处理异常等内容。

try-catch处理

回想一下，我们在上一节中介绍的所有核心过滤器，是否记得有一个 post 过滤器SendErrorFilter是用来处理异常信息的？根据正常的处理流程，该过滤器会处理异常信息，那么这里没有出现任何异常信息说明很有可能就是这个过滤器没有被执行。所以，不妨来详细看看SendErrorFilter的shouldFilter函数：

public boolean shouldFilter（）{

RequestContext ctx=RequestContext.getCurrentContext（）;

return ctx.containsKey（"error.status_code"）&& ! ctx.getBoolean（SEND_ERROR_FILTER_RAN,false）;

}

可以看到，该方法的返回值中有一个重要的判断依据ctx.containsKey（"error.status_code"），也就是说请求上下文中必须有error.status_code参数，我们实现的 ThrowExceptionFilter 中并没有设置这个参数，所以自然不会进入SendErrorFilter 过滤器的处理逻辑。那么如何使用这个参数呢？可以看一下 route类型的几个过滤器，由于这些过滤器会对外发起请求，所以肯定会有异常需要处理，比如RibbonRoutingFilter的run方法实现如下：

public Object run（）{

RequestContext context=RequestContext.getCurrentContext（）;

this.helper.addIgnoredHeaders（）;

try {

RibbonCommandContext commandContext=buildCommandContext（context）;

ClientHttpResponse response=forward（commandContext）;

setResponse（response）;

return response;

}

catch（ZuulException ex）{

context.set（ERROR_STATUS_CODE,ex.nStatusCode）;

context.set（"error.message",ex.errorCause）;

context.set（"error.exception",ex）;

}

catch（Exception ex）{

context.set（"error.status_code",HttpServletResponse.SC_INTERNAL_SERVER_ERROR）;

context.set（"error.exception",ex）;

}

return null;

}

可以看到，整个发起请求的逻辑都采用了try-catch块处理。在catch异常的处理逻辑中并没有做任何输出操作，而是向请求上下文中添加了一些error相关的参数，主要有下面三个参数。

- error.status_code：错误编码。

- error.exception:Exception异常对象。

- error.message：错误信息。

其中，error.status_code参数就是SendErrorFilter过滤器用来判断是否需要执行的重要参数。分析到这里，实现异常处理的大致思路就开始明朗了，我们可以参考RibbonRoutingFilter的实现对ThrowExceptionFilter的run方法做一些异常处理的改造，具体如下：

public Object run（）{

log.info（"This is a pre filter,it will throw a RuntimeException"）;

RequestContext ctx=RequestContext.getCurrentContext（）;

try {

doSomething（）;

} catch（Exception e）{

ctx.set（"error.status_code",HttpServletResponse.SC_INTERNAL_SERVER_ERROR）;

ctx.set（"error.exception",e）;

}

return null;

}

通过上面的改造之后，我们再尝试访问之前的接口，这个时候我们可以得到如下响应内容：

{

"timestamp": 1481674980376,

"status": 500,

"error": "Internal Server Error",

"exception": "java.lang.RuntimeException",

"message": "Exist some errors..."

}

此时，异常信息已经被SendErrorFilter过滤器正常处理并返回给客户端了，同时在网关的控制台中也输出了异常信息。从返回的响应信息中，可以看到几个之前我们在请求上下文中设置的内容，它们的对应关系如下所示。

- status：对应error.status_code参数的值。

- exception：对应error.exception参数中Exception的类型。

- message：对应error.exception参数中Exception的message信息。对于message的信息，我们在过滤器中还可以通过ctx.set（"error.message","自定义异常消息"）；来定义更友好的错误信息。SendErrorFilter 会优先取error.message作为返回的message内容，如果没有的话才会使用Exception中的message信息。

ErrorFilter处理

通过上面的分析与实验，我们已经知道如何在过滤器中正确处理异常，让错误信息能够顺利地流转到后续的SendErrorFilter过滤器来组织和输出。但是，即使我们不断强调要在过滤器中使用 try-catch 来处理业务逻辑并向请求上下文中添加异常信息，但是不可控的人为因素、意料之外的程序因素等，依然会使得一些异常从过滤器中抛出，对于意外抛出的异常又会导致没有控制台输出也没有任何响应信息的情况出现，那么是否有什么好的方法来为这些异常做一个统一的处理呢？

这个时候，我们就可以用到 error 类型的过滤器了。由于在请求生命周期的 pre、route、post三个阶段中有异常抛出的时候都会进入error阶段的处理，所以可以通过创建一个error类型的过滤器来捕获这些异常信息，并根据这些异常信息在请求上下文中注入需要返回给客户端的错误描述。这里我们可以直接沿用在 try-catch 处理异常信息时用的那些error参数，这样就可以让这些信息被SendErrorFilter捕获并组织成响应消息返回给客户端。比如，下面的代码就实现了这里所描述的一个过滤器：

public class ErrorFilter extends ZuulFilter {

Logger log=LoggerFactory.getLogger（ErrorFilter.class）;

@Override

public String filterType（）{

return "error";

}

@Override

public int filterOrder（）{

return 10;

}

@Override

public boolean shouldFilter（）{

return true;

}

@Override

public Object run（）{

RequestContext ctx=RequestContext.getCurrentContext（）;

Throwable throwable=ctx.getThrowable（）;

log.error（"this is a ErrorFilter : {}",throwable.getCause（）.getMessage（））;

ctx.set（"error.status_code",HttpServletResponse.SC_INTERNAL_SERVER_ERROR）;

ctx.set（"error.exception",throwable.getCause（））;

return null;

}

}

在将该过滤器加入API网关服务之后，我们可以尝试使用之前介绍try-catch处理时实现的 ThrowExceptionFilter（不包含异常处理机制的代码），让该过滤器能够抛出异常。这个时候我们再通过API网关来访问服务接口。此时，我们就可以在控制台中看到ThrowExceptionFilter过滤器抛出的异常信息，并且请求响应中也能获得如下的错误信息内容，而不是什么信息都没有的情况了。

{

"timestamp": 1481674993561,

"status": 500,

"error": "Internal Server Error",

"exception": "java.lang.RuntimeException",

"message": "Exist some errors..."

}

不足与优化

到这里，我们已经基本掌握了在核心过滤器处理逻辑之下，对自定义过滤器中处理异常的两种基本解决方法：一种是通过在各个阶段的过滤器中增加 try-catch 块，实现过滤器内部的异常处理；另一种是利用error类型过滤器的生命周期特性，集中处理pre、route、post阶段抛出的异常信息。通常情况下，我们可以将这两种手段同时使用，其中第一种是对开发人员的基本要求；而第二种是对第一种处理方式的补充，以防止意外情况的发生。

这样的异常处理机制看似已经完美，但是如果在多一些应用实践或源码分析之后，我们会发现依然存在一些不足。下面，我们不妨跟着源码来看看，到底上面的方案还有哪些不足之处需要注意和进一步优化。先来看看外部请求到达API网关服务之后，各个阶段的过滤器是如何进行调度的：

try {

preRoute（）;

} catch（ZuulException e）{

error（e）;

postRoute（）;

return;

}

try {

route（）;

} catch（ZuulException e）{

error（e）;

postRoute（）;

return;

}

try {

postRoute（）;

} catch（ZuulException e）{

error（e）;

return;

}

上面的代码源自com.netflix.zuul.http.ZuulServlet的service方法实现，它定义了Zuul处理外部请求过程时，各个类型过滤器的执行逻辑。从代码中我们可以看到三个try-catch块，它们依次分别代表了pre、route、post三个阶段的过滤器调用。在catch的异常处理中我们可以看到它们都会被error类型的过滤器进行处理（之前使用error过滤器来定义统一的异常处理也正是利用了这个特性）; error类型的过滤器处理完毕之后，除了来自post阶段的异常之外，都会再被post过滤器进行处理。所以，上面代码中各个处理阶段的逻辑如下图所示：

通过图中的分析，我们可以看到，对于从 post 过滤器中抛出异常的情况，在经过error过滤器处理之后，就没有其他类型的过滤器来接手了，这就是使用之前所述方案存在不足之处的根源。回想一下之前实现的两种异常处理方法，其中非常核心的一点是，这两种处理方法都在异常处理时向请求上下文中添加了一系列的error.*参数，而这些参数真正起作用的地方是在post阶段的SendErrorFilter，在该过滤器中会使用这些参数来组织内容返回给客户端。而对于post阶段抛出异常的情况下，由error过滤器处理之后并不会再调用 post 阶段的请求，自然这些 error.*参数也就不会被SendErrorFilter消费输出。所以，如果我们在自定义post过滤器的时候，没有正确处理异常，就依然有可能出现日志中没有异常但请求响应内容为空的问题。我们可以通过将之前ThrowExceptionFilter的filterType修改为post来验证这个问题的存在，注意去掉try-catch块的处理，让它能够抛出异常。

解决上述问题的方法有很多种，最直接的是我们可以在实现error过滤器的时候，直接组织结果返回就能实现效果。但是这样做的缺点也很明显，对于错误信息组织和返回的代码实现会存在多份，这样非常不利于日后的代码维护工作。所以为了保持对异常返回处理逻辑的一致性，我们还是希望将post过滤器抛出的异常交给SendErrorFilter来处理。

在前文中，我们已经实现了一个ErrorFilter来捕获pre、route、post过滤器抛出的异常，并组织 error.*参数保存到请求的上下文中。由于我们的目标是沿用SendErrorFilter，这些error.*参数依然对我们有用，所以可以继续沿用该过滤器，让它在post过滤器抛出异常的时候，继续组织error.*参数，只是这里我们已经无法将这些 error.*参数再传递给 SendErrorFilter 过滤器来处理了。所以，我们需要在ErrorFilter 过滤器之后再定义一个 error 类型的过滤器，让它来实现SendErrorFilter的功能，但是这个error过滤器并不需要处理所有出现异常的情况，它仅对 post 过滤器抛出的异常有效。根据上面的思路，我们完全可以创建一个继承自SendErrorFilter的过滤器，复用它的run方法，然后重写它的类型、顺序以及执行条件，实现对原有逻辑的复用，具体实现如下：

@Component

public class ErrorExtFilter extends SendErrorFilter {

@Override

public String filterType（）{

return "error";

}

@Override

public int filterOrder（）{

return 30; //大于ErrorFilter的值

}

@Override

public boolean shouldFilter（）{

//TODO 判断：仅处理来自post过滤器引起的异常

return true;

}

}

到这里，我们在过滤器调度上的实现思路已经很清晰了，但是又有一个问题出现在我们面前：怎么判断引起异常的过滤器来自什么阶段呢？shouldFilter方法该如何实现，对于这个问题，我们第一反应会寄希望于请求上下文 RequestContext 对象，可是在查阅文档和源码后发现其中并没有存储异常来源的内容，所以我们不得不扩展原来的过滤器处理逻辑。当有异常抛出的时候，记录下抛出异常的过滤器，这样我们就可以在ErrorExtFilter过滤器的shouldFilter方法中获取并以此判断异常是否来自post阶段的过滤器了。

为了扩展过滤器的处理逻辑，为请求上下文增加一些自定义属性，我们需要深入了解Zuul过滤器的核心处理器：com.netflix.zuul.FilterProcessor。该类中定义了下面列出的过滤器调用和处理相关的核心方法。

- getInstance（）：该方法用来获取当前处理器的实例。

- setProcessor（FilterProcessor processor）：该方法用来设置处理器实例，可以使用此方法来设置自定义的处理器。

- processZuulFilter（ZuulFilter filter）：该方法定义了用来执行 filter的具体逻辑，包括对请求上下文的设置，判断是否应该执行，执行时一些异常的处理等。

- getFiltersByType（String filterType）：该方法用来根据传入的filterType 获取 API 网关中对应类型的过滤器，并根据这些过滤器的filterOrder从小到大排序，组织成一个列表返回。

- runFilters（String sType）：该方法会根据传入的 filterType 来调用getFiltersByType（String filterType）获取排序后的过滤器列表，然后轮询这些过滤器，并调用 processZuulFilter（ZuulFilter filter）来依次执行它们。

- preRoute（）：调用runFilters（"pre"）来执行所有pre类型的过滤器。

- route（）：调用runFilters（"route"）来执行所有route类型的过滤器。

- postRoute（）：调用runFilters（"post"）来执行所有post类型的过滤器。

- error（）：调用runFilters（"error"）来执行所有error类型的过滤器。

根据之前的设计，可以直接扩展 processZuulFilter（ZuulFilter filter），当过滤器执行抛出异常的时候，我们捕获它，并向请求上下中记录一些信息。比如下面的具体实现：

public class DidiFilterProcessor extends FilterProcessor {

@Override

public Object processZuulFilter（ZuulFilter filter）throws ZuulException {

try {

return super.processZuulFilter（filter）;

} catch（ZuulException e）{

RequestContext ctx=RequestContext.getCurrentContext（）;

ctx.set（"failed.filter",filter）;

throw e;

}

}

}

在上面代码的实现中，我们创建了一个 FilterProcessor 的子类，并重写了processZuulFilter（ZuulFilter filter），虽然主逻辑依然使用了父类的实现，但是在最外层，我们为其增加了异常捕获，并在异常处理中为请求上下文添加了failed.filter属性，以存储抛出异常的过滤器实例。在实现了这个扩展之后，我们也就可以完善之前ErrorExtFilter中的shouldFilter（）方法了，通过从请求上下文中获取该信息做出正确的判断，具体实现如下：

@Component

public class ErrorExtFilter extends SendErrorFilter {

@Override

public String filterType（）{

return "error";

}

@Override

public int filterOrder（）{

return 30; //大于ErrorFilter的值

}

@Override

public boolean shouldFilter（）{

RequestContext ctx=RequestContext.getCurrentContext（）;

ZuulFilter failedFilter=（ZuulFilter）ctx.get（"failed.filter"）;

//判断：仅处理来自post过滤器引起的异常

if（failedFilter !=null && failedFilter.filterType（）.equals（"post"））{

return true;

}

return false;

}

}

到这里，我们的优化任务还没有完成，因为扩展的过滤器处理类并还没有生效。最后，需要在应用主类中，通过调用FilterProcessor.setProcessor（new DidiFilterProcessor（））；方法来启用自定义的核心处理器以完成我们的优化目标。

自定义异常信息

在实现了对自定义过滤器中的异常处理之后，实际应用到业务系统中时，往往默认的错误信息并不符合系统设计的响应格式，那么我们就需要对返回的异常信息进行定制。对于如何定制这个错误信息有很多种方法可以实现。最直接的是，可以编写一个自定义的post过滤器来组织错误结果，该方法实现起来简单粗暴，完全可以参考SendErrorFilter的实现，然后直接组织请求响应结果而不是forward到/error端点，只是使用该方法时需要注意：为了替代 SendErrorFilter，还需要禁用 SendErrorFilter 过滤器，禁用的配置方法在后文中会详细介绍。

那么如果不采用重写过滤器的方式，依然想要使用SendErrorFilter来处理异常返回的话，我们要如何定制返回的响应结果呢？这个时候，我们的关注点就不能放在Zuul的过滤器上了，因为错误信息的生成实际上并不是由Spring Cloud Zuul完成的。我们在介绍SendErrorFilter 的时候提到过，它会根据请求上下中保存的错误信息来组织一个forward 到/error 端点的请求来获取错误响应，所以我们的扩展目标转移到了对/error端点的实现。

/error 端点的实现来源于 Spring Boot 的 org.springframework.boot.autoconfigure.web.BasicErrorController，它的具体定义如下：

@RequestMapping

@ResponseBody

public ResponseEntity<Map<String,Object>> error（HttpServletRequest request）{

Map<String,Object> body=getErrorAttributes（request,

isIncludeStackTrace（request,MediaType.ALL））;

HttpStatus status=getStatus（request）;

return new ResponseEntity<Map<String,Object>>（body,status）;

}

从源码中可以看到，它的实现非常简单，通过调用getErrorAttributes方法来根据请求参数组织错误信息的返回结果，而这里的getErrorAttributes方法会将具体组织逻辑委托给 org.springframework.boot.autoconfigure.web.ErrorAttributes接口提供的getErrorAttributes来实现。在Spring Boot的自动化配置机制中，默认会采用 org.springframework.boot.autoconfigure.web.DefaultErrorAttributes作为该接口的实现。如下代码所示，在定义Error处理的自动化配置中，该接口的默认实现采用了@ConditionalOnMissingBean修饰，说明DefaultErrorAttributes对象实例仅在没有ErrorAttributes接口的实例时才会被创建来使用，所以我们只需要自己编写一个自定义的ErrorAttributes接口实现类，并创建它的实例就能替代这个默认的实现，从而达到自定义错误信息的效果了。

@ConditionalOnClass（{ Servlet.class,DispatcherServlet.class }）

@ConditionalOnWebApplication

@AutoConfigureBefore（WebMvcAutoConfiguration.class）

@Configuration

public class ErrorMvcAutoConfiguration {

@Autowired

private ServerProperties properties;

@Bean

@ConditionalOnMissingBean（value=ErrorAttributes.class,search=SearchStrategy.CURRENT）

public DefaultErrorAttributes errorAttributes（）{

return new DefaultErrorAttributes（）;

}

...

}

举个简单的例子，比如我们不希望将 exception 属性返回给客户端，那么就可以编写一个自定义的实现，它可以基于 DefaultErrorAttributes，然后重写getErrorAttributes方法，从原来的结果中将exception移除即可，具体实现如下：

public class DidiErrorAttributes extends DefaultErrorAttributes {

@Override

public Map<String,Object> getErrorAttributes（

RequestAttributes requestAttributes,boolean includeStackTrace）{

Map<String,Object> result=super.getErrorAttributes（requestAttributes,includeStackTrace）;

result.remove（"exception"）;

return result;

}

}

最后，为了让自定义的错误信息生成逻辑生效，需要在应用主类中加入如下代码，为其创建实例来替代默认的实现：

@Bean

public DefaultErrorAttributes errorAttributes（）{

return new DidiErrorAttributes（）;

}

通过上面介绍的方法，我们就能基于Zuul的核心过滤器来灵活地自定义错误返回信息，以满足实际应用系统的响应格式了。

禁用过滤器

不论是核心过滤器还是自定义过滤器，只要在API网关应用中为它们创建了实例，那么默认情况下，它们都是启用状态的。那么如果有些过滤器我们不想使用了，如何禁用它们呢？大多情况下初识Zuul的使用者第一反应就是通过重写shouldFilter逻辑，让它返回false，这样该过滤器对于任何请求都不会被执行，基本实现了对过滤器的禁用。但是，对于自定义过滤器来说似乎是实现了过滤器不生效的功能，但是这样的做法缺乏灵活性。由于直接要修改过滤器逻辑，我们不得不重新编译程序，并且如果该过滤器在未来一段时间还有可能被启用的时候，那么就又得修改代码并编译程序。同时，对于核心过滤器来说，就更为麻烦，我们不得不获取源码来进行修改和编译。

实际上，在Zuul中特别提供了一个参数来禁用指定的过滤器，该参数的配置格式如下：

zuul.<SimpleClassName>.<filterType>.disable=true

其中，<SimpleClassName>代表过滤器的类名，比如快速入门示例中的AccessFilter;<filterType>代表过滤器类型，比如快速入门示例中 AccessFilter 的过滤器类型pre。所以，如果我们想要禁用快速入门示例中的 AccessFilter 过滤器，只需要在application.properties配置文件中增加如下配置即可：

zuul.AccessFilter.pre.disable=true

该参数配置除了可以对自定义的过滤器进行禁用配置之外，很多时候可以用它来禁用Spring Cloud Zuul中默认定义的核心过滤器。这样我们就可以抛开Spring Cloud Zuul自带的那套核心过滤器，实现一套更符合我们实际需求的处理机制。

通过本节对异常处理的介绍，也许这些方法并一定完全适用读者所接触的实际系统，但是通过这些分析可以帮助我们进一步理解Zuul过滤器的运行机制，帮助我们基于Spring Cloud Zuul去实现更适合自身系统的API网关服务。