spring cloud中的重試機制應該說是比較混亂的，不同的版本有一定區別，實現也不大一樣，好在spring cloud camden之後已經基本穩定下來，dalston中又進行了一些改進，詳情暫且不表。
下面我們來詳細**。
筆者使用的版本是spring cloud dalston sr4，同樣適應於edgware以及更高版本，對於dalston此前的版本，本文不做討論，大家可自行研究。
對於整合了ribbon的resttemplate，例如乙個resttemplate新增了@loadbalanced註解
@bean
@loadbalanced
public resttemplate resttemplate()
spring:
cloud:
loadbalancer:
retry:
enabled: true
ribbon:
# 同一例項最大重試次數，不包括首次呼叫
maxautoretries: 1
# 重試其他例項的最大重試次數，不包括首次所選的server
maxautoretriesnextserver: 2
# 是否所有操作都進行重試
oktoretryonalloperations: false
feign.retryer.default#default()，重試5次。但feign整合了ribbon，ribbon也有重試的能力，此時，就可能會導致行為的混亂。
spring cloud意識到了此問題，因此做了改進，將feign的重試改為feign.retryer#never_retry，如需使用feign的重試，只需使用ribbon的重試配置即可。因此，對於camden以及以後的版本，feign的重試可使用如下屬性進行配置：
ribbon:
maxautoretries: 1
maxautoretriesnextserver: 2
oktoretryonalloperations: false
配置：
zuul:
# 開啟zuul的重試
retryable: true
ribbon:
maxautoretries: 1
maxautoretriesnextserver: 2
oktoretryonalloperations: false
zuul.retryable=true對zuul全域性開啟了重試，事實上，也可對指定路由開啟/關閉重試：
zuul.routes..retryable=trueclientname:
ribbon:
retryablestatuscodes: 404,502
docker容器雙向聯通與高可用的eureka server
spring cloud中，eureka常見問題總結
《spring cloud與docker微服務架構實戰》配套**
《spring cloud與docker微服務實戰》實體書目錄
Spring Cloud各元件總結歸納
spring cloud技術應用從場景上可以分為兩大類 潤物無聲類和獨挑大樑類。潤物無聲，融合在每個微服務中 依賴其它元件並為其提供服務。獨挑大樑，獨自啟動不需要依賴其它元件。每個元件都不是平白無故的產生的，是為了解決某一特定的問題而存在。特殊成員zipkin，之所以特殊是因為從jar包和包名來看它...
springcloud中各元件彙總
a 服務註冊中心 eureka x zookeeper,consul,nacos b 服務呼叫 ribbon,loadbanlancer,feign x openfeign c 服務熔降級 hystrix x resilience4j,sentinel 阿里 d 服務閘道器 zuul x zuul2...
Spring Cloud 各元件之間的關係
每個元件都不是平白無故的產生的，是為了解決某一特定的問題而存在。eureka和ribbon，是最基礎的元件，乙個註冊服務，乙個消費服務。hystrix為了優化ribbon 防止整個微服務架構因為某個服務節點的問題導致崩潰，是個保險絲的作用。dashboard給hystrix統計和展示用的，而且監控服...