开启重试在某些情况下是有问题的，比如当压力过大，一个实例停止响应时，路由将流量转到另一个实例，很有可能导致最终所有的实例全被压垮。

说到底，断路器的其中一个作用就是防止故障或者压力扩散。用了retry，断路器就只有在该服务的所有实例都无法运作的情况下才能起作用。这种时候，断路器的形式更像是提供一种友好的错误信息，或者假装服务正常运行的假象给使用者。

不用retry，仅使用负载均衡和熔断，就必须考虑到是否能够接受单个服务实例关闭和eureka刷新服务列表之间带来的短时间的熔断。如果可以接受，就无需使用retry。

#retry

#该参数用来开启重试机制 。只设置这个开关，确定好用。 TODO ： 了解下实现原理

spring.cloud.loadbalancer.retry.enabled=true

#断路器的超时时间,断路器的超时时间需要大于ribbon的超时时间，不然不会触发重试。

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000

#ribbon请求连接的超时时间

ribbon.ConnectTimeout=250

#请求处理的超时时间

ribbon.ReadTimeout=1000

#对所有操作请求都进行重试

ribbon.OkToRetryOnAllOperations=true

#对当前实例的重试次数

ribbon.MaxAutoRetries=1

#对下个实例的重试次数

ribbon.MaxAutoRetriesNextServer=1

版本1.5.6

使用Ribbon zuul hystrix

引入重试jar包

org.springframework.retry

spring-retry

参考 LoadBalancerAutoConfiguration 以及RibbonAutoConfiguration

实现原理: RetryLoadBalancerInterceptor 实现 ClientHttpRequestInterceptor 通过拦截器实现

配置

注意:

- ribbon.ConnectTimeout+ribbon.ReadTimeout

- 连接失败的意思是服务宕机,请求不可到达, 并不是服务报错

zuul是什么?

front door. API Gateway.Zuul is a JVM based router and server side load balancer by Netflix.所有请求的入口。

As an edge service application, Zuul is built to enable dynamic routing, monitoring, resiliency and security. 作为边界应用服务，zuul能实现动态路由、监控、弹性与安全性。

用groovy编写。

Netflix uses Zuul for the following:

Authentication 认证

Insights 洞察力

Stress Testing 压力测试

Canary Testing 金丝雀测试

Dynamic Routing 动态路由

Service Migration 服务迁移

Load Shedding 减载

Security 安全

Static Response handling 静态响应处理

Active/Active traffic management

如果以后想设计网关，可按照上面进行对标设计。

zuul 请求处理过程：

Spring  Cloud之Feign、ribbon设置超时时间和重试机制的总结

一、 Feign设置超时时间

使用Feign调用接口分两层，ribbon的调用和hystrix的调用，所以ribbon的超时时间和Hystrix的超时时间的结合就是Feign的超时时间

#hystrix的超时时间

hystrix:

command:default:

execution:

timeout:

enabled:trueisolation:

thread:

timeoutInMilliseconds:9000#ribbon的超时时间

ribbon:

ReadTimeout:3000ConnectTimeout:3000

一般情况下 都是 ribbon 的超时时间(

因为ribbon的重试机制和Feign的重试机制有冲突，所以源码中默认关闭Feign的重试机制，源码如下

要开启Feign的重试机制如下：(Feign默认重试五次 源码中有)

@Bean

Retryer feignRetryer() {return newRetryer.Default();

}

二、ribbon的重试机制

设置重试次数：

ribbon:

ReadTimeout:3000ConnectTimeout:3000MaxAutoRetries:1#同一台实例最大重试次数,不包括首次调用

MaxAutoRetriesNextServer:1#重试负载均衡其他的实例最大重试次数,不包括首次调用

OkToRetryOnAllOperations:false #是否所有操作都重试

根据上面的参数计算重试的次数：MaxAutoRetries+MaxAutoRetriesNextServer+(MaxAutoRetries *MaxAutoRetriesNextServer) 即重试3次 则一共产生4次调用

如果在重试期间，时间超过了hystrix的超时时间，便会立即执行熔断，fallback。所以要根据上面配置的参数计算hystrix的超时时间，使得在重试期间不能达到hystrix的超时时间，不然重试机制就会没有意义

hystrix超时时间的计算： (1 + MaxAutoRetries + MaxAutoRetriesNextServer) * ReadTimeout 即按照以上的配置 hystrix的超时时间应该配置为 (1+1+1)*3=9秒

当ribbon超时后且hystrix没有超时，便会采取重试机制。当OkToRetryOnAllOperations设置为false时，只会对get请求进行重试。如果设置为true，便会对所有的请求进行重试，如果是put或post等写操作，如果服务器接口没做幂等性，会产生不好的结果，所以OkToRetryOnAllOperations慎用。

如果不配置ribbon的重试次数，默认会重试一次

注意：

默认情况下,GET方式请求无论是连接异常还是读取异常,都会进行重试

非GET方式请求,只有连接异常时,才会进行重试

原文：https://blog.csdn.net/east123321/article/details/82385816

SpringCloud重试机制配置

SpringCloud重试retry是一个很赞的功能，能够有效的处理单点故障的问题。主要功能是当请求一个服务的某个实例时，譬如你的User服务启动了2个，它们都在eureka里注册了，那么正常情况下当请求User服务时，ribbon默认会轮询这两个实例。此时如果其中一个实例故障了，发生了宕机或者超时等，如果没有配置启用重试retry策略，那么调用方就会得到错误信息或者超时无响应或者是熔断返回的信息。我们希望的自然是一个故障了，会自动切换到另一个去访问。

最简单的方法就是retry。

需要先在pom.xml里加入

org.springframework.retry

spring-retry

Ribbon、zuul、feign都可以配置各自的retry方式。

1 ribbon配置如下

@Bean

@LoadBalanced

RestTemplate restTemplate() {

HttpComponentsClientHttpRequestFactory httpRequestFactory= newHttpComponentsClientHttpRequestFactory();

httpRequestFactory.setReadTimeout(5000);

httpRequestFactory.setConnectTimeout(5000);return newRestTemplate(httpRequestFactory);

}

2 zuul配置如下

zuul的重试比较简单，不需要任何代码，直接在yml里配置即可。

注意，配置时，ribbon开头的在yml里是不给提示的，不要以为不提示就是没效果，其实是可以用的。

这个ReadTimeout和ConnectTimeout区别是很大的，ConnectTimeout是指建立连接的时间，如果目标服务宕机或网络故障，那么响应的就是ConnectTimeout，无法连接。而ReadTimeout则是连接建立后，等待目标服务返回响应的时间，譬如目标服务做了一个复杂操作导致耗时较长，那么会触发ReadTimeout。

譬如zuul路由了/user路径到user服务上，如果User1实例宕机了，那么配置了retry的zuul就会在重试MaxAutoRetries次数后，切换到另一个实例User2上。如果User2也故障了，那么返回404.

retryableStatusCodes里面有几个错误码，意思就是遇到哪些错误码时触发重试。默认是404，我多配了几个，仅供参考。

3 feign配置如下