一，Zuul的应用场景
Zuul是Netflix基于JVM的路由器和服务器端负载均衡器。
Zuul可以通过加载动态过滤机制，从而实现以下各项功能：
验证与安全保障：识别面向各类资源的验证要求并拒绝那些与要求不符的请求。
审查与监控：在边缘位置追踪有意义数据及统计结果，从而为我们带来准确的生产状态结论。
动态路由：以动态方式根据需要将请求路由至不同后端集群。
压力测试：逐渐增加指向集群的负载流量，从而计算性能水平。
负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求。
静态响应处理：在边缘位置直接建立部分响应，从而避免其流入内部集群。
多区域弹性:：跨越AWS区域进行请求路由，旨在实现ELB使用多样化并保证边缘位置与使用者尽可能接近。
Zuul的规则引擎允许任何JVM语言编写规则和过滤器，内置支持Java和Groovy。
二，Zuul的配置文件详解
1，超时时间配置
Spring Cloud因为整合了zuul，ribbon，hystrix，所以超时时间也比较复杂，到底使用哪个超时时间配置，我们来看一下。
zuul的超时时间配置：
zuul.host.socket-timeout-millis
zuul.host.connect-timeout-millis
ribbon的超时时间配置：
ribbon.ConnectTimeout
ribbon.ReadTimeout
hystrix的超时时间配置：
hystrix.command.default.execution.
isolation.thread.timeoutInMillisecond
如果我们既设置了ribbon的超时时间，又设置了hystrix的超时时间，那么zuul最终会取较小的那个值。
2，host最大连接数配置
zuul.host.maxTotalConnections：最大连接数。默认值是200，我们项目配置的是2000。
zuul.host.maxPreRouteConnections：每个路由的最大连接数。默认20，我们项目配置的是500。
3，路由配置
zuul.routes.微服务.path：请求转发路径，也就是说zuul会把带有当前的请求转发到对应的名称为serviceId的微服务上。
zuul.routes.微服务.serviceId：微服务的唯一标识。
zuul.routes.微服务.stripPrefix：是否去掉前缀。这个配置是配合zuul.prefix来使用的，如果我们设置了前缀，可以通过设置stripPrefix=true来自动去掉前缀。
zuul.routes.xxx.url：配置反向代理。
zuul.routes.微服务.sensitive-headers：过滤掉客户端附带的headers相关属性。Zuul默认会过滤掉下面三个属性：
Cookies
Set-Cookie
Authorization
具体可以参考源码：ZuulProperties
zuul.routes.微服务.ignored-headers：
具体可以参考源码：ZuulProperties。
4，hystrix相关配置
#hystrix的隔离策略
hystrix.command.default.execution.isolation.strategy=THREAD
Hystrix的隔离策略有两种：分别是线程隔离和信号量隔离。
THREAD（线程隔离）：使用该方式，HystrixCommand将会在单独的线程上执行，并发请求受线程池中线程数量的限制。
SEMAPHORE（信号量隔离）：使用该方式，HystrixCommand将会在调用线程上执行，开销相对较小，并发请求受信号量的个数的限制。
Hystrix中默认并且推荐使用线程隔离，因为这种方式有一个除网络超时以外的额外保护层。
一般来说，只有当调用负载非常高时（例如每个实例每秒调用数百次）才需要使用信号量隔离，因为这种场景下使用THREAD开销会比较高。信号量隔离一般仅适用于非网络调用的隔离。
#设置HystrixCommand的执行是否有超时限制。
hystrix.command.default.execution.timeout.enabled=false
#等待hystrix命令执行的超时时间
hystrix.command.default.execution.isolation.thread.timeoutInMillisecond=90000
设置调用者等待命令执行的超时限制，超过此时间，HystrixCommand被标记为TIMEOUT，并执行回退逻辑。
注意：超时会作用在HystrixCommand.queue()，即使调用者没有调用get()去获得Future对象。
#HystrixCommand执行方法允许的最大请求数。
hystrix.command.default.fallback.isolation.semaphore.maxConcurrentRequest=200
设置当使用ExecutionIsolationStrategy.SEMAPHORE时，HystrixCommand执行方法允许的最大请求数。如果达到最大并发数时，后续请求会被拒绝。信号量应该是容器（比如Tomcat）线程池一小部分，不能等于或者略小于容器线程池大小，否则起不到保护作用。
#设置断路器是否生效
hystrix.command.default.circuitBreaker.enabled=true
#是否强制打开断路器
hystrix.command.default.circuitBreaker.forceOpen=false
如果该属性设置为true，强制断路器进入打开状态，将会拒绝所有的请求。该属性优先级比circuitBreaker.forceClosed高。
#是否强制关闭断路器
hystrix.command.default.circuitBreaker.forceClosed=false
如果该属性设置为true，强制断路器进入关闭状态，将会允许所有的请求，无视错误率。
#线程池核心线程数
hystrix.threadpool.default.coreSize=2000
这里的coreSize和ThreadPoolExecutor的corePoolSize是不同的概念。hystrix会对请求进行隔离，这个隔离是通过线程池来实现的。hystrix会根据调用的服务，对线程池进行重新划分，这个coreSize是hystrix划分的线程池的核心线程数。
#最大信号量
zuul.semaphore.max-semaphore=5000
设置当使用ExecutionIsolationStrategy.SEMAPHORE时，信号量的最大值。
三，Zuul的隔离模式
准确的说，Zuul没有隔离模式，我们这里的隔离模式本质上是Hystrix的隔离模式，在Spring Cloud体系中，Zuul默认整合了Hystrix。
在Hystrix的jar包下，有一个HystrixCommandProperties，这个类中定义了2个隔离级别：SEMAPHORE和THREAD，默认使用SEMAPHORE。
SEMAPHORE：信号量隔离级别。
THREAD：线程池隔离级别。
这2种隔离级别有何区别呢？
THREAD（线程隔离）：使用该方式，HystrixCommand将会在单独的线程上执行，并发请求受线程池中线程数量的限制。
SEMAPHORE（信号量隔离）：使用该方式，HystrixCommand将会在调用线程上执行，开销相对较小，并发请求受信号量的个数的限制。
Hystrix中默认并且推荐使用线程隔离，因为这种方式有一个除网络超时以外的额外保护层。
一般来说，只有当调用负载非常高时（例如每个实例每秒调用数百次）才需要使用信号量隔离，因为这种场景下使用THREAD开销会比较高。信号量隔离一般仅适用于非网络调用的隔离。
四，Zuul架构图
这里简单总结一下Zuul的工作原理。
1，ZuulServlet
ZuulServlet是Zuul的入口。ZuulServlet继承了抽象类HttpServlet，把HttpServlet包装成ZuulServlet。ZuulServlet实现了GenericServlet的init()方法，并且实现了HttpServlet的service()方法。
也就是说，ZuulServlet具备了为Zuul提供服务的能力，通过ZuulServlet.service()，ZuulServlet可以开启Zuul服务了！
2，ZuulRunner
ZuulServlet最终会把请求交给ZuulRunner，由ZuulRunner来执行具体的逻辑。
ZuulRunner做了什么呢？ZuulRunner拿到RequestContext，然后设置了HttpServletRequest和HttpServletResponse就完事了。然后把请求交给FilterProcessor。
3，FilterProcessor
FilterProcessor是过滤器的最终执行者。
4，FilterLoader
FilterLoader借助FilterRegistry，实现了获取查询和新增过滤器的功能。有一点需要注意，如果拿到的ZuulFilter为空，FilterLoader会尝试使用GroovyCompiler加载ZuulFilter。
