為什么需要 Hystrix?
在微服務架構中，我們將業務拆分成一個個的服務，服務與服務之間可以相互調用（RPC）。為了保證其高可用，單個服務又必須集群部署。由於網絡原因或者自身的原因，服務並不能保證服務的100%可用，如果單個服務出現問題，調用這個服務就會出現網絡延遲，此時若有大量的網絡涌入，會形成任務累計，導致服務癱瘓，甚至導致服務“雪崩”。為了解決這個問題，就出現斷路器模型。
Hystrix 是一個幫助解決分布式系統交互時超時處理和容錯的類庫, 它同樣擁有保護系統的能力.什么是服務雪崩
分布式系統中經常會出現某個基礎服務不可用造成整個系統不可用的情況, 這種現象被稱為服務雪崩效應. 為了應對服務雪崩, 一種常見的做法是手動服務降級. 而Hystrix的出現,給我們提供了另一種選擇.
服務雪崩應對策略
針對造成服務雪崩的不同原因, 可以使用不同的應對策略:
1.流量控制
2.改進緩存模式
3.服務自動擴容
4.服務調用者降級服務
流量控制 的具體措施包括:
•網關限流
•用戶交互限流
•關閉重試
服務雪崩解決辦法
1.服務雪崩的原因
（1）某幾個機器故障：例如機器的硬驅動引起的錯誤，或者一些特定的機器上出現一些的bug（如，內存中斷或者死鎖）。
（2）服務器負載發生變化：某些時候服務會因為用戶行為造成請求無法及時處理從而導致雪崩，例如阿里的雙十一活動，若沒有提前增加機器預估流量則會造服務器壓力會驟然增大二掛掉。
（3）人為因素：比如代碼中的路徑在某個時候出現bug
2.解決或緩解服務雪崩的方案
一般情況對於服務依賴的保護主要有3中解決方案：
（1）熔斷模式：這種模式主要是參考電路熔斷，如果一條線路電壓過高，保險絲會熔斷，防止火災。放到我們的系統中，如果某個目標服務調用慢或者有大量超時，此時，熔斷該服務的調用，對於后續調用請求，不在繼續調用目標服務，直接返回，快速釋放資源。如果目標服務情況好轉則恢復調用。
（2）隔離模式：這種模式就像對系統請求按類型划分成一個個小島的一樣，當某個小島被火少光了，不會影響到其他的小島。例如可以對不同類型的請求使用線程池來資源隔離，每種類型的請求互不影響，如果一種類型的請求線程資源耗盡，則對后續的該類型請求直接返回，不再調用后續資源。這種模式使用場景非常多，例如將一個服務拆開，對於重要的服務使用單獨服務器來部署，再或者公司最近推廣的多中心。
（3）限流模式：上述的熔斷模式和隔離模式都屬於出錯后的容錯處理機制，而限流模式則可以稱為預防模式。限流模式主要是提前對各個類型的請求設置最高的QPS閾值，若高於設置的閾值則對該請求直接返回，不再調用后續資源。這種模式不能解決服務依賴的問題，只能解決系統整體資源分配問題，因為沒有被限流的請求依然有可能造成雪崩效應。
3.熔斷設計
在熔斷的設計主要參考了hystrix的做法。其中最重要的是三個模塊：熔斷請求判斷算法、熔斷恢復機制、熔斷報警
（1）熔斷請求判斷機制算法：使用無鎖循環隊列計數，每個熔斷器默認維護10個bucket，每1秒一個bucket，每個blucket記錄請求的成功、失敗、超時、拒絕的狀態，默認錯誤超過50%且10秒內超過20個請求進行中斷攔截。
（2）熔斷恢復：對於被熔斷的請求，每隔5s允許部分請求通過，若請求都是健康的（RT<250ms）則對請求健康恢復。
（3）熔斷報警：對於熔斷的請求打日志，異常請求超過某些設定則報警
4.隔離設計
隔離的方式一般使用兩種
（1）線程池隔離模式：使用一個線程池來存儲當前的請求，線程池對請求作處理，設置任務返回處理超時時間，堆積的請求堆積入線程池隊列。這種方式需要為每個依賴的服務申請線程池，有一定的資源消耗，好處是可以應對突發流量（流量洪峰來臨時，處理不完可將數據存儲到線程池隊里慢慢處理）
（2）信號量隔離模式：使用一個原子計數器（或信號量）來記錄當前有多少個線程在運行，請求來先判斷計數器的數值，若超過設置的最大線程個數則丟棄改類型的新請求，若不超過則執行計數操作請求來計數器+1，請求返回計數器-1。這種方式是嚴格的控制線程且立即返回模式，無法應對突發流量（流量洪峰來臨時，處理的線程超過數量，其他的請求會直接返回，不繼續去請求依賴的服務）
5 超時機制設計
超時分兩種，一種是請求的等待超時，一種是請求運行超時。
等待超時：在任務入隊列時設置任務入隊列時間，並判斷隊頭的任務入隊列時間是否大於超時時間，超過則丟棄任務。
運行超時：直接可使用線程池提供的get方法
什么是熔斷機制
熔斷機制，就是下游服務出現問題后，為保證整個系統正常運行下去，而提供一種降級服務的機制，通過返回緩存數據或者既定數據，避免出現系統整體雪崩效應。在springcloud中，該功能可通過配置的方式加入到項目中。
Hystrix作用
1.斷路器機制
斷路器很好理解, 當Hystrix Command請求后端服務失敗數量超過一定比例(默認50%), 斷路器會切換到開路狀態(Open). 這時所有請求會直接失敗而不會發送到后端服務. 斷路器保持在開路狀態一段時間后(默認5秒), 自動切換到半開路狀態(HALF-OPEN). 這時會判斷下一次請求的返回情況, 如果請求成功, 斷路器切回閉路狀態(CLOSED), 否則重新切換到開路狀態(OPEN). Hystrix的斷路器就像我們家庭電路中的保險絲, 一旦后端服務不可用, 斷路器會直接切斷請求鏈, 避免發送大量無效請求影響系統吞吐量, 並且斷路器有自我檢測並恢復的能力.
2.Fallback
Fallback相當於是降級操作. 對於查詢操作, 我們可以實現一個fallback方法, 當請求后端服務出現異常的時候, 可以使用fallback方法返回的值. fallback方法的返回值一般是設置的默認值或者來自緩存.
3.資源隔離
在Hystrix中, 主要通過線程池來實現資源隔離. 通常在使用的時候我們會根據調用的遠程服務划分出多個線程池. 例如調用產品服務的Command放入A線程池, 調用賬戶服務的Command放入B線程池. 這樣做的主要優點是運行環境被隔離開了. 這樣就算調用服務的代碼存在bug或者由於其他原因導致自己所在線程池被耗盡時, 不會對系統的其他服務造成影響. 但是帶來的代價就是維護多個線程池會對系統帶來額外的性能開銷. 如果是對性能有嚴格要求而且確信自己調用服務的客戶端代碼不會出問題的話, 可以使用Hystrix的信號模式(Semaphores)來隔離資源。