最近自己在寫一套SpringCloud的全家桶項目，發現一個問題，很是讓人頭疼，就是超時的設置問題，先來介紹下我的實踐場景：
網關： SpringCloud Gateway
請求路徑： 前端->網關->服務A->服務B
問題：
在服務A進行斷點debugger測試，結果直接接口直接被網關降級返回：服務A暫不可用，但是實際情況就是，我只是在服務A處打了斷點進行調試而已，所有服務其實都是正常運行的，只是網關急不可耐的對服務A的調用提前判了死刑，也就是服務降級，嘗試多次後，直接會觸發熔斷。
我的網關，是啓用了Hystrix的限流以及服務降級還有熔斷功能，這個時候，我就想到超時時間的設置，但是又想到，網關還使用了Ribbon的負載均衡，這個其實也是有超時時長的，然後，在服務A和服務B中的話，還存在Feign這種客戶端請求工具，也是有超時時長的限制，那麼這個時候，就需要去好好梳理，各種工具的超時設置的關係了，不然，這種問題調測起來，是非常費力氣的。
Ribbon：服務負載均衡工具
Hystrix：服務調用觸發降級、熔斷工具
Feign：客戶端請求工具【Ribbon+Hystrix】
關係：Hystrix和Ribbon一起讀秒，Feign是他們兩者時間總和；
一般情況下 都是 ribbon 的超時時間（<）hystrix的超時時間（否則會在接口調用還未完成的時候直接進入回調方法），但是我自己是不再去單獨設置Ribbon的超時、重試的，因爲Ribbon的作用就是幫助我們尋找服務，而服務這一塊在註冊中心管理，如果找不到服務，大概率是服務沒有註冊或者有問題，我更喜歡讓他快速失敗，對於它的超時和重試設置，不是很有必要，反而會加大問題排查難度。
再來說一下Feign，因爲ribbon的重試機制和Feign的重試機制有衝突，所以源碼中默認關閉Feign的重試機制，對於我自己而已，也不希望它開啓重試，快速失敗反而直觀。
設置Hystrix的超時，則是因爲，業務處理是需要一定時間的，而且我不希望在我還沒有處理完業務的時候，就被迫返回、觸發降級甚至熔斷，這是不合理的。
設置Hystrix超時、重試、熔斷的配置流程
1.啓用註解開啓對Hystrix的支持
2.yaml或者接口定義中設置超時
如果是網關的話
# hystrix相關配置
hystrix:
command:
default:
execution: ## 超時配置
isolation:
thread:
timeoutInMilliseconds: 20000 #設置請求超時時間，默認1秒，超過指定的時間後，觸發降級
circuitBreaker: ##熔斷配置
requestVolumeThreshold: 3 #達到指定的次數後熔斷服務 (默認20次)
sleepWindowInMilliseconds: 5000 #熔斷後，多長時間進行恢復(默認 5000)
如果是服務A、B、C的話還需要開啓Feign的Hystrix支持
# 開啓Feign熔斷器配置
feign:
hystrix:
enabled: true