Zuul的过滤器

过滤器是Zuul的核心组件,这篇文章用来记录Zuul的过滤器相关内容。

过滤器类型与请求声明周期

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

  • PRE
    这种过滤器在请求被路由之前调用。可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调式信息等。

  • ROUTING
    这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求,并使用Apache HttpClient或 Netfilx Ribbon请求微服务。

  • POST
    这种过滤器在路由到微服务以后执行。这种过滤器可以用来为响应添加标准的Http Header、收集统计信息和指标、将响应从微服务发送给客户端等。

  • ERROR
    在其他阶段发生错误时执行该过滤器。

除了上面默认的过滤器类型外,Zuul还允许创建自定义的过滤器类型。例如,可以定制一种STATIC类型的过滤器,直接在Zuul中生成响应,而不将请求转发到后端微服务。

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

Zuul请求声明周期

我们来进行编写一个Zuul过滤器

编写一个Zuul的过滤器非常简单,只需要继承抽象类ZuulFilter,然后实现几个抽象方法就可以了。

接下来,我们编写一个简单的Zuul过滤器,让该过滤器打印请求日志。

  1. 编写自定义Zuul过滤器
public class PreRequestLogFilter extends ZuulFilter {

    private static final Logger LOGGER = LoggerFactory.getLogger(PreRequestLogFilter.class);

    @Override
    public String filterType() {
        return "pre";
    }

    @Override
    public int filterOrder() {
        return 1;
    }

    @Override
    public boolean shouldFilter() {
        return true;
    }

    @Override
    public Object run() {
        RequestContext ctx = RequestContext.getCurrentContext();

        HttpServletRequest request = ctx.getRequest();
        PreRequestLogFilter.LOGGER.info(String.format("send %s request to %s",request.getMethod(),request.getRequestURL().toString()));
        return null;
    }
}

由代码可知,自定义的Zuul Filter需要实现下面几个方法。

  • filterType: 返回过滤器的类型。有pre、route、post、error等几种取值,分别对应上文的几种过滤器。详情可以参考com.netfilx.zuul.ZuulFilter.filterType() 中的注释。
  • filterOrder: 返回一个int值来指定过滤器的执行顺序,不同的过滤器允许返回相同的数字。
  • shouldFilter: 返回一个boolean值来判断该过滤器是否要执行,true表示执行,false表示不执行。
  • run: 过滤器的具体逻辑。这里我让它打印了请求的HTTP方法以及请求地址。
  1. 修改springboot工程的启动类,为启动类添加一下内容:
	@Bean
	public PreRequestLogFilter preRequestLogFilter() {
		return new PreRequestLogFilter();
	}

测试:
访问 http://localhost:port/microservice-name/uri,可以获得类似如下日志:

send GET request to http://localhost:8040/microservice-provider-user/1

禁用Zuul过滤器

Spring Cloud默认为Zuul编写并启用了一些过滤器,例如DebugFilter,FormBodyWrapperFilter、PreDecorationFilter等。这些过滤器都存放在spring-cloud-netfilx-core 这个Jar包的org.springframework.cloud.netflix.zuul.filters包中。

一些场景下,想要禁用掉部分过滤器,该怎么办?

答案非常简单,只须设置zuul...disable=true,即可禁用SimpleClassName 所对应的过滤器。如果想要禁用掉我们上门所编写的过滤器,只需设置zuul.PreRequestLogFilter.pre.disable=true即可。

