今天早上過來突然被告知我們提供給外系統的接口服務出問題了，失敗率高達20%
很奇怪，昨天週末，今天也沒做什麼處理，怎麼突然變成這樣了
1.接口測試
第一反應是接口是不是出問題了，然後我立馬打開jmeter調20次接口
問題是全部成了？？？
這就很奇怪了，讓對端提供截圖證據，是不是別人搞我？？？
2.定位問題服務
根據對端反饋的視頻，可以看到反饋的報錯是zuulexception
那麼就可以確定，問題拋出的地方在zuul
然後打開日誌一看，這一看直接爆炸。。。。
日誌瘋狂報錯，timed-out and no fallback available.
因爲當時部署的4個節點，這個機器上的2個節點瘋狂報這個錯，但是隻有20%的的失敗率，這個就很奇怪了，
於是我打開第二臺機器的日誌。。。。
嗶了狗。。。。。第二天機器居然毫無波動？？？
啥意思？就瞧不起前面這臺機器咯，到這裏我就懵逼了，百思不得起解，然後我第一反應就是看源碼。。。
3.源碼定位問題
那麼要通過源碼定位問題，就要準備類似的環境了，生產肯定是不能亂動的
因爲之前說過，有臺機器是好的，我就先把第一臺機器的服務關閉，先把第二臺機器的2個節點頂一下了
那麼現在生產先拋到一邊，我們準備一下環境
1.eureka，2.zuul 3.demo服務
先起eureka
吧對應的服務註冊上去
準備接口請求，然後我準備在原來的服務上打個斷點，卡一會再過去看看效果
然後我發現卡半天，毫無波動。。。。
幾分鐘後。。。
終於報錯了，但是報的錯確不是之前的那個錯了
爲了模擬那種情況
調試zuul網關參數
設置熔斷超時時間：150毫秒，夠少了吧
測試一波
終於問題得到復現，很顯然是在熔斷超時的時間內沒有得到返回導致的
但是我們對接口響應時間有要求，3s之內沒有返回就應該算超時
那麼這個值默認是多少呢？？
這也太短了，1s不返回就當超時，我們這個接口涉及到的子接口就有6個，更不用說自己還有部分邏輯了，又不能直接把原子接口直接給外系統用
那這邊只能改參數了
調整之後，調整之後，我們再試試效果
效果確實得到改觀
測試請求時間：16點26分26s
我們報錯時間：16:26:29.
跟我們設置的參數吻合，很好
那是不是吧這個調大就把這個問題解決了呢？？？
4、壓測
我們再試試再大量請求的情況下是否還是會出現這種情況，或者是等待
爲了更好的測試，我們設置進程池最大數量爲2個
單請求沒問題
我們接下來直接模擬8個線程同時請求接口,並在服務中添加線程等待的方法模擬業務繁忙
接下來我們測試一下
隨着時間的推移，我們發現失敗的數量越來越多，前面的未執行完，後面的繼續堆積
總結：
說白了就是調整熔斷返回超時的時間，這個default可以手動設置爲對應的服務id
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds
最後注意一點：
這個值要比：ribbon.ReadTimeout 與 ribbon.ConnectTimeout兩個參數的值之和要大