第十四天:浪迹天涯网上商城(1.0版本)--spring cloud zuul网关的过滤器运行机制剖析

1、ZuulServlet执行的生命周期

在前面的博客第十二天:浪迹天涯网上商城(1.0版本)--spring cloud zuul网关搭建中,我们使用了@EnableZuulProxy注解,开启该注解后,在Spring容器初始化时,会将Zuul的相关配置初始化,其中包含一个Spring Boot的bean:ServletRegistrationBean,该类主要用于注册Servlet。Zuul提供了一个ZuulServlet类,在Servlet的service方法中,执行各种ZuulFilter。下图为HTTP请求在ZuulServlet中的生命周期。


ZuulServlet的service方法接收到请求后,会执行“pre”阶段的过滤器,再执行“routing”阶段的过滤器,最后执行“post”阶段的过滤器。其中“routing”的过滤器,会将请求转发到“源服务”,源服务可以是第三方的Web服务,也可以是Spring Cloud的集群服务。在执行pre和routing阶段的过滤器时,如果出现异常,则会执行“error”过滤器。整个过程的HTTP请求、HTTP响应、状态等数据,都会封装到一个RequestContext的对象中。下面展示的是ZuulServlet的service方法的源代码部分:


2、zuul过滤器优先级

Spring Cloud为HTTP请求的各个阶段,为每个阶段都提供了多个过滤器,这些过滤器的执行顺序,由它们各自提供的一个int值决定,提供的值越小,优先级越高。下图展示了默认的过滤器,以及它们的优先级。


3、pre过滤器

ServletDetectionFilter:它的执行顺序为-3,是最先被执行的过滤器。该过滤器总是会被执行,主要用来检测当前请求是通过Spring的DispatcherServlet处理运行,还是通过ZuulServlet来处理运行的。ServletDetectionFilter代码很简单,源代码如下所示:

扫描二维码关注公众号,回复: 1632432 查看本文章


它的检测结果会以布尔类型保存在当前请求上下文的isDispatcherServletRequest参数中,这样在后续的过滤器中,我们就可以通过RequestUtils.isDispatcherServletRequest()和RequestUtils.isZuulServletRequest()方法判断它以实现做不同的处理。一般情况下,发送到API网关的外部请求都会被Spring的DispatcherServlet处理,除了通过/zuul/路径访问的请求会绕过DispatcherServlet,被ZuulServlet处理,主要用来应对处理大文件上传的情况。另外,对于ZuulServlet的访问路径/zuul/,我们可以通过zuul.servletPath参数来进行修改。

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


2、FormBodyWrapperFilter:它的执行顺序为-1,是第三个执行的过滤器。该过滤器仅对两种请求生效,第一类是Content-Type为application/x-www-form-urlencoded的请求,第二类是Content-Type为multipart/form-data并且是由Spring的DispatcherServlet处理的请求(用到了ServletDetectionFilter的处理结果)。


而该过滤器的主要目的是将符合要求的请求体包装成FormBodyRequestWrapper对象。


4、DebugFilter:它的执行顺序为1,是第四个执行的过滤器。该过滤器会根据配置参数zuul.debug.request和请求中的debug参数来决定是否执行过滤器中的操作。而它的具体操作内容则是将当前的请求上下文中的debugRouting和debugRequest参数设置为true。


由于在同一个请求的不同生命周期中,都可以访问到这两个值,所以我们在后续的各个过滤器中可以利用这两值来定义一些debug信息,这样当线上环境出现问题的时候,可以通过请求参数的方式来激活这些debug信息以帮助分析问题。另外,对于请求参数中的debug参数,我们也可以通过zuul.debug.parameter来进行自定义。

5、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关闭对这些头域的添加动作。


5、routing过滤器

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


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

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

5、post过滤器





猜你喜欢

转载自blog.csdn.net/pfnie/article/details/80722278