Zuul之Filter详解

Zuul详解

官方文档：https://github.com/Netflix/zuul/wiki/How-it-Works

Zuul的中心是一系列过滤器，能够在HTTP请求和响应的路由过程中执行一系列操作。

以下是Zuul过滤器的主要特征：

• 类型：通常在应用过滤器时在路由流程中定义阶段（尽管它可以是任何自定义字符串）
• 执行顺序：在类型中应用，定义跨多个过滤器的执行顺序
• 标准：执行过滤器所需的条件
• 操作：满足条件时要执行的操作

Zuul提供了一个动态读取，编译和运行这些过滤器的框架。过滤器不直接相互通信 - 而是通过RequestContext共享状态，RequestContext对每个请求都是唯一的。

过滤器目前用Groovy编写，尽管Zuul支持任何基于JVM的语言。每个Filter的源代码都写入Zuul服务器上的一组指定目录，这些目录会定期轮询更改。更新的过滤器从磁盘读取，动态编译到正在运行的服务器中，并由Zuul为每个后续请求调用。

过滤类型

Zuul大部分功能都是通过过滤器来实现的。Zuul中定义了四种标准过滤器类型，这些过滤器类型对应于请求的典型生命周期：

• PRE：这种过滤器在请求被路由调用之前调用。我们可利用这种过滤器实现身份验证、再集群中选择请求的微服务、记录调试信息等。
• ROUTING：这种过滤器将请求路由到微服务。用于构建发送给微服务的请求，并使用Apache HttpClient或Netflix Ribbon构建和发送原始HTTP请求的位置。
• POST：请求在路由到微服务之后执行。示例包括向响应添加标准HTTP标头、收集统计信息和指标、以及将响应从源传输到客户端。
• ERROR：过滤器在其中一个阶段发生错误时执行。

除了默认的过滤器类型，Zuul还允许我们创建自定义过滤器类型。例如，我们有一个自定义STATIC类型的过滤器，它直接在Zuul中生成响应，而不是将请求转发到后端的微服务。

Zuul请求的生命周期

Zuul请求的生命周期如下图所示，改图详细的描述了各种类型的过滤器执行顺序。 

 

常见的使用

/**
 * 过滤类型
 */
filterType() {
    return FilterConstants.PRE_TYPE;
}

/**
 * 过滤顺序
 */
public int filterOrder() {
    return -4;
}

/**
 * 拦截需要过滤的请求
 */
shouldFilter(){
    ……
}

/**
 * 过滤需要做的处理
 */
run(){
    ……
}

执行顺序

• 1、按照filterType决定顺序

Pre 优先 Post执行，此时filterOrder没有作用。

• 2、filterType相同

filterOrder有作用，数字越小，越先执行。（负数也是这个规则，0和-1的话，-1先执行）

• 3、相同filterType,相同filterOrder，都执行，执行顺序不清楚。

prefilter先执行了，post后执行了。

感觉不像是按照过滤请名称排序的样子。