一.走進Hystrix

hystrix介紹

　　Hystrix 供分佈式系統使用，提供延遲和容錯功能，隔離遠程系統、訪問和第三方程序庫的訪問點，防止級聯失敗，保證複雜的分佈系統在面臨不可避免的失敗時，仍能有其彈性。

hystrix歷史

 　　hystrix，高可用性保障的一個框架，是Netflix公司API團隊從2011年開始作一些提高系統可用性和穩定性的工做，Hystrix就是從那時候開始發展出來的。時至今日，Netflix中天天都有數十億次的服務間調用，經過Hystrix框架在進行，而Hystrix也幫助Netflix網站提高了總體的可用性和穩定性。

 

hystrix的適用場景

適用場景：
　　對於一個分佈式系統，不一樣的的服務間存在着不少依賴，好比服務A依賴服務B、C、D，服務A拿到B、C、D返回的數據，進行下一個環節的操做，這時候若是服務B出現故障，這時候使用hystrix能夠確保服務A中止調用服務B，只調用服務C、服務D，使系統能正常的響應，不會由於服務B故障而致使整個系統崩潰。

　　例如：

　　　　短信發送微服務，由於對接了多個渠道，當某個渠道不可用的狀況下，hystrix熔斷掉，而後採起另外的渠道進行下發。在發送量級比較大的狀況，能夠減小短信發送進行重試的時間。

 

不適用場景：

　　若是你的服務所依賴的服務均是核心業務，不能熔斷，這個時候就不能使用hystrix了。

　　例如：

　　　　計費業務，id生成器業務做爲核心業務，是整個短信業務的核心，若是引入熔斷機制會致使業務流程失敗，至關於整個短信業務不可用，因此這類核心無降級的服務是不該該啓動hystrix的。

 

hystrix vs dubbo

　　也許大家的腦海中會有疑問，就是既然咱們的分佈式系統都使用了分佈式服務治理框架了，例如dubbo，能夠設置超時時間來打斷未響應的調用；爲何還須要hystrix，這不是畫蛇添足麼，其實否則，由於dubbo設置的超時時間並不能減輕服務提供方的壓力，當你的服務提供方出現故障時，大量的請求依然會打過來，這時候你的服務提供者不段的進行超時處理，拋timeout異常，也就是提供方依然在不斷的接收大量的請求，若是忽然來了個流量洪峯，你的web容器的線程就會瞬間被吃光，這時候會致使整個系統卡死，沒法再爲用戶做出任何響應了。

　　而hystrix能夠有豐富的配置，其原理是：在一個窗口時間內針對錯誤進行計數，當達到閾值則熔斷提供方，不在請求該熔斷的提供方，而後快速返回。hystrix可以解決服務提供者不可用的場景。他採用了資源隔離模式，經過線程隔離和信號量隔離保護主線程池；使用熔斷器避免無節操的重試，並提供斷路自動復位功能。下面咱們就來看一看如何使用hystrix。

 

hystrix開發原則

（1）阻止任何一個依賴服務耗盡全部的資源，好比tomcat中的全部線程資源

（2）避免請求排隊和積壓，採用限流和fail fast來控制故障

（3）提供fallback降級機制來應對故障

（4）使用資源隔離技術，好比bulkhead（艙壁隔離技術），swimlane（泳道技術），circuit breaker（短路技術），來限制任何一個依賴服務故障致使的影響

（5）經過近實時的統計/監控/報警功能，來提升故障發現的速度

（6）經過近實時的屬性和配置熱修改功能，來提升故障處理和恢復的速度

（7）保護依賴服務調用的全部故障狀況，而不只僅只是網絡故障狀況 

 

hystrix如何實現目標

（1）經過HystrixCommand或者HystrixObservableCommand來封裝對外部依賴的訪問請求，這個訪問請求通常會運行在獨立的線程中，資源隔離

（2）對於超出咱們設定閾值的服務調用，直接進行超時，不容許其耗費過長時間阻塞住。這個超時時間默認是99.5%的訪問時間，可是通常咱們能夠本身設置一下

（3）爲每個依賴服務維護一個獨立的線程池，或者是semaphore，當線程池已滿時，直接拒絕對這個服務的調用

（4）對依賴服務的調用的成功次數，失敗次數，拒絕次數，超時次數，進行統計

（5）若是對一個依賴服務的調用失敗次數超過了必定的閾值，自動進行熔斷，在必定時間內對該服務的調用直接降級，一段時間後再自動嘗試恢復

（6）當一個服務調用出現失敗，被拒絕，超時，短路等異常狀況時，自動調用fallback降級機制

（7）對屬性和配置的修改提供近實時的支持

 

摘抄

　　App Container能夠是咱們的應用容器，好比jetty，tomcat，也能夠是一個用來處理外部請求的線程池（好比netty的worker線程池）。一個用戶請求有可能依賴其餘多個外部服務，好比上圖中的A,H,I,P，在不可靠的網絡環境下，任何的RPC均可能會面臨三種狀況：成功、失敗、超時。若是一次用戶請求所依賴外部服務(A,H,I,P)有任何一個不可用，就有可能致使整個用戶請求被阻塞。考慮到應用容器的線程數目基本都是固定的（好比tomcat的線程池默認200），當在高併發的狀況下，某一外部依賴的服務超時阻塞，就有可能使得整個主線程池被佔滿，這是長請求擁塞反模式（https://tech.meituan.com/performance_tuning_pattern.html）。

更進一步，線程池被佔滿就會致使整個服務不可用，而依賴該服務的其餘服務，就又可能會重複產生上述問題。所以整個系統就像雪崩同樣逐漸的擴散、坍塌、崩潰了！