一文详解Spring Cloud Feign重试机制

Feign组件默认使用Ribbon的重试机制并增加了根据状态码判断重试机制，默认情况下是不启用的。Feign使用的是Spring Retry组件，需要引入依赖才能启用。

eureka-client 是自己的serverId， MaxAutoRetries 同一台服务器上的最大重试次数（不包括第一次尝试）， MaxAutoRetriesNextServer 要重试的下一个服务器的最大数量（不包括第一个服务器）， retryableStatusCodes 可以根据接口返回的状态码判断是否重试其他服务， OkToRetryOnAllOperations 只对所有的超时请求重试

注意 ： Ribbon的重试机制只有对GET请求或者设置了OkToRetryOnAllOperations生效 详情请查看源码：

Feign对返回状态码做了重试判断RetryableFeignLoadBalancer

重试机制用的是Spring Retry组件当抛出异常时进行重试！

GET请求指的是feign client 请求其他client时声明的那个interface中mapping注解类型，RequestMapping不设置method默认为GET请求

1.zuul相关的默认配置 springcloud(F版)

有些书上说，配置当中的ConnectTimeout和ReadTimeout是当HTTP客户使用HttpClient的时候生效的，参数会被设置到HttpClient中，但我在使用过程中，并不是只有HttpClient才会生效。

默认情况下ribbon超时时间为1秒，我们模拟一个2秒的业务让ribbon超时。

当MaxAutoRetries大于0时，调用也没有发生变化。

至此说明实验一中重试未起作用。

突然有一个想法，网关重试机制会不会和ribbon底层使用的http有关呢，默认情况下ribbon使用的是httpclient,那么我如果换成使用okhttp呢，于是，我把ribbon底层换成了okhttp又重复了一遍实验一

ribbon.MaxAutoRetries: 1

通过打印异常堆栈，可以发现其中的端倪

异常已经清晰的告诉我们了原因：

Number of retries on next server exceeded max 1 retries ，就是重试机器的次数已经答到了设置的上限，因为我们MaxAutoRetriesNextServer设置的是1，意思就是我们重试一台。因此我们吧

ribbon.MaxAutoRetries: 2

zuul使用httpClient并支持重试

zuul网关重试就先写到这，主要是记录了一下我自己的使用当中遇到的情况。欢迎拍砖。

---