文章初衷
為了應對將來在線（特別是無線端）業務量的成倍增長，后端服務的分布式化程度需要不斷提高，對於服務的延遲和容錯管理將面臨更大挑戰，公司框架和開源團隊選擇內部推廣Netflix的Hystrix，一是為了推進各部門的服務使用覆蓋率，二是為了增加C Sharp語言版本的參與度（目前公司至少三成服務由.NET編寫）。該博文屬於個人對Hystrix研究和實踐經驗。
什么是Hystrix？
Hystrix是世界最大在線影片租賃服務商Netflix開源，針對分布式系統的延遲和容錯庫。該庫由Java寫成，項目源於Netflix API團隊在2011年啟動的彈性工程項目。項目在github上發布至今，已經有接近三千顆星，只有少數優秀的開源項目才能享受到千星級別的待遇，Hystrix成功可見一斑。
為什么使用Hystrix？
在大中型分布式系統中，通常系統很多依賴(HTTP,hession,Netty,Dubbo等)，如下圖:
在高並發訪問下,這些依賴的穩定性與否對系統的影響非常大,但是依賴有很多不可控問題:如網絡連接緩慢，資源繁忙，暫時不可用，服務脫機等.
如下圖：QPS為50的依賴 I 出現不可用，但是其他依賴仍然可用.
當依賴I 阻塞時,大多數服務器的線程池就出現阻塞(BLOCK),影響整個線上服務的穩定性.如下圖:
在復雜的分布式架構的應用程序有很多的依賴，都會不可避免地在某些時候失敗。高並發的依賴失敗時如果沒有隔離措施，當前應用服務就有被拖垮的風險。
例如:一個依賴30個SOA服務的系統,每個服務99.99%可用。 99.99%的30次方 ≈ 99.7% 0.3% 意味着一億次請求 會有 3,000,00次失敗 換算成時間大約每月有2個小時服務不穩定. 隨着服務依賴數量的變多，服務不穩定的概率會成指數性提高.
解決問題方案:對依賴做隔離,Hystrix就是處理依賴隔離的框架,同時也是可以幫我們做依賴服務的治理和監控.
到底能做什么呢？
1）Hystrix使用命令模式HystrixCommand(Command)包裝依賴調用邏輯，每個命令在單獨線程中/信號授權下執行
2）提供熔斷器組件,可以自動運行或手動調用,停止當前依賴一段時間(10秒)，熔斷器默認錯誤率閾值為50%,超過將自動運行。
3）可配置依賴調用超時時間,超時時間一般設為比99.5%平均時間略高即可.當調用超時時，直接返回或執行fallback邏輯。
4）為每個依賴提供一個小的線程池（或信號），如果線程池已滿調用將被立即拒絕，默認不采用排隊.加速失敗判定時間。
5）依賴調用結果分:成功，失敗（拋出異常），超時，線程拒絕，短路。 請求失敗(異常，拒絕，超時，短路)時執行fallback(降級)邏輯。
6）提供近實時依賴的統計和監控
7）支持異步執行。支持並發請求緩存。自動批處理失敗請求。
Hystrix設計理念
想要知道如何使用，必須先明白其核心設計理念，Hystrix基於命令模式，通過UML圖先直觀的認識一下這一設計模式
可見，Command是在Receiver和Invoker之間添加的中間層，Command實現了對Receiver的封裝。那么Hystrix的應用場景如何與上圖對應呢？
API既可以是Invoker又可以是reciever，通過繼承Hystrix核心類HystrixCommand來封裝這些API（例如，遠程接口調用，數據庫查詢之類可能會產生延時的操作）。就可以為API提供彈性保護了。
Hello World
Hello World的例子旨在展示，如何在項目中低侵入式的改造，使API置於Hystrix保護之下！
引入maven依賴
<!-- 依賴版本 -->
<hystrix.version>1.3.16</hystrix.version>
<hystrix-metrics-event-stream.version>1.1.2</hystrix-metrics-event-stream.version>
<dependency>
<groupId>com.netflix.hystrix</groupId>
<artifactId>hystrix-core</artifactId>
<version>${hystrix.version}</version>
</dependency>
<dependency>
<groupId>com.netflix.hystrix</groupId>
<artifactId>hystrix-metrics-event-stream</artifactId>
<version>${hystrix-metrics-event-stream.version}</version>
</dependency>
<!-- 倉庫地址 -->
<repository>
<id>nexus</id>
<name>local private nexus</name>
<url>http://maven.oschina.net/content/groups/public/</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
下面是一個沒有使用Hystrix保護的sayHello的服務以及它的調用
//API調用，可能會產生延時 public class HelloService { public static String sayHello(final String name) { return String.format("Hello %s!", name); } } //客戶端直接調用API public class Client{ public static void main(String[] args) { System.out.println(HelloService.sayHello("World")); } }
假設字符串生成過程是一個需要保護的操作，下面我們用Hystrix進行封裝。
需要注意的是，雖然使用命令模式，但是我們這里不建議覆蓋execute方法，而是實現run的模版方法，多數框架的實現會采用template設計模式，並且將模版方法設置為protected簽名，這樣做的好處是，既可以將具體的業務交給業務實現者，又可以為之添加其他功能，而業務實現者只需要關注自己的業務就好了。比如這里HystrixCommand.execute方法實際上是調用了HystrixCommand.queue().get()，而queue方法除了最終調用run之外，還需要為run方法提供超時和異常等保護功能，外部也不能直接調用非安全的run方法，這一實踐非常值得我們學習。
OK，現在我們通過實現run方法來包裝sayHello功能，我們通過一個私有域_name，通過構造函數來傳遞消息，獲取構造參數的拷貝來保持不變性。
public class SayHelloCommand extends HystrixCommand<String> { private final String _name; public SayHelloCommand(String name) { super(HystrixCommandGroupKey.Factory.asKey("HelloService")); _name = new String(name);//unmutable } @Override protected String run() { return String.format("Hello %s!", _name); } }
API改造如下,作為門面方法最好不要改動函數的簽名（除非參數和返回類型有變動，這是因為客戶端代碼的改動代價往往是巨大的），同時提供版本sayHelloAsync，該方法提供了異步功能
public class HelloService { // public static String sayHello(final String name) // { // return "Hello " + name + "!"; // } /** * sayHello under protection of Hystrix * @param name * @return <code>"Hello " + name + "!"</code> */ public static String sayHello(final String name) { return new SayHelloCommand(name).execute(); } /** * call async * @param name * @return */ public static Future<String> sayHelloAsync(final String name) { return new SayHelloCommand(name).queue(); } }
接下來我們來看看，如何在超時熔斷情況下使用FallBack策略，這點在項目中是相當有用的，比如超時后訪問數據備庫，或者直接返回重試響應
首先SayHelloCommand構造函數使用Hystrix的Setter來設置超時時間，這里解釋下Setter這個類涉及到的幾個最佳實踐
1.Setter使用builder模式，想想構造函數有很多參數要設置，作為構造參數傳遞會大大降低可閱讀性，用靜態工廠方法一個個設置又可能造成多線程並發下的不一致性，而且這種bug往往非常難以定位，所以builder模式是非常好的實踐。將Setter作為構造器傳給HystrixCommand的構造函數，Setter中又很多靜態方法，可以通過方法名明確的知道元素的意義。
2.Setter是HystrixCommand內部靜態類，Hystrix代碼大量的使用了內部靜態類，來作為該類的工廠方法，或者構造器，我覺得這樣划分使代碼職責更加清晰，比單獨的工廠類更易於維護。
3.Setter使用函數式串聯，每個靜態工廠方法返回Setter實例，這樣我們可以把構造過程串聯起來,使代碼更加易於閱讀。
4.Setter是不可變類，每個靜態工廠方法返回一個新的Setter拷貝，所以Setter是線程安全的。
OK，Setter介紹到這里，這里我們繼續設置超時時間為500
public SayHelloCommand(final String name) { //builder for HystrixCommand super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("HelloServiceGroup")) .andCommandPropertiesDefaults(HystrixCommandProperties.Setter().withTimeoutInMilliseconds(500))); _name = new String(name); }
run方法我們使用Thread.sleep(600)來特意達到超時的效果，同時實現getFallback方法，程序超時后會立即運行FallBack
@Override protected String getFallback() { return String.format("[FallBack]Hello %s!", _name); } @Override protected String run() throws Exception { //TimeOut Thread.sleep(600); return String.format("Hello %s!", _name); }
最終輸出：
[FallBack]Hello World!
回顧重點
1.Hystrix可以為分布式服務提供彈性保護
2.Hystrix通過命令模式封裝調用，來實現彈性保護，繼承HystrixCommand並且實現run方法，就完成了最簡單的封裝。
3. 實現getFallBack方法可以為熔斷或者異常提供后備處理方法。
4.HystrixCommand中Setter類的最佳實踐。
5.模版方法在框架中的實踐。