1.雪崩效應
在微服務架構中，服務眾多，通常會涉及多個服務層級的調用，一旦基礎服務發生故障，很可能會導致級聯故障，進而造成整個系統不可用，這種現象被稱為服務雪崩效應。服務雪崩效應是一種因“服務提供者”的不可用導致“服務消費着”的不可用並將這種不可用逐漸放大的過程。
比如在一個系統中，A是服務提供者：B是A的服務消費着，C和D又是B的服務消費者。如果此時A發生故障，則會引起B的不可用，而B的不可用又將導致C和D的不可用，當這種不可用像滾雪球一樣逐漸放大的時候，雪崩效應就形成了。
2.熔斷器(CircuitBreaker)
熔斷器的原理很簡單，如同電力過載保護器。它可以實現快速失敗，如果它在一段時間內偵測到許多類似的錯誤，就會強迫其以后的多個調用快速失敗，不再訪問遠程服務器，從而防止應用程序不斷地嘗試執行可能會失敗的操作，使得應用程序繼續執行而不用等待修正錯誤，或者浪費CPU時間去等到長時間的超時產生。熔斷器也可以使應用程序能夠診斷錯誤是否已經修正，如果已經修正，應用程序會再次嘗試調用操作。熔斷器模式就像是那些容易導致錯誤操作的一種代理。這種代理能夠記錄最近調用發生錯誤的次數，然后決定使用允許操作維續,或者立即返回錯誤。熔斷器是保護服務高可用的最后一道防線.
3.Hystrix特性
3.1 斷路器機制
斷路器很好理解， 當Hystrix Command請求后端服務失敗數量超過一定比例(默認為50%) ， 斷路器會切換到開路狀態(Open) .這時所有請求會直接失敗而不會發送到后端服務。斷路器保持在開路狀態一段時間后(默認為5秒) ， 自動切換到半開路狀態(HALF-OPEN) .這時會判斷下一次請求的返回情況， 如果請求成功， 斷路器切回閉路狀態(CLOSED) ， 否則重新切換到開路狀態(OPEN) .Hystrix的斷路器就像我們家庭電路中的保險絲， 一旦后端服務不可用，斷路器就會直接切斷請求鏈，避免發送大量無效請求，從而影響系統吞吐量，並且斷路器有自我檢測並恢復的能力。
3.2 fallback
fallback相當於降級操作.對於查詢操作， 我們可以實現一個fallback方法， 當請求后端服務出現異常的時候， 可以使用fallback方法返回的值。fallback方法的返回值一般是設置的默認值或者來自緩存。
3.3 資源隔離
在Hystrix中， 主要通過線程池來實現資源隔離， 通常在使用的時候我們會根據調用的遠程服務划分出多個線程池。例如， 調用產品服務的Command放入A線程池， 調用賬戶服務的Command放入B線程池， 這樣做的主要優點是運行環境被隔離開了。這樣就算調用服務的代碼存在bug或者由於其他原因導致自己所在線程池被耗盡， 也不會對系統的其他服務造成影響，但是帶來的代價就是維護多個線程池會對系統帶來額外的性能開銷.如果是對性能有嚴格要求而且確信自己調用服務的客戶端代碼不會出問題， 就可以使用Hystrix的信號模式(Semaphores) 來隔離資源。
5.Hystrix Dashboard
Hystrix-dashboard是一款針對Hystrix進行實時監控的工具， 通過Hystrix Dashboard我們可以直觀地看到各Hystrix Command的請求響應時間、請求成功率等數據。
6.Spring Cloud Turbine
上面我們集成了Hystrix Dashboard， 使用Hystrix Dashboard可以看到單個應用內的服務信息。顯然這是不夠的，我們還需要一個工具能讓我們匯總系統內多個服務的數據並顯示到Hystrix Dashboard上， 這個工具就是Turbine。