Spring Cloud源码分析（四）Zuul：核心过滤器

https://mp.weixin.qq.com/s/xYU8e6uM5e7bdebI7qjuSw

经过以前博客发布的《Spring Cloud构建微服务架构（五）服务网关》一文，相信你们对于Spring Cloud Zuul已经有了一个基础的认识。经过前文的介绍，咱们对于Zuul的第一印象一般是这样的：它包含了对请求的路由和过滤两个功能，其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础；而过滤器功能则负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础。然而实际上，路由功能在真正运行时，它的路由映射和请求转发都是由几个不一样的过滤器完成的。其中，路由映射主要经过pre类型的过滤器完成，它将请求路径与配置的路由规则进行匹配，以找到须要转发的目标地址；而请求转发的部分则是由route类型的过滤器来完成，对pre类型过滤器得到的路由地址进行转发。因此，过滤器能够说是Zuul实现API网关功能最为核心的部件，每个进入Zuul的HTTP请求都会通过一系列的过滤器处理链获得请求响应并返回给客户端。

下面，咱们就经过本文来详细了解一下Spring Cloud Zuul的过滤器！如下内容节选自《Spring Cloud微服务实战》，稍作加工。

过滤器

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

1
2
3
4
5
6
7
String filterType();

int filterOrder();

boolean shouldFilter();

Object run();

它们各自的含义与功能总结以下：

• filterType：该函数须要返回一个字符串来表明过滤器的类型，而这个类型就是在HTTP请求过程当中定义的各个阶段。在Zuul中默认定义了四种不一样生命周期的过滤器类型，具体以下：
• pre：能够在请求被路由以前调用。
• routing：在路由请求时候被调用。
• post：在routing和error过滤器以后被调用。
• error：处理请求时发生错误时被调用。
• filterOrder：经过int值来定义过滤器的执行顺序，数值越小优先级越高。
• shouldFilter：返回一个boolean类型来判断该过滤器是否要执行。咱们能够经过此方法来指定过滤器的有效范围。
• run：过滤器的具体逻辑。在该函数中，咱们能够实现自定义的过滤逻辑，来肯定是否要拦截当前的请求，不对其进行后续的路由，或是在请求路由返回结果以后，对处理结果作一些加工等。

请求生命周期

上一节中，对于Spring Cloud Zuul中的过滤器类型filterType，咱们已经作过一些简单的介绍，Zuul默认定义了四个不一样的过滤器类型，它们覆盖了一个外部HTTP请求到达API网关，直到返回请求结果的所有生命周期。下图源自Zuul的官方WIKI中关于请求生命周期的图解，它描述了一个HTTP请求到达API网关以后，如何在各个不一样类型的过滤器之间流转的详细过程。

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

核心过滤器

在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-www-form-urlencoded的请求，第二类是Content-Type为multipart/form-data而且是由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-Forwarded-Host、X-Forwarded-Port、X-Forwarded-For、X-Forwarded-Prefix、X-Forwarded-Proto。咱们也能够经过设置zuul.addProxyHeaders=false关闭对这些头域的添加动做。

《Spring Cloud实战小贴士：Zuul处理Cookie和重定向》 一文中提到的加载敏感头信息加入到忽略头信息的操做调用就在PreDecorationFilter过滤器中实现。

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

这里不列出具体代码了，读者可自行根据类名来查看源码了解详细处理过程。下图是对上述过滤器根据顺序、名称、功能、类型作了综合的整理，能够帮助咱们在自定义过滤器或是扩展过滤器的时候用来参考并全面地考虑整个请求生命周期的处理过程。

本文节选自《Spring Cloud微服务实战》，转载请注明出处

相关文章：

• Spring Cloud实战小贴士：Zuul处理Cookie和重定向
• Netflix Zuul与Nginx的性能对比
• Spring Cloud Zuul实现动态路由

活动推荐：Spring Cloud技术沙龙 - 北京站
活动时间：2017年 5 月 6 日 13:00-17:00

活动地点：北京市海淀区上地五街开拓路 11 号福道大厦

活动议程

Agenda

13:00-13:40 签到

14:00-14:30 王鸿飞： Spring Cloud 在新浪商业产品中的实战应用

14:30-15:00 许进：Spring Cloud Zuul 与网关中间件

15:00-15:30 刘思贤：基于 Spring Cloud 的微服务实践

15:30-16:00 现场抽奖 & 茶歇

16:00-16:30 张英磊：Spring Cloud 在云计算 SaaS 中的实战经验分享

16:30-17:00 程天亮：Spring Boot 在链家网实践

报名请至：http://www.hdb.com/party/rrt4b.html

SpringCloud新书推荐

版权声明

本文采用 CC BY 3.0 CN协议 进行许可。 可自由转载、引用，但需署名做者且注明文章出处。如转载至微信公众号，请在文末添加做者公众号二维码。
长按指纹
一键关注