功能特点说明

1. Zuul解决的是对外提供微服务的问题，比如气象局对外开放气象信息查询接口，这时候Zuul就来实现反向代理等功能。在一个系统内部之间的微服务调用不需要zuul，直接微服务间通过eureka注册，通过Ferign远程调用即可。

2. Zuul只适合提供接口调用的数据发送，比如json数据，或者最多是一个页面，完全没有nginx丰富的路由适配和跳转的功能的。

3. requestPath的serviceUrl的解耦

• 传统nginx可以解决反向代理和负载均衡，但是 nginx的path(locationUrl)配置和应用url耦合在一起，而url是可能经常变更的。

• Zuul集成了Eureka的话，在zuul服务器上实现requestPath绑定serviceId（也就是applicationName），从而实现和应用程序url的解耦，只要服务提供方的serviceId是一样的即可，都注册在eureka上，就相互找的到，无论应用程序url怎么变，ip变或者端口变了都无所谓，只要serviceId不变即可。

  zuul.routes.main-psm.path=/main/** zuul.routes.main-psm.serviceId=spring-cloud-psm

1. Zuul结合Filter实现安全认证，比如验证Token等信息，主流的还是整合shiro或者OAUTH。

2. Zuul结合熔断机制和重试机制，对远程调用服务提供更友好的支持

3. 多个Zuul结合前端的nginx一起用实现高可用，不过没怎么理解透彻

简单的反向代理

通过指定一个自定义的应用名称来反向代理请求
zuul.routes.${应用命名}.path=路径
zuul.routes.${应用命名}.url=对应的代理路径

zuul.routes.hello.path=/hello/**
zuul.routes.hello.url=http://localhost:9000/

结合eureka来实现 反向代理和 应用服务器的解耦、默认负载均衡

1. 配置path和serviceId（对应eureka注册的producer的spring.application.name

   spring.application.name=gateway-service-zuul server.port=8888 zuul.routes.api-a.path=/test/** zuul.routes.api-a.serviceId=spring-cloud-producer eureka.client.serviceUrl.defaultZone=http://localhost:8000/eureka/

2. 如果producer里面有多个应用程序且spring.application.name一样的话，默认轮询实现负载均衡

3. 可以不在zuul里面配置path和serviceId，默认路径
   http://ZUUL_HOST:ZUUL_PORT/微服务在Eureka上的serviceId/**
   例如：下面直接转发到spring-cloud-producer项目里面，只要在eureka上面注册过
   http://localhost:8888/spring-cloud-producer/hello?name=hzs123

实现全局性质的拦截器

http://www.ityouknow.com/springcloud/2018/01/20/spring-cloud-zuul.html
Filter的生命周期有4个，分别是“PRE”、“ROUTING”、“POST”、“ERROR”，整个生命周期可以用下图来表示。

可以通过继承ZuulFilter重写相关方法，来实现相关的拦截器，比如对url权限等操作进行全局性质的拦截

实现应用层面的熔断器

当某个应用出问题的时候，可以封装报错的界面，直接熔断，避免无效等待和调用

@Component
public class ProducerFallback implements FallbackProvider {
    @Override
    public String getRoute() {
        return "spring-cloud-producer";
    }
}

配置路由重试

当网络异常的时候，一次失败的调用不会直接返回结果，而是重试N次直到获取到正确的结果，依赖spring-retry这个jar包