在使用spring cloud框架開發微服務時，會遇到zuul，ribbon，hystrix的配置，剛開始接觸到時候會有些懵逼，下面我講講這三者的作用和區別。

zuul：是gateway的核心，叫做路由。在一個專案中，有很多微服務，它們之間的相互呼叫就是通過zuul的設定才能實現的。

ribbon：負載均衡，spring cloud是一個分散式框架，所以ribbon是針對業務模組的多例項負載均衡的配置。

hystrix：熔斷器，當gateway呼叫具體的業務模組的時候，難免會受到網路，查詢效率等因素的影響，導致響應超時，這時候就需要配置hystrix了，以免執行緒一直佔用記憶體，導致記憶體溢位等問題，使得程式down掉。

關於這三個超時策略額問題,zuul和ribbon都有connect-timeout和socket-timeout的配置，當zuul.routes的配置走url的時候，

是zuul.host.connect-timeout-millis,zuul.host.socket-timeout-millis這兩個配生效，當zuul.routes的配置走serviceid的時候，是

ribbon.Readtimeout,ribbon.Sockettimeout生效。

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000這個配置是hystrix的熔斷時間，當請求時間超過這個時間，會自動熔斷，釋放記憶體。

ribbon的重試機制：當一個請求過來被分發到其中的一個例項處理，當這個例項出現問題無法響應或者響應超時的時候，繼續請求當前例項，或者請求其他例項，下面是ribbon重試的配置。

# hystrix的超時時間必須大於ribbon的超時時間
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000
# 開啟重試
zuul.retryable=true
spring.cloud.loadbalancer.retry.enabled=true
# 請求連線的超時時間
ribbon.connectTimeout=2000
# 請求處理的超時時間
ribbon.readTimeout=5000
# 對當前例項的重試次數
ribbon.maxAutoRetries=1
# 切換例項的重試次數
ribbon.maxAutoRetriesNextServer=3
# 對所有操作請求都進行重試
ribbon.okToRetryOnAllOperations=true
 

關於hystrix的超時時間計算的問題說明，以上面的配置時間為例：

ribbon.connectTimeot是請求連線的時間，基本上都是很短的，所以這個請求的時間可以忽略不記，所耗費的時間基本上都是在請求的處理時間上。所以計算的公式是（1+maxAutoRetries+maxAutoRetriesNestServer)*5000,該計算公式會得出一個值，hystrix的超時時間最好要大於這個值，如果小於這個值的話，那麼配置重試就沒有意義了，因為當系統還在進行重試的時候，就把這一次的請求熔斷了。

最後，要使配置生效，專案需要匯入相應的依賴：

<dependency>
    <groupId>org.springframework.retry</groupId>
    <artifactId>spring-retry</artifactId>
    <version>1.2.1.RELEASE</version>
</dependency>