爲什麼需要Hystrix
在大中型分佈式系統中，通常系統很多依賴，如下圖:
在高併發訪問下，這些依賴的穩定性與否對系統的影響非常大，但是依賴有很多不可控問題：如網絡連接緩慢，資源繁忙，暫時不可用，服務脫機等，如下圖：
當依賴阻塞時，大多數服務器的線程池就出現阻塞，影響整個線上服務的穩定性，如下圖：
在複雜的分佈式架構的應用程序有很多的依賴，都會不可避免地在某些時候失敗。高併發的依賴失敗時如果沒有隔離措施，當前應用服務就有被拖垮的風險。
Hystrix如何解決依賴隔離
Hystrix使用命令模式HystrixCommand(Command)包裝依賴調用邏輯，每個命令在單獨線程中/信號授權下執行。
可配置依賴調用超時時間,超時時間一般設爲比99.5%平均時間略高即可。當調用超時時，直接返回或執行fallback邏輯。
爲每個依賴提供一個小的線程池或信號，如果線程池已滿調用將被立即拒絕，默認不採用排隊。加速失敗判定時間。
依賴調用結果分：成功、失敗/拋出異常、超時、線程拒絕、短路。 請求失敗(異常，拒絕，超時，短路)時執行fallback(降級)邏輯。
提供熔斷器組件，可以自動運行或手動調用，停止當前依賴一段時間(10秒)，熔斷器默認錯誤率閾值爲50%，超過將自動運行。
提供近實時依賴的統計和監控。
Hystrix依賴的隔離架構，如下圖：
如何使用Hystrix
使用maven引入Hystrix依賴
1.3.161.1.2com.netflix.hystrixhystrix-core${hystrix.version}com.netflix.hystrixhystrix-metrics-event-stream${hystrix-metrics-event-stream.version}
使用命令模式封裝依賴邏輯
publicclass HelloWorldCommand extends HystrixCommand {privatefinalStringname;publicHelloWorldCommand(Stringname) {//最少配置:指定命令組名(CommandGroup) super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"));this.name = name; } @OverrideprotectedStringrun() {// 依賴邏輯封裝在run()方法中 return"Hello "+ name +" thread:"+ Thread.currentThread().getName(); }//調用實例 publicstaticvoidmain(String[] args)throwsException{//每個Command對象只能調用一次,不可以重複調用, //重複調用對應異常信息HelloWorldCommand helloWorldCommand =newHelloWorldCommand("sync-hystrix");//使用execute()同步調用代碼,效果等同於:helloWorldCommand.queue().get(); Stringresult = helloWorldCommand.execute(); System.out.println("result="+ result); helloWorldCommand =newHelloWorldCommand("async-hystrix");//異步調用,可自由控制獲取結果時機, Future future = helloWorldCommand.queue();//get操作不能超過command定義的超時時間,默認:1秒 result = future.get(100, TimeUnit.MILLISECONDS); System.out.println("result="+ result); System.out.println("mainThread="+ Thread.currentThread().getName()); } }
使用Fallback() 提供降級策略
//重載HystrixCommand的getFallback方法實現邏輯
public class HelloWorldCommand extends HystrixCommand {
private final String name;
public HelloWorldCommand(String name) {
super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("HelloWorldGroup"))
.andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
.withExecutionIsolationThreadTimeoutInMilliseconds(500)));
this.name = name;
}
@Override
protected String getFallback() {
return "exeucute Falled";
}
@Override
protected String run() throws Exception {
//sleep 1 秒,調用會超時
TimeUnit.MILLISECONDS.sleep(1000);
return "Hello " + name +" thread:" + Thread.currentThread().getName();
}
public static void main(String[] args) throws Exception{
HelloWorldCommand command = new HelloWorldCommand("test-Fallback");
String result = command.execute();
}
}
NOTE: 除了HystrixBadRequestException異常之外，所有從run()方法拋出的異常都算作失敗，並觸發降級getFallback()和斷路器邏輯。
HystrixBadRequestException用在非法參數或非系統故障異常等不應觸發回退邏輯的場景。
依賴命名:CommandKey
public HelloWorldCommand(String name) {
super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"))
/ HystrixCommandKey工廠定義依賴名稱 /
.andCommandKey(HystrixCommandKey.Factory.asKey("HelloWorld")));
this.name = name;
}
NOTE: 每個CommandKey代表一個依賴抽象，相同的依賴要使用相同的CommandKey名稱。依賴隔離的根本就是對相同CommandKey的依賴做隔離。
依賴分組:CommandGroup
命令分組用於對依賴操作分組，便於統計，彙總等。
//使用HystrixCommandGroupKey工廠定義 public HelloWorldCommand(String name) { Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("HelloWorldGroup")) }
NOTE: CommandGroup是每個命令最少配置的必選參數，在不指定ThreadPoolKey的情況下，字面值用於對不同依賴的線程池/信號區分。
線程池/信號:ThreadPoolKey
public HelloWorldCommand(String name) {
super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"))
.andCommandKey(HystrixCommandKey.Factory.asKey("HelloWorld"))
/ 使用HystrixThreadPoolKey工廠定義線程池名稱/
.andThreadPoolKey(HystrixThreadPoolKey.Factory.asKey("HelloWorldPool")));
this.name = name;
}
NOTE: 當對同一業務依賴做隔離時使用CommandGroup做區分，但是對同一依賴的不同遠程調用如(一個是redis 一個是http)，可以使用HystrixThreadPoolKey做隔離區分。
最然在業務上都是相同的組，但是需要在資源上做隔離時，可以使用HystrixThreadPoolKey區分。
信號量隔離:SEMAPHORE
隔離本地代碼或可快速返回遠程調用(如memcached，redis)可以直接使用信號量隔離，降低線程隔離開銷。
publicclassHelloWorldCommandextendsHystrixCommand{privatefinalStringname; publicHelloWorldCommand(Stringname) {super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("HelloWorldGroup"))/ 配置信號量隔離方式,默認採用線程池隔離 /.andCommandPropertiesDefaults(HystrixCommandProperties.Setter() .withExecutionIsolationStrategy(HystrixCommandProperties.ExecutionIsolationStrategy.SEMAPHORE)));this.name = name; }@OverrideprotectedStringrun()throwsException{return"HystrixThread:"+Thread.currentThread().getName(); } public static void main(String[] args)throwsException{HelloWorldCommandcommand =newHelloWorldCommand("semaphore");Stringresult = command.execute();System.out.println(result);System.out.println("MainThread:"+Thread.currentThread().getName()); } }
Hystrix關鍵組件分析
Hystrix流程結構解析
流程說明：
1，每次調用創建一個新的HystrixCommand，把依賴調用封裝在run()方法中
2，執行execute()/queue做同步或異步調用
3，判斷熔斷器(circuit-breaker)是否打開，如果打開跳到步驟8，進行降級策略，否則繼續後續步驟
4，判斷線程池/隊列/信號量是否跑滿，如果跑滿進入降級步驟8，否則繼續後續步驟
5，調用HystrixCommand的run方法，運行依賴邏輯
a 依賴邏輯調用超時，進入步驟8
6，判斷邏輯是否調用成功
a 返回成功調用結果
b 調用出錯，進入步驟8
7，計算熔斷器狀態，所有的運行狀態上報給熔斷器，用於統計從而判斷熔斷器狀態
8，getFallback()降級邏輯
以下四種情況將觸發getFallback調用：
run()方法拋出非HystrixBadRequestException異常
run()方法調用超時
熔斷器開啓攔截調用
線程池/隊列/信號量是否跑滿
沒有實現getFallback的Command將直接拋出異常
fallback降級邏輯調用成功直接返回
降級邏輯調用失敗拋出異常
9，返回執行成功結果
熔斷器:Circuit Breaker
Circuit Breaker 流程架構和統計
每個熔斷器默認維護10個bucket，每秒一個bucket，每個blucket記錄成功、失敗、超時、拒絕的狀態，默認錯誤超過50%且10秒內超過20個請求進行中斷攔截.。
隔離(Isolation)分析
Hystrix隔離方式採用線程/信號的方式，通過隔離限制依賴的併發量和阻塞擴散。
(1) 線程隔離
把執行依賴代碼的線程與請求線程分離，請求線程可以自由控制離開的時間(異步過程)。
通過線程池大小可以控制併發量，當線程池飽和時可以提前拒絕服務，防止依賴問題擴散。
線上建議線程池不要設置過大，否則大量堵塞線程有可能會拖慢服務器。
線程池的使用示意圖如下圖所示，當n個請求線程併發對某個接口請求調用時，會先從hystrix管理的線程池裏面獲得一個線程，然後將參數傳遞給這個線程去執行真正調用。線程池的大小有限，默認是10個線程，可以使用maxConcurrentRequests參數配置，如果併發請求數多於線程池線程個數，就有線程需要進入隊列排隊，但排隊隊列也有上限，默認是 5，如果排隊隊列也滿，則必定有請求線程會走fallback流程。
線程池模式可以支持異步調用，支持超時調用，支持直接熔斷，存在線程切換，開銷大。
(2) 線程隔離的優缺點
線程隔離的優點：
使用線程可以完全隔離第三方代碼，請求線程可以快速放回。
當一個失敗的依賴再次變成可用時，線程池將清理，並立即恢復可用，而不是一個長時間的恢復。
可以完全模擬異步調用，方便異步編程。
線程隔離的缺點：
線程池的主要缺點是它增加了cpu，因爲每個命令的執行涉及到排隊(默認使用SynchronousQueue避免排隊)，調度和上下文切換。
對使用ThreadLocal等依賴線程狀態的代碼增加複雜性，需要手動傳遞和清理線程狀態。
NOTE: Netflix公司內部認爲線程隔離開銷足夠小，不會造成重大的成本或性能的影響。
Netflix內部API每天100億的HystrixCommand依賴請求使用線程隔，每個應用大約40多個線程池，每個線程池大約5-20個線程。
(3) 信號隔離
信號隔離也可以用於限制併發訪問，防止阻塞擴散, 與線程隔離最大不同在於執行依賴代碼的線程依然是請求線程（該線程需要通過信號申請）。
如果客戶端是可信的且可以快速返回，可以使用信號隔離替換線程隔離，降低開銷。
線程隔離與信號隔離區別如下圖：
信號量的使用示意圖如下圖所示，當n個併發請求去調用一個目標服務接口時，都要獲取一個信號量才能真正去調用目標服務接口，但信號量有限，默認是10個，可以使用maxConcurrentRequests參數配置，如果併發請求數多於信號量個數，就有線程需要進入隊列排隊，但排隊隊列也有上限，默認是 5，如果排隊隊列也滿，則必定有請求線程會走fallback流程，從而達到限流和防止雪崩的目的。
信號量模式從始至終都只有請求線程自身，是同步調用模式，不支持超時調用，不支持直接熔斷，由於沒有線程的切換，開銷非常小。
(4) 總結
當請求的服務網絡開銷比較大的時候，或者是請求比較耗時的時候，我們最好是使用線程隔離策略，這樣的話，可以保證大量的容器(tomcat)線程可用，不會由於服務原因，一直處於阻塞或等待狀態，快速失敗返回。而當我們請求緩存這些服務的時候，我們可以使用信號量隔離策略，因爲這類服務的返回通常會非常的快，不會佔用容器線程太長時間，而且也減少了線程切換的一些開銷，提高了緩存服務的效率。
線程池：適合絕大多數的場景，99%的。對依賴服務的網絡請求的調用和訪問，timeout這種問題
信號量：適合你的訪問不是對外部依賴的訪問，而是對內部的一些比較複雜的業務邏輯的訪問，但是像這種訪問，系統內部的代碼，其實不涉及任何的網絡請求，那麼只要做信號量的普通限流就可以了，因爲不需要去捕獲timeout類似的問題，算法+數據結構的效率不是太高，併發量突然太高，因爲這裏稍微耗時一些，導致很多線程卡在這裏的話，不太好，所以進行一個基本的資源隔離和訪問，避免內部複雜的低效率的代碼，導致大量的線程被hang住