是這樣的，今天碰到了微服務響應超時問題，而且超時時間特別短，2秒就超時，zuul就走熔斷了。
我採用zuul作為閘道器，根據不同的訪問路徑進行微服務的路由，譬如有個服務是user，我訪問user服務的某個介面時，該介面執行時間很慢，2秒多，然後還沒執行完，zuul就執行熔斷了，進入了我配好的zuulfallbackprovider裡。所以來研究一下zuul的超時處理。
前提，zuul和微服務都已經註冊到了eureka中，zuul採用service-id來進行路由，當訪問/user時進入到user服務中。而且，已經為user服務設定好了zuul的熔斷，譬如已經寫好了use***llbackprovider implements zuulfallbackprovider。我特別設定了模擬超時的介面，就是搞幾個介面sleep不同的時間。
public object test1() catch (interruptedexception e)
return "dbtoes";
}public object test2() catch (interruptedexception e)
return "dbtoes";
}public object test3() catch (interruptedexception e)
return "dbtoes";
}關鍵是zuul的配置檔案，通過配置不同的超時策略來完成超時處理。
注意看官方的文件：
這裡就是講zuul的超時的，配置很簡單：
ribbon.readtimeout， ribbon.sockettimeout這兩個就是ribbon超時時間設定，當在yml寫時，應該是沒有提示的，給人的感覺好像是不是這麼配的一樣，其實不用管它，直接配上就生效了。
還有zuul.host.connect-timeout-millis， zuul.host.socket-timeout-millis這兩個配置，這兩個和上面的ribbon都是配超時的。區別在於，如果路由方式是serviceid的方式，那麼ribbon的生效，如果是url的方式，則zuul.host開頭的生效。（此處重要！使用serviceid路由和url路由是不一樣的超時策略）
如果你在zuul配置了熔斷fallback的話，熔斷超時也要配置，不然如果你配置的ribbon超時時間大於熔斷的超時，那麼會先走熔斷，相當於你配的ribbon超時就不生效了。
熔斷超時是這樣的：
hystrix.command.default.execution.isolation.thread.timeoutinmilliseconds: 60000
default代表預設，如果你想為某個特定的service配熔斷超時策略，可以用這種方式：
總結起來就是三種超時配置：
閘道器的超時層級
zuul
zuul:
max:
host:
connections: 500
host:
socket-timeout-millis: 60000
connect-timeout-millis: 60000
ribbon
ribbon:
readtimeout: 10000
connecttimeout: 10000
maxautoretries: 0
maxautoretriesnextserver: 1
eureka:
enabled: true
hystrix
hystrix:
command:
default:
execution:
timeout:
enabled: true
isolation:
thread:
timeoutinmilliseconds: 60000
這裡面ribbon和hystrix是同時生效的，哪個值小哪個生效，另乙個就看不到效果了。
我的例子是這樣配置的
我啟動專案，訪問test1，也就是sleep3秒那個時，會進入熔斷超時，訪問test2，sleep1秒時能正常返回，訪問test3同樣進入熔斷。
可以自行修改超時時間來測試一下。
zuul超時時間配置
server.port 10000 zuul的路由配置 zuul.routes.bid bid zuul.routes.bid consumer consumer 熔斷超時時間配置 hystrix.command.default.execution.isolation.thread.timeouti...
Spring Cloud feign 服務超時處理
spring cloud中，feign和ribbon在整合了hystrix後，可能會出現首次呼叫失敗的問題 造成該問題的原因 hystrix預設的超時時間是1秒，如果超過這個時間尚未響應，將會進入fallback 而首次請求往往會比較慢 因為spring的懶載入機制，要例項化一些類 這個響應時間可能...
支付介面響應超時處理
問題 呼叫第三方支付介面響應時間超過10秒，導致大量線上訂單因為超時失敗，該介面是實時返回結果的，而且不是一直都慢，是偶爾慢。解決方法 呼叫介面時設定超時時間，當介面超過9秒未返回結果，自動將改訂單設定為處理中，然後後由定時任務呼叫查詢介面。這樣就把，乙個實時返回結果的介面，當成乙個非同步的介面來用...