Zuul网关简析

之前讲过了其他的SpringCloud中的组件，今天来说一下最后一个基本组件Zuul

首先简单讲一下Zuul的作用，他在微服务这个架构里面扮演的角色是网关，那么为什么我们需要网关呢？

1. 在微服务的架构中，可能会有非常多的服务，服务都会有各自的服务名称，如果前端需要调用后端的接口的话，那么如此纷繁复杂的服务名称肯定会让前端崩溃，这个时候我们就需要屏蔽掉这些服务所带来的影响，这时我们需要一个门面，也就是Zuul（类比一下slf4j，这也是一个经典的门面，调用slf4j，我们就不需要关心实际调用的日志框架是log4j、logback还是log4j2等等了）
2. 既然Zuul作为了门面，那么他也可以做一些统一的处理，比如安全认证、限流、异常处理等问题

Zuul的源码可以说是SpringCloud这几个组件中最简单的了，核心就是一些filter，这些过滤器分为了几类，分别是pre过滤器、routing过滤器、post过滤器和error过滤器，先画一张图总览一下，之后再接着讲

我们先从pre过滤器来说，pre过滤器中包含了很多filter，其中有ServletDetectionFilter、Servlet30WrapperFilter、FormBodyWrapperFilter、DebugFilter、PreDecorationFilter，其中最重要的就是PreDecorationFilter，他负责解析请求url，然后将url匹配我们的application.yml文件中的映射

举个例子，你的Zuul网关的application.yml中可能会有这么一段配置信息

zuul:
  routes:
    serviceName:
      path: /test/**

那么当你请求 /test/XXX 的时候，实际请求会请求到对应的服务的 /XXX，这一步其实就是Zuul的PreDecorationFilter帮我们做了一步映射

pre过滤器之后就轮到了routing过滤器，routing过滤器包含了RibbonRoutingFilter、SimpleHostRoutingFilter、SendForwardFilter，默认情况下使用的是RibbonRoutingFilter，这个filter会将请求转发到服务

那么这一步是怎么做到服务转发的呢？其实很简单，通过这个filter的名称，我们可以猜到这个filter使用了ribbon，ribbon的作用其实就是负载均衡，还记得上面的application.yml中的serviceName吗，这里就告诉你了需要转发的服务名称，此时通过ribbon，然后就可以从服务注册中心中获取到所有的服务实例，然后负载均衡出来一个实例，并进行服务的转发

比如我们上面的请求具体是localhost:8080/test/XXX ，那么通过服务的转发，实际的url可能就变成了localhost:8888/XXX，localhost:8888其实就是要转发到的服务的ip和端口号

讲完了pre过滤器和routing过滤器，其实Zuul最重要的逻辑就已经讲完了，之后的post过滤器，其实包含了LocationRewriteFilter和SendResponseFilter，默认情况下LocationRewriteFilter是不会启用的，SendResponseFilter其实就是从一个inputStream读取了服务返回的结果，然后将结果写入outStream，最后输出到了浏览器中

最后一个过滤器是error过滤器，在之前讲的三种过滤器出现异常的时候，都会调用SendErrorFilter，默认情况下，如果有异常，打印出异常日志，在控制台，将异常信息输出到浏览器中去

这就是所有的四种Zuul的过滤器，是不是很简单，其实最核心的逻辑就是将请求的url通过application.yml中的配置映射到实际服务的url，并转发到对应的服务上