hystrix 之服務雪崩

服務雪崩：在微服務調用的過程中由于各服務之間的強依賴關系，如果某些服務發成故障，可能會導緻所有服務的所有資源不可用的現象

主要原因：

　　服務提供者不可用（硬體故障，程式 BUG，緩存擊穿，使用者大量請求等）

　　重試加大流量（使用者重試，代碼邏輯重試）

　　服務消費者不可用（同步等待造成的資源耗盡

即一個服務不可用，導緻一系列服務的不可用。

解決方案：

　　請求緩存：支援将一個請求與傳回結果做緩存處理；

　　請求合并：将相同的請求進行合并然後調用批處理接口；

　　服務隔離：限制調用分布式服務的資源，某一個調用的服務出現問題不會影響其他服務調用；

　　服務熔斷：犧牲局部服務，保全整體系統穩定性的措施；

　　服務降級：服務熔斷以後，用戶端調用自己本地方法傳回預設值。

請求緩存：

　　Hystrix 為了降低通路服務的頻率，支援将一個請求與傳回結果做緩存處理，但Hystrix 自帶緩存有兩個缺點：

　　　　本地緩存，叢集情況下緩存無法同步。

　　　　不支援第三方緩存容器，如：Redis，MemCache。

　　是以：可使用 Spring 的緩存內建方案

請求合并：

　　在高并發情況下，減少微服務之間通信次數，将各請求合并處理

　　優點：減少了微服務之間的通信

　　缺點：增加了單個請求的延遲，請求量不高，請求耗時延遲低不适用

服務隔離：

　　線程池隔離：通常情況下一個微服務的所有接口都是在一個線程池中運作，如果由于某個接口通路壓力過大，導緻其他接口無法通路

　　　　對通路壓力過大的接口單獨設立線程，而不影響其他線程

　　　　優點：

　　　　　　使用線程池隔離可以安全隔離依賴的服務，減少所依賴服務發生故障時的影響面。

　　　　　　獨立的線程池提高了并發性。

　　　　　　當失敗的服務再次變得可用時，線程池将清理并立即恢複，而不需要一個長時間的恢複。

　　　　确定：

　　　　　　請求線上程池中執行，肯定會帶來任務排程、排隊和上下文切換帶來的 CPU 開銷。

　　　　　　因為涉及到跨線程，那麼就存在 ThreadLocal 資料的傳遞問題，比如在主線程初始化的 ThreadLocal 變量

　　信号量隔離：

　　　　每次調用線程，目前請求通過計數信号量進行限制，當信号量大于了最大請求數 maxConcurrentRequests 時，進行限制，調用 fallback 接　　　　　　　　口快速傳回。信号量的調用是同步的，也就是說，每次調用都得阻塞調用方的線 程，直到結果傳回。這樣就導緻了無法對通路做逾時（隻能依靠調　　用協定逾時，無法主動釋放）

服務熔斷：

　　啟動條件：

　　　　機關時間内請求超标

　　　　機關時間内請求失敗太多

　　重試：熔斷啟動狀态下，機關時間内重試，成功則關閉熔斷，失敗則fallback

服務降級：當服務不可用時，預設的處理方法

　　觸發條件：

　　　　方法抛出非 HystrixBadRequestException 異常

　　　　方法調用逾時

　　　　熔斷器開啟攔截調用

　　　　線程池/隊列/信号量跑滿