过滤器
在Spring Cloud Zuul中，过滤器的顶级接口是IZuulFilter，其下有个抽象类ZuulFilter，过滤器必须包含4个基本特征：执行条件（shouldFilter）、具体操作（run）、过滤类型（filterType）、执行顺序（filterOrder）。具体抽象方法源码如下：
package com.netflix.zuul;
/**
* BAse interface for ZuulFilters
*
* @author Mikey Cohen
* Date: 10/27/11
* Time: 3:03 PM
*/
public interface IZuulFilter {
/**
* a "true" return from this method means that the run() method should be invoked
*
* @return true if the run() method should be invoked. false will not invoke the run() method
*/
boolean shouldFilter();
/**
* if shouldFilter() is true, this method will be invoked. this method is the core method of a ZuulFilter
*
* @return Some arbitrary artifact may be returned. Current implementation ignores it.
*/
Object run();
}
public abstract class ZuulFilter implements IZuulFilter, Comparable<ZuulFilter> {
private final DynamicBooleanProperty filterDisabled =
DynamicPropertyFactory.getInstance().getBooleanProperty(disablePropertyName(), false);
/**
* to classify a filter by type. Standard types in Zuul are "pre" for pre-routing filtering,
* "route" for routing to an origin, "post" for post-routing filters, "error" for error handling.
* We also support a "static" type for static responses see StaticResponseFilter.
* Any filterType made be created or added and run by calling FilterProcessor.runFilters(type)
*
* @return A String representing that type
*/
abstract public String filterType();
/**
* filterOrder() must also be defined for a filter. Filters may have the same filterOrder if precedence is not
* important for a filter. filterOrders do not need to be sequential.
*
* @return the int order of a filter
*/
abstract public int filterOrder();
}几个特征的简单说明如下：
- shouldFilter ：返回一个boolean类型来判断该过滤器是否要执行。可以通过实现此方法来达到过滤指定条件的请求。方法内一般通过zuul提供的request上下文工具获取请求的request，获取方式如下：
@Override
public boolean shouldFilter() {
RequestContext ctx = RequestContext.getCurrentContext();
HttpServletRequest request = ctx.getRequest();
return request.getRequestURI().startsWith("/api-task");
}这样就可以通过请求的参数、路径等信息进行判断。
- run ：过滤器的具体实现。在这个方法中，可以实现自定义的过滤逻辑，达到拦截请求、路由请求或对请求进行一些统一的操作的目的，比如Ribbon的负载均衡就是通过filter来实现的
filterType ：这个方法返回一个字符串来代表过滤器的类型。这个类型就是指定过滤器是在哪个阶段去执行。类型是固定的几个字符串，有常量定义在FilterConstants中，具体如下：
- pre：在请求被路由之前调用
- route：在路由请求时候被调用
- post：在routing和error过滤器之后被调用
- error：处理请求发生错误时被调用
- filterOrder：这个方法返回一个整数来定义过滤器的执行顺序，数值越小优先级越高
请求生命周期
Zuul定义了四个过滤器类型，覆盖了从接收一个HTTP请求到返回结果的生命周期。下图描述了在各个不同类型的过滤器之间流转的详细过程
从上图中可以看出，当外部HTTP请求到达API网关服务的时候，首先它会进入第一个阶段pre，在这里它会被pre类型的过滤器进行处理，该类型的过滤器主要目的是在进行请求路由之前做一些前置加工，比如请求的校验等。在完成了pre类型的过滤器处理之后，请求进入第二个阶段routing，也就是之前说的路由请求转发阶段，请求将会被routing类型过滤器处理，这里的具体处理内容就是将外部请求转发到具体服务实例上去的过程，当服务实例将请求结果都返回之后，routing阶段完成，请求进入第三个阶段post，此时请求将会被post类型的过滤器进行处理，这些过滤器在处理的时候不仅可以获取到请求信息，还能获取到服务实例的返回信息，所以在post类型的过滤器中，我们可以对处理结果进行一些加工或转换等内容。另外，还有一个特殊的阶段error，该阶段只有在上述三个阶段中发生异常的时候才会触发，但是它的最后流向还是post类型的过滤器，因为它需要通过post过滤器将最终结果返回给请求客户端
核心过滤器
在Spring Cloud Zuul中，在HTTP请求生命周期的各个阶段已经默认地实现了一批核心过滤器，它们会在API网关服务启动的时候被自动地加载和启用。这个过滤器在spring-cloud-netflix-core模块的org.springframework.cloud.netflix.zuul.filters包下
这些过滤器的加载是在ZuulConfiguration配置类当中，从这些过滤器的名字上基本能看出zuul大概的处理流程，下面将对这些过滤器做一些详细的介绍
pre过滤器
- ServletDetectionFilter ：执行顺序为-3，是最先被执行的过滤器。该过滤器的shouldFilter()方法总是返回true，所以这个过滤器总是会被执行，主要用来检测当前请求是否通过Spring的DispatcherServlet，并会把检测结果保存到request上下文当中（key为isDispatcherServletRequest）。在后续的过滤器中，就可以通过RequestUtils.isDispatcherServletRequest()工具方法判断它以实现做不同的处理。一般情况下接收到的http请求都会被Spring的DispatcherServlet处理，除了通过/zuul/**路径访问的请求会绕过DispatcherServlet，被ZuulServlet处理，为了方便，ZuulServlet处理的路径是可以通过zuul.servletPath参数来进行配置的
- Servlet30WrapperFilter ：执行顺序为-2，是第二个执行的过滤器。目前的实现同样是总会对所有请求有效，主要实现的是将原始的HttpServletRequest包装成Servlet30RequestWrapper对象
FormBodyWrapperFilter ：执行顺序为-1，第三个执行的过滤器。这个过滤器只对两种类型请求生效：
- Content-Type为application/x-www-form-urlencoded的请求
- Content-Type为multipart/form-data并且是由Spring的DispatcherServlet处理的请求。而该过滤器的主要目的是将符合要求的请求体包装成FormBodyRequestWrapper对象
- DebugFilter ：执行顺序为1，第四个执行的过滤器。该过滤器是否执行是根据配置参数zuul.debug.request和请求中的debug参数来决定的。而它的具体操作内容则是将当前的request上下文中的debugRouting和debugRequest参数设置为true。这样在这之后的所有过滤器都可以获取到这两个值，我们就可以在后续的各个过滤器中利用这两值来定义一些帮助分析问题的日志，当线上环境出现问题的时候，可以通过请求参数的方式来打印出相关日志以帮助分析问题
- PreDecorationFilter ：执行顺序为5，是pre阶段最后被执行的过滤器。该过滤器会判断当前请求上下文中是否存在forward.to和serviceId参数，如果都不存在，那么它才会执行具体过滤器的操作(如果有一个存在的话，说明当前请求已经被处理过了，因为这两个信息就是根据当前请求的路由信息加载进来的)。这个过滤器的主要作用就是为当前请求做一些预处理，比如：进行路由规则的匹配、在请求上下文中设置一些基本信息、对没有匹配到路由规则的一些处理等，这些处理对后续过滤器的处理提供了重要依据，我们可以再后续过滤器中通过RequestContext.getCurrentContext()来访问这些信息。另外，我们还可以在该实现中找到一些对HTTP头请求进行处理的逻辑，其中包含了一些信息头的处理，比如：X-Forwarded-Host、X-Forwarded-Port。另外，对于这些头域的记录是通过zuul.addProxyHeaders参数进行控制的，而这个参数默认值为true，所以Zuul在请求跳转时默认地会为请求增加X-Forwarded-*请求头图，包括：X-Forwarded-Host、X-Forwarded-Port、X-Forwarded-For、X-Forwarded-Prefix、X-Forwarded-Proto。我们也可以通过设置zuul.addProxyHeaders=false关闭对这些信息头的处理
route过滤器
- RibbonRoutingFilter ：执行顺序为10，是route阶段第一个执行的过滤器。这个过滤器只对请求上下文中存在serviceId参数的请求进行处理，即只对通过serviceId配置路由规则的请求生效。这个过滤器主要实现的就是负载后向服务实例发送请求
- SimpleHostRoutingFilter ：执行顺序为100，是route阶段第二个执行的过滤器。该过滤器只对请求上下文中存在routeHost参数的请求进行处理，即只对通过url配置路由规则的请求生效。而该过滤器的执行逻辑就是直接向routeHost参数的物理地址发起请求，从源码中我们可以知道该请求是直接通过httpclient包实现的，而没有使用Hystrix命令进行包装，所以这类请求并没有线程隔离和断路器的保护
- SendForwardFilter ：执行顺序为500，是route阶段第三个执行的过滤器。该过滤器只对请求上下文中存在forward.to参数的请求进行处理，主要实现的是应用内的本地跳转
post过滤器
- SendErrorFilter ：执行顺序为0，是post阶段第一个执行的过滤器。该过滤器仅在请求上下文中包含error.status_code参数(由之前执行的过滤器设置的错误编码)并且还没有被该过滤器处理过的时候执行。这个过滤器主要实现的就是收集错误的信息放入到request上下文当中，然后本地forward到配置的错误路径（默认是/error）
- SendResponseFilter ：执行顺序为1000，是post阶段最后执行的过滤器。该过滤器会检查请求上下文中是否包含请求响应相关的头信息、响应数据流或是响应体，只有在包含它们其中一个的时候就会执行处理逻辑。该过滤器主要就是将路由请求的结果发送回客户端，即响应客户端的请求
以上就是zuul提供的一些过滤器的说明，了解了这些过滤器，就可以根据自己应用的需求场景，自定义实用的过滤器了