<think>好的,我现在需要回答用户关于Zuul过滤器中pre、post和error类型filterOrder的最佳设置方法的问题。首先,我得回忆一下Zuul过滤器生命周期和相关文档。根据之前提供的引用,Zuul有四种过滤器类型:pre、route、post和error,每个类型在请求处理的不同阶段执行。 用户问的是pre、post和error过滤器的合理filterOrder设置方法。我需要先确定每个类型过滤器的执行顺序范围。根据引用[1],pre过滤器的执行顺序是处理路由之前,route在路由时,post在route和error之后,error在所有阶段发生错误时执行。不过具体order数值范围可能没有明确提到,可能需要进一步分析。 通常,Zuul过滤器执行顺序是按类型划分的,每个类型内的过滤器根据各自的order值排序。比如pre过滤器的order值越小,越先执行。而整个请求的生命周期中,pre过滤器先执行,然后是route,接着是post,最后是error吗?或者error过滤器是在任何阶段发生错误时触发? 根据引用[3]中的示例,pre过滤器执行后是route,然后是post。但error过滤器可能在pre、route或post阶段发生错误时触发。所以error过滤器的order值可能需要设置在pre之后,但不确定具体的数值范围。 查阅资料,比如Spring Cloud的官方文档,可能会提到各个过滤器类型的执行顺序范围。例如,pre过滤器的order范围通常是负数或较小的数值,route在中间,post在较大的数值,而error可能介于pre和post之间,或者在特定位置。或者,可能每个类型的order范围是独立的,例如pre从-1000到0,route从110000,post从10001到20000,error可能在更后面的范围? 另外,引用[2]提到如何禁用过滤器,比如设置zuul.LogFilter.pre.disable=true,说明过滤器的类型和名称在配置中是重要的,但order值需要开发者自己设置。 用户的最佳实践问题需要考虑如何安排不同过滤器的顺序以避免冲突,确保关键过滤器先执行。例如,认证应该在pre阶段的最先执行,日志记录可能在pre阶段的后面,或者在post阶段的最前面。 可能的建议是:pre过滤器使用较低的order值(例如从0到1000),route在1000到10000,post在10000到20000,error可能在更高的范围,或者根据需要在pre之后。但需要更准确的信息。 可能需要参考Spring Cloud Zuul的默认过滤器order值。例如,ServletDetectionFilter的order是-3,Servlet30WrapperFilter是-2,FormBodyWrapperFilter是-1,这些是pre类型的。所以默认的pre过滤器可能有负的order值。而用户自定义的pre过滤器可能需要设置比这些默认值更大的order值,或者更小,取决于是否需要先于或后于默认过滤器执行。 例如,如果用户希望自己的pre过滤器在默认的ServletDetectionFilter之后执行,应该设置order值大于-3,比如-2,或者更高的值。但需要根据具体需求调整。 对于error过滤器,它们的执行顺序可能是在其他类型之后?或者在处理错误时触发,其order值可能独立于其他类型。例如,当pre阶段发生错误时,error过滤器会执行,那么error过滤器的order值可能影响它们在处理错误时的顺序。 总结最佳实践: 1. pre过滤器:使用较低数值,通常在-1000到0之间,确保关键过滤器(如认证)优先执行。默认的pre过滤器有负值,自定义的可以设置在默认之后或之前,根据需求。 2. route过滤器:order在110000之间,通常只有一个内置的RibbonRoutingFilter或SimpleHostRoutingFilter,用户自定义route过滤器需根据需要设置。 3. post过滤器:order在10001到20000之间,执行后处理,如添加响应头。 4. error过滤器:可能设置在0到1000之间,但需要确保在错误发生时能正确处理。或者可能error过滤器的order值与其他类型不冲突,因为它们只在错误时触发,但内部的执行顺序可能由order值决定。 可能用户需要知道各个类型内的order范围,以及如何避免不同过滤器之间的顺序冲突。比如,pre过滤器之间按order从小到大执行,而error过滤器之间也是如此。当错误发生时,error过滤器按它们的order顺序执行。 所以,最佳实践建议: - pre过滤器:order值从-1000到0,关键服务如认证设置为最小(最先执行)。 - route过滤器:order在1到999之间。 - post过滤器:order从1000开始。 - error过滤器:可以设置在0到100之间,或者根据需要在pre之后。 另外,要参考内置过滤器的order值,避免冲突。例如,如果内置的pre过滤器有order为-3,用户自定义的pre过滤器若想在其后执行,应设置为更大的值,如-2,-1,或正数。或者相反,如果想先执行,则设置更小的值,如-4。 例如,自定义的认证pre过滤器可能需要比ServletDetectionFilter(order=-3)更早执行,所以设置为order=-4。或者在默认之后执行,比如order=5。 因此,最佳实践应包括: 1. 确定内置过滤器的order值,避免覆盖或冲突。 2. 根据业务需求调整自定义过滤器的order值。 3. 同一类型的过滤器按order值升序执行。 比如,在pre阶段,执行顺序是order值从小到大,所以若想让某个pre过滤器先执行,设置更小的order值。 对于error过滤器,它们可能在任何阶段出错时被调用,因此它们的order值决定了在处理错误时的执行顺序。比如,错误日志记录可能需要先执行,设置较小的order值,而错误响应处理可能随后执行。 总之,合理的设置需要: - 了解默认过滤器的order值。 - 根据业务逻辑确定自定义过滤器的执行顺序。 - 同一类型内使用连续的order范围,避免重叠。 最后,给出一个示例设置,比如pre过滤器从0到100,error从100到200,post从200以上,但可能需要更准确的划分。或者参考官方文档的推荐范围。</think>### Zuul过滤器FilterOrder最佳实践 在Zuul网关中,过滤器的执行顺序通过`filterOrder`属性控制,合理设置该值可确保过滤器按预期逻辑执行。以下是针对`pre`、`post`和`error`类型过滤器的推荐设置方法: --- #### 一、执行顺序基本原则 1. **按类型分层级**: - `pre` → `route` → `post`(正常流程) - `error` 在**任意阶段发生异常时触发** - 同一类型内按`filterOrder`升序执行(数值越小越先执行)[^1][^3]。 2. **内置过滤器参考**: Zuul默认的`pre`过滤器使用**负值**(如`ServletDetectionFilter`的`order=-3`),自定义过滤器需根据是否覆盖默认逻辑选择`order`值: - 若需**优先于默认过滤器**,设置更小的数值(如`-4`); - 若需**在默认之后执行**,使用正值(如`1`)[^2][^4]。 --- #### 二、各类型推荐范围 | 类型 | 推荐范围 | 典型场景示例 | |--------|-------------|---------------------------| | **pre** | `-1000 ~ 0` | 认证(`order=-100`)、请求日志(`order=0`) | | **error** | `1 ~ 999` | 错误日志(`order=1`)、错误响应封装(`order=100`) | | **post** | `1000+` | 响应头追加(`order=1000`)、性能统计(`order=2000`) | --- #### 三、具体配置示例 1. **pre类型**: ```java public class AuthFilter extends ZuulFilter { @Override public int filterOrder() { return -100; // 高优先级认证逻辑 } } ``` 2. **error类型**: ```java public class ErrorLoggerFilter extends ZuulFilter { @Override public int filterOrder() { return 1; // 先记录错误日志 } } ``` 3. **post类型**: ```java public class ResponseHeaderFilter extends ZuulFilter { @Override public int filterOrder() { return 1000; // 最后添加响应头 } } ``` --- #### 四、注意事项 1. **避免范围重叠**:确保不同类型过滤器的`order`范围不重叠,例如`pre`使用负值,`error`使用正小值。 2. **禁用冲突过滤器**:若需覆盖默认过滤器,可通过`zuul.<FilterClass>.<type>.disable=true`禁用原有逻辑[^2]。 3. **调试方法**:通过日志观察过滤器执行顺序,结合`/actuator/filters`端点(需开启监控)验证实际顺序[^3]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值