前面我们已经讲了netflix中的eureka，现在我们来讲讲netflix中的zuul（网关）。
首先讲一下为什么会有zuul出现，任何东西的出现都是有原因的。现在我讲一下两种情况让大家弄懂zuul的大概作用。
1，首先我们在弄微服务项目的时候，会将传统的一个大项目A细分化成很小的，功能独立的项目。问题来了，以前的传统大项目A可能访问之前有什么权限控制，token验证之类的东西。如果使用微服务，将大项目A切割成很多小项目，是不是这些小项目都要做这些权限控制，那代码就显得重复。如果以后要改相关控制权限的代码，那岂不是要全部微服务项目都要改一遍，这种肯定也是不行的。也有人会想到可以将权限控制的代码另起一个项目，这种做法确实可以做到方便管理权限控制代码，因为只要改一份就行了，但这样的话又有一个问题就是，所有的项目都要调用这个权限控制项目的服务。而zuul提供了zuulfilter过滤器，之前在请求到达网关的时候直接权限控制调，而不需要重新调用其他项目的服务。
2，我们运维人员在做负载均衡的时候一般是利用Nginx，或者硬件设置f5这类的软硬件。负载均衡的配置大致就是你要跟什么url，提供一个服务器组。简单的一个负载均衡的配置：/test/** ; https://191.1.1.20:81/, https://191.1.1.21:82/。
意思就是如果客户发过来的请求包含/test/，将在服务器组中的这两个地址根据相关负载均衡机制选择其中一个ip。像这种传统的负载均衡有一个很大的弊端，就是等你的项目越来越多，你需要花很大的时间，精力去维护这些ip。zuul还有一个作用是负载均衡作用，与传统的不一样，它是面向服务的负载均衡，不用去管理这些繁杂的ip数据，具体后面再详细讲
zuul的作用：动态路由（面向服务的路由），监控，校验过滤等功能
主要配置详情：
传统路由配置（单实例配置）：
zuul.routes.<route>.path=/test/**
zuul.routes.<route>.url=ip:端口/test
传统路由配置（多实例配置）：
zuul.routes.<route>.path=/test/**
<route>.ribbon.listOfServers=ip:port/list,ip:port2/list
前缀配置：
给统一路由加前缀
zuul:
prefix: /myapizuul的前缀，默认会从请求中移除。
例如
zuul.routes.<route>.path=/test/**
zuul.routes.<route>.url=ip:port/test/list
默认是zuul.stripPrefix=true ,当为true的时候会将test从请求路径中移除，变成ip:port/list
zuul.stripPrefix=true ,当为false的时候，变成ip:port/test/list（不会去除）
问题
1，回话保持问题Cookie
一个请求到zuul，再到相应的服务，之后返回结果给用户。我们发现Cookie和Authorization都没有被正确地传递给具体服务，所以最终导致会话状态没有得到保持的现象。这个是zuul的过滤器去掉了。解决这种问题的方式也很简单
- 全局设置：
zuul.sensitive-headers=
- 指定路由设置：
zuul.routes.<routeName>.sensitive-headers=zuul.routes.<routeName>.custom-sensitive-headers=true
最好不好用全局的，最好是我们将web的请求设置一下就行，将其它的restful风格的请求还是按照默认
2，重定向问题
在使用Spring Cloud Zuul对接Web网站的时候，处理完了会话控制问题之后。往往我们还会碰到如下图所示的问题，我们在浏览器中通过Zuul发起了登录请求，该请求会被路由到某WebSite服务，该服务在完成了登录处理之后，会进行重定向到某个主页或欢迎页面。此时，仔细的开发者会发现，在登录完成之后，我们浏览器中URL的HOST部分发生的改变，该地址变成了具体WebSite服务的地址了。这就是在这一节，我们将分析和解决的重定向问题！
zuul.add-host-header=true
就能让原本有问题的重定向操作得到正确的处理