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的核心配置和执行流程
