zuul的执行流程
Zuul是服务网关,是微服务的访问入口和出口,它的核心工作思想是:根据客户端的请求URL,通过路由映射到相应的微服务,然后通过服务发现的方式结合Ribbon实现对下游微服务的负载均衡 。Zuul通过大量的Filters实现上述功能,在zuul底层通过ZuulServlet定义整个请求的流程,请求会调用经过pre前置过滤器,route路由过滤器,post后置过滤器,然后返回响应结果,下面是一张摘抄于SpringCloud官网的zuul的生命周期图
这张图的大致流程为:
- 当客户端请求过来首先会到 "pre" 前置过滤器,前置过滤器会根据URL决定执行哪个Routing 路由过滤器
- 请求到达”routing” 路由过滤器,路由过滤器会选择一个微服务去执行,底层使用了Ribbon进行负载均衡
- 请求到达某个微服务,执行完成后又会回到“routing”路由过滤器,然后执行“post”后置过滤器,请求结束
- 如果过滤器在执行的过程中报错,则会执行“error”过滤器,然后执行“post”过滤器,最后返回结果
- 如果是“post”过滤器执行出错,然后执行“error”过滤器,但是不会再回到“post”过滤器,而是最返回结果
Zuul的核心Filters
下面是zuul的默认filters ,位于 spring-cloud-netflix-core.jar的 zuul.filters包中,它们的执行顺序在FilterConstants类:
类型 | 过滤器 | 描述 | 顺序 |
---|---|---|---|
pre | ServletDetectionFilter | 在pre过滤器中,ServletDetectionFilter是第一个执行的过滤器,检测请求是用 DispatcherServlet还是 ZuulServlet,将结果设置到RequestContext中 | -3 |
pre | Servlet30WrapperFilter | 主要是将原始请求进行包装,将原始的HttpServletRequest请求包装成Servlet30RequestWrapper类型 | -2 |
pre | FormBodyWrapperFilter | 同Servlet30RequestWrapper一样,也是对请求的一个包装,只不过他只包装表单数据,即:content-type中必须带有“application/x-www-form-urlencoded”或“multipart/form-data” | -1 |
error | SendErrorFilter | 这个是用来发送错误的Filter | 0 |
pre | DebugFilter | 设置请求过程是否开启debug,将当前请求上下文中的debugRouting 和debugRequest 参数设置为true |
1 |
pre | PreDecorationFilter | 基本的路由转发配置,根据uri调用哪一个route过滤器 | 5 |
route | RibbonRoutingFilter | 服务路由的过滤器,使用用Ribbon 做负载均衡,hystrix做熔断 | 10 |
route | SimpleHostRoutingFilter | 简单主机路由过滤器,如果使用url路由,则用这个过滤器 | 100 |
route | SendForwardFilter | 它使用RequestDispatcher转发请求 | 500 |
post | SendResponseFilter | SendResponseFilter是Zuul的最后一个Filter,负责最终响应结果的输出。 | 1000 |
文章结束,这一章作为铺垫,我们将在后面章节从源码的角度详细介绍Zuul的核心配置和执行流程