本篇主要講解一下Spring Cloud 中 Zuul 組件的Ribbon和Hystrix的配置尼摹。
- Ribbon：負載均衡挖息，是針對服務的多實例負載均衡的配置
- Hystrix：熔斷器，當zuul網關調用具體的業(yè)務的時候可能受到網絡，代碼執(zhí)行時間等影響長時間無響應，這個時候就需要配置hystrix，避免線程長時間占用內存袁串，造成內存泄露，服務掛掉
Ribbon 配置
通過查閱官方文檔呼巷，我找到了配置方案囱修。路由方式的不同配置的方式也不一樣。
- 當使用了Eureka注冊中心王悍，zuul.routes配置走service的時候破镰，通過
ribbon.ReadTimeout和ribbon.SocketTimeout配置 - 當zuul.routes配置走url的時候,通過
zuul.host.connect-timeout-millis和zuul.host.socket-timeout-millis配置
如果想要對指定服務進行特殊配置，配置方式如下：
<serviceName>.ribbon.ReadTimeout
<serviceName> 為 服務名
Hystrix配置
如果zuul配置了熔斷fallback的話，熔斷超時也要配置鲜漩。配置屬性如下：
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=60000
default代表默認源譬，如果你想為某個特定的service配熔斷超時策略，配置方式如下：
hystrix.command.<serviceName>.execution.isolation.thread.timeoutInMilliseconds=60000
<serviceName> 為 服務名
示例
通過上面的說明孕似，Ribbon和Hystrix的配置如下（配置沒有提示但依然有效）：
#是否開啟路由重試
zuul.retryable=true
#對當前實例的重試次數
ribbon.MaxAutoRetries=1
#切換實例的重試次數
ribbon.MaxAutoRetriesNextServer=1
#請求處理的超時時間
ribbon.ReadTimeout=5000
#請求連接的超時時間
ribbon.ConnectTimeout=2000
#對所有操作請求都進行重試
ribbon.OkToRetryOnAllOperations=true
# hystrix 超時時間最好大于Ribbon的超時時間
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=16000
當啟動Eureka,Zuul踩娘，ServiceA服務進行測試的時候，在Zuul服務的控制臺打印了下面的警告：
2018-12-03 16:22:30.306 WARN [apigateway,7447152c2c5cc400,7447152c2c5cc400,true] 20024 --- [nio-8102-exec-3] o.s.c.n.z.f.r.s.AbstractRibbonCommand : The Hystrix timeout of 16000ms for the command serviceA is set lower than the combination of the Ribbon read and connect timeout, 28000ms.
大概意思就是 Hystrix 的 超時時間小于 Ribbon的超時時間喉祭。為什么Ribbon的超時時間是28000ms呢养渴？這個警告是AbstractRibbonCommand.java報告的，于是我開始查閱它的源碼泛烙。
protected static int getHystrixTimeout(IClientConfig config, String commandKey) {
int ribbonTimeout = getRibbonTimeout(config, commandKey);
DynamicPropertyFactory dynamicPropertyFactory = DynamicPropertyFactory.getInstance();
// 獲取默認的hytrix超時時間
int defaultHystrixTimeout = dynamicPropertyFactory.getIntProperty("hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds", 0).get();
// 獲取具體服務的hytrix超時時間理卑，這里應該是hystrix.command.serviceA.execution.isolation.thread.timeoutInMilliseconds
int commandHystrixTimeout = dynamicPropertyFactory.getIntProperty("hystrix.command." + commandKey + ".execution.isolation.thread.timeoutInMilliseconds", 0).get();
int hystrixTimeout;
// hystrixTimeout的優(yōu)先級是 具體服務的hytrix超時時間 > 默認的hytrix超時時間 > ribbon超時時間
if (commandHystrixTimeout > 0) {
hystrixTimeout = commandHystrixTimeout;
} else if (defaultHystrixTimeout > 0) {
hystrixTimeout = defaultHystrixTimeout;
} else {
hystrixTimeout = ribbonTimeout;
}
// 如果默認的或者具體服務的hytrix超時時間小于ribbon超時時間就會警告
if (hystrixTimeout < ribbonTimeout) {
LOGGER.warn("The Hystrix timeout of " + hystrixTimeout + "ms for the command " + commandKey + " is set lower than the combination of the Ribbon read and connect timeout, " + ribbonTimeout + "ms.");
}
return hystrixTimeout;
}
仔細查看發(fā)現(xiàn)ribbonTimeout是通過getRibbonTimeout()方法獲取的
protected static int getRibbonTimeout(IClientConfig config, String commandKey) {
int ribbonTimeout;
// 默認為 2s
if (config == null) {
ribbonTimeout = 2000;
} else {
// 這里獲取了四個參數，ReadTimeout蔽氨，ConnectTimeout藐唠，MaxAutoRetries， MaxAutoRetriesNextServer,優(yōu)先級：具體服務 > 默認
// 1. 請求處理的超時時間,默認 1s
int ribbonReadTimeout = getTimeout(config, commandKey, "ReadTimeout", Keys.ReadTimeout, 1000);
// 2. 請求連接的超時時間,默認 1s
int ribbonConnectTimeout = getTimeout(config, commandKey, "ConnectTimeout", Keys.ConnectTimeout, 1000);
// 3. 對當前實例的重試次數.默認 0
int maxAutoRetries = getTimeout(config, commandKey, "MaxAutoRetries", Keys.MaxAutoRetries, 0);
// 4. 切換實例的重試次數,默認 1
int maxAutoRetriesNextServer = getTimeout(config, commandKey, "MaxAutoRetriesNextServer", Keys.MaxAutoRetriesNextServer, 1);
// ribbonTimeout的計算方法
ribbonTimeout = (ribbonReadTimeout + ribbonConnectTimeout) * (maxAutoRetries + 1) * (maxAutoRetriesNextServer + 1);
}
return ribbonTimeout;
}
原來 ribbonTimeout的計算方法為:
ribbonTimeout = (ribbonReadTimeout + ribbonConnectTimeout) * (maxAutoRetries + 1) * (maxAutoRetriesNextServer + 1);
按照示例中的配置鹉究，我們進行計算：
ribbonTimeout = (5000 + 2000) * (1 + 1) * (1 + 1) = 28000
從邏輯上來說宇立，hystrixTimeout要大于ribbonTimeout，所以更改配置如下：
#是否開啟路由重試
zuul.retryable=true
#對當前實例的重試次數
ribbon.MaxAutoRetries=1
#切換實例的重試次數
ribbon.MaxAutoRetriesNextServer=1
#請求處理的超時時間
ribbon.ReadTimeout=5000
#請求連接的超時時間
ribbon.ConnectTimeout=2000
#對所有操作請求都進行重試
ribbon.OkToRetryOnAllOperations=true
# hystrix 超時時間最好大于Ribbon的超時時間
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=30000
如果hystrixTimeout小于ribbonTimeout自赔，可能在Ribbon切換實例進行重試的過程中就會觸發(fā)熔斷泄伪。
