Spring Cloud Ribbon 重试机制

前言

在集群环境中，多个节点来提供服务，难免会有某个节点故障

用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