前言
在集群环境中，多个节点来提供服务，难免会有某个节点故障
用Nginx做负载均衡的时候，如果你的应用是无状态的，是可以滚动发布的，也就是一台台去重启应用
这样对用户其实是影响比较小的，因为Nginx在转发请求失败后会重新将该请求转发到别的实例上去
Zuul中是否也存在这样的问题
我们在用Zuul构建API网关时，发现eureka中的服务挂了一个, 由于ribbon的默认负载机制是轮询
如果一个服务下线，eureka并不会马上清除信息，不像zookeeper那样基于watcher可以实时监控下线
所以在eureka中挂掉的服务没有被清空信息时，zuul会转发到已经故障的机器，导致请求失败
当然这个不会持续很久， 当连续失败hystrix就会处于打开状态，就算有一次失败，我觉得也是不能容忍的
所以我们需要有像Nginx中那样重试的机制来保证请求的成功，哪怕延迟个几百毫秒响应给使用方
在Zuul中我们可以配置ribbon的重试机制来实现，必须依赖一个 Spring Retry
官方文档地址：http://cloud.spring.io/spring-cloud-static/Dalston.SR4/multi/multi_netflix-metrics.html
具体配置如下:
pom.xml
<!-- 重试机制 ，必须配，否则重试不生效 --><dependency> <groupId>org.springframework.retry</groupId> <artifactId>spring-retry</artifactId></dependency>
application.properties
# hystrix的超时时间必须大于ribbon的超时时间hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000# 开启重试zuul.retryable=truespring.cloud.loadbalancer.retry.enabled=true# 请求连接的超时时间ribbon.connectTimeout=2000# 请求处理的超时时间ribbon.readTimeout=5000# 对当前实例的重试次数ribbon.maxAutoRetries=1# 切换实例的重试次数ribbon.maxAutoRetriesNextServer=3# 对所有操作请求都进行重试ribbon.okToRetryOnAllOperations=true
在zuul中要生效除了要依赖spring-retry之外还需要配置zuul.retryable=true
测试步骤
相同的服务注册2个到eureka中
启动zuul网关
访问API
停掉一个服务
继续访问API
作者：尹吉欢
链接：https://www.jianshu.com/p/cdb6fedcab70
随时随地看视频
