一般情況對於服務依賴的保護主要有3中解決方案：

（1）熔斷模式：這種模式主要是參考電路熔斷，如果一條線路電壓過高，保險絲會熔斷，防止火災。放到我們的系統中，如果某個目標服務呼叫慢或者有大量超時，此時，熔斷該服務的呼叫，對於後續呼叫請求，不在繼續呼叫目標服務，直接返回，快速釋放資源。如果目標服務情況好轉則恢復呼叫。

（2）隔離模式：這種模式就像對系統請求按型別劃分成一個個小島的一樣，當某個小島被火少光了，不會影響到其他的小島。例如可以對不同型別的請求使用執行緒池來資源隔離，每種型別的請求互不影響，如果一種型別的請求執行緒資源耗盡，則對後續的該型別請求直接返回，不再呼叫後續資源。這種模式使用場景非常多，例如將一個服務拆開，對於重要的服務使用單獨伺服器來部署，再或者公司最近推廣的多中心。

（3）限流模式：上述的熔斷模式和隔離模式都屬於出錯後的容錯處理機制，而限流模式則可以稱為預防模式。限流模式主要是提前對各個型別的請求設定最高的QPS閾值，若高於設定的閾值則對該請求直接返回，不再呼叫後續資源。這種模式不能解決服務依賴的問題，只能解決系統整體資源分配問題，因為沒有被限流的請求依然有可能造成雪崩效應。

熔斷設計

        熔斷的設計主要參考了hystrix的做法。其中最重要的是三個模組：熔斷請求判斷演算法、熔斷恢復機制、熔斷報警

      （1）熔斷請求判斷機制演算法：使用無鎖迴圈佇列計數，每個熔斷器預設維護10個bucket，每1秒一個bucket，每個blucket記錄請求的成功、失敗、超時、拒絕的狀態，預設錯誤超過50%且10秒內超過20個請求進行中斷攔截。

      （2）熔斷恢復：對於被熔斷的請求，每隔5s允許部分請求通過，若請求都是健康的（RT<250ms）則對請求健康恢復。

      （3）熔斷報警：對於熔斷的請求打日誌，異常請求超過某些設定則報警

超時機制設計

        超時分兩種，一種是請求的等待超時，一種是請求執行超時。

       等待超時：在任務入佇列時設定任務入佇列時間，並判斷隊頭的任務入佇列時間是否大於超時時間，超過則丟棄任務。

       執行超時：直接可使用執行緒池提供的get方法。

參考

       2、Hystrix使用與分析：http://hot66hot.iteye.com/blog/2155036