在微服務架構中，根據業務來拆分成一個個的服務，服務與服務之間可以相互調用（RPC） 。爲了保證其高可用，單個服務通常會集羣部署。由於網絡原因或者自身的原因，服務並不能保證100%可用，如果單個服務出現問題，調用這個服務就會出現線程阻塞，此時若有大量的請求涌入，Servlet容器的線程資源會被消耗完畢，導致服務癱瘓。服務與服務之間的依賴性，故障會傳播，會對整個微服務系統造成災難性的嚴重後果，這就是服務故障的“雪崩”效應。
如下圖所示：A作爲服務提供者，B爲A的服務消費者，C和D是B的服務消費者。A不可用引起了B的不可用，並將不可用像滾雪球一樣放大到C和D時，雪崩效應就形成了。
Hystrix語義爲“豪豬"，具有自我保護的能力。Hystrix的出現即爲解決雪崩效應。
Hystrix的設計原則是什麼？
- 資源隔離（線程池隔離和信號量隔離）機制：限制調用分佈式服務的資源使用，某一個調用的服務出現問題不會影響其它服務調用。
- 限流機制：限流機制主要是提前對各個類型的請求設置最高的QPS閾值，若高於設置的閾值則對該請求直接返回，不再調用後續資源。
- 熔斷機制：當失敗率達到閥值自動觸發降級（如因網絡故障、超時造成的失敗率真高），熔斷器觸發的快速失敗會進行快速恢復。
- 降級機制：超時降級、資源不足時（線程或信號量）降級 、運行異常降級等，降級後可以配合降級接口返回託底數據。
- 緩存支持：提供了請求緩存、請求合併實現
- 通過近實時的統計/監控/報警功能，來提高故障發現的速度
- 通過近實時的屬性和配置熱修改功能，來提高故障處理和恢復的速度
Hystrix是如何實現它的目標的？
（1）通過HystrixCommand或者HystrixObservableCommand來封裝對外部依賴的訪問請求，這個訪問請求一般會運行在獨立的線程中，資源隔離
（2）對於超出我們設定閾值的服務調用，直接進行超時，不允許其耗費過長時間阻塞住。這個超時時間默認是99.5%的訪問時間，但是一般我們可以自己設置一下
（3）爲每一個依賴服務維護一個獨立的線程池，或者是semaphore，當線程池已滿時，直接拒絕對這個服務的調用
（4）對依賴服務的調用的成功次數，失敗次數，拒絕次數，超時次數，進行統計
（5）如果對一個依賴服務的調用失敗次數超過了一定的閾值，自動進行熔斷，在一定時間內對該服務的調用直接降級，一段時間後再自動嘗試恢復
（6）當一個服務調用出現失敗，被拒絕，超時，短路等異常情況時，自動調用fallback降級機制
（7）對屬性和配置的修改提供近實時的支持
