学习微服务网关zuul，看这篇就够了
作者：爱撒谎的男孩
原文：https://chenjiabing666.github.io/2018/12/25/zuul%E6%9C%8D%E5%8A%A1%E7%BD%91%E5%85%B3/本文系读者投稿，已获作者原创授权。
如果你有好文章，可以戳这里投稿。
Zuul
简介
Zuul包含了对请求的路由和过滤两个主要的功能，其中路由功能负责将外部的请求转发到具体的微服务实例上，是实现外部访问统一入口的基础上，而过滤功能则负责对请求的处理过程进行干预，是实现请求校验，服务聚合等功能的基础。
Zuul和Eureka进行整合，将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获取其他微服务的信息，也即以后访问微服务都是通过Zuul跳转后获得。
代理+路由+过滤三大功能。
使用
需要和Eureka客户端结合使用，依赖如下：
添加配置，将其注册到eureka中，如下：
在主启动类上添加@EnableZuulProxy这个注解，如下:
启动即可，在eureka中看到注册进入即可
之后只需要通过zuul访问其他的微服务提供者即可，比如服务提供者的实例名称为dept-provider，那么通过zuul访问的路径为
http://localhost:9001/dept-provider/dept/1路由映射规则
代理名称
之前的配置访问的还是需要带上微服务的实例名称，但是我们不想微服务的实例名称暴露，那么此时就需要使用代理名称替代，配置如下:
- 使用
ignored-services忽略真实的服务名称访问，可以同时指定多个，其中服务名称必须和服务配置文件中一样。 - 在routes下指定多个路由映射规则。
按照上面的配置完成之后就可以直接使用映射的路由访问即可，如：
http://zuul.com:9001/api-order/order/1设置统一前缀
我们可以在所有的访问uri前面加上统一的前缀，配置如下:
使用zuul.prefix加上统一的前缀即可
通过上面的配置，此时的访问路径变成
http://zuul.com:9001/chenjiabing/api-order/order/1某个uri取消路由
使用zuul.ignored-services是忽略一个或者多个微服务的全部接口，但是如果我们可以更细化
如果我们需要隐藏一些敏感的接口不给访问，我们可以在yml文件中配置，如下:
传递敏感头信息
默认zuul是不能传递头信息的，比如cookie，默认的设置了三个字段，如下:
如果我们想让它不过滤，只需要将其设置为空，或者不配置其他的，如下：
- 将
sensitive-headers这个值设置为空即可 - 这个配置只是针对
order-provider这个微服务起作用
上面的配置是针对单个服务的设置，我们也可以配置针对所有的服务，如下：
过滤器
生命周期
Filter 的生命周期有 4 个，分别是 “PRE”、“ROUTING”、“POST” 和“ERROR”，整个生命周期可以用下图来表示
生命周期解释如下：
PRE：这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、鉴权、限流、参数校验、请求转发，在集群中选择请求的微服务、记录调试信息等。ROUTING：这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求，并使用 Apache HttpClient 或 Netfilx Ribbon 请求微服务。POST：这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的 HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等。ERROR：在其他阶段发生错误时执行该过滤器。 除了默认的过滤器类型，Zuul 还允许我们创建自定义的过滤器类型。例如，我们可以定制一种 STATIC 类型的过滤器，直接在 Zuul 中生成响应，而不将请求转发到后端的微服务。
前置过滤器的使用
利用前置过滤器实现检测token是否正确，如果不正确，那么直接返回权限不足401状态码，不路由微服务。
继承ZuulFilter。
注入到ioc容器中。
后置过滤器的使用
利用后置过滤器在响应头中添加内容，和前置过滤器的使用一样，只是使用的过滤器的类型不用，如下：
禁用某种过滤器
如果我们想要禁用某种过滤器（自定义或者zuul自身的），我们可以在配置中设置，格式：zuul.<SimpleClassName>.<filterType>.disable=true，比如禁用我们TokenFilter，如下：
限流
令牌桶算法
https://blog.csdn.net/tianyaleixiaowu/article/details/74942405
https://baike.baidu.com/item/%E4%BB%A4%E7%89%8C%E6%A1%B6%E7%AE%97%E6%B3%95/6597000?fr=aladdin
系统按照恒定的速率往指定大小的桶里添加令牌，每来一个请求就消耗一个令牌，如果桶内没有令牌表示此事的请求流量已经超过设置的大小了，应该做出相应的响应或者直接抛出异常
实现
使用前置过滤器，在请求被转发之前调用，限流的过滤器应该是所有过滤器中优先级最大的
使用google开源的组件Guava
多维度限流
https://segmentfault.com/a/1190000012252677
鉴权
https://www.jianshu.com/p/f89f5557990f
一些api只有具有某些权限的时候才可以被调用，比如用户的一些相关信息，只有在用户登录之后才可以调用，否则将会提示没有权限
实现
我们在用户登录成功之后会在返回头中添加cookie的值为openId=random(随机数)，并且将其保存在redis中（key=openId_userId，value=random）
我们事先将指定权限的接口uri存放在数据库中，在zuul中定义一个鉴权的过滤器，如果请求过来了，判断这个uri是否需要某种权限才能调用，如果不需要直接路由即可，如果需要那么判断cookie中是否有openId，如果没有表示没有登录，权限不够，如果有，需要判断和redis中的值是否相同，如果相同，表示有权限，直接路由到服务即可。
这里将部分逻辑写在shouldFilter()方法中，限制范围（判断请求的uri是否需要鉴权），run()方法中只需要判断是否具有权限即可。
跨域
超时时间设置
我们在使用zuul访问服务的时候，一旦服务超过很短的时间没有响应，那么zuul就会自动熔断，默认的时间是2秒，但是可以通过配置修改，如下：由于zuul使用ribbon实现负载均衡，因此这里还需要配置ribbon的超时时间，否则配置将不会生效
服务熔断
当请求的服务响应时间超时或者服务不可用的时候zuul会直接响应异常，我们可以设置熔断，只需要在zuul的服务中配置即可，如下：
zuul的重试
有时候因为网络或者其它原因，服务可能会暂时的不可用，这个时候我们希望可以再次对服务进行重试，Zuul也帮我们实现了此功能，需要结合Spring Retry 一起来实现
依赖：
在配置文件中配置如下：
- 在zuul中开启重试机制
- 配置ribbon的重试次数
- 默认请求超时时间很短，还可以配置ribbon的超时时间
Zuul的高可用
将多个zuul的微服务注册到Eureka中的（集群）
Nginx和Zuul混搭的方式，可以将Nginx的请求转发到多个zuul中，zuul再路由给指定的微服务
完整的配置
消费端的使用
前提：
- zuul微服务（zuul-server）注册到eureka注册中心
- 微服务提供者注册到Eureka注册中心，zuul-server配置的路由是api-order
- 服务消费者注册到Eureka中
那么如果消费者想用通过zuul-server访问到服务提供者，那么可以直接写http://zuul-server/api-order/order/{id}
源码
https://gitee.com/chenjiabing666/zuul-server.git
参考文章
https://windmt.com/2018/04/23/spring-cloud-11-zuul-filter/
https://cloud.spring.io/spring-cloud-netflix/2.0.x/single/spring-cloud-netflix.html#_router_and_filter_zuul
https://mp.weixin.qq.com/s/FsvZgkvpI0S6rposacGiiQ