如何進行Hystrix開源框架

本篇文章給大家分享的是有關如何進行Hystrix開源框架，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

Spring Cloud集成了Hystrix，Hystrix在很多大公司里都在廣泛的使用，我寫了一個開源框架，叫Jboot（開源網址git.oschina.net/fuhai/jboot ），它也集成了Hystrix，同時以Hystrix為核心穿插在整個框架內部。

我有一些之前的同事在阿里、百度、騰訊、滴滴等大公司，他們也都在廣泛的使用Hystrix，但是，卻沒有太好的文章能介紹Hystrix到底是什么？它為什么這么流行？在什么場景下用？解決什么痛點？

Hystrix的介紹：

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

實際上，這樣的解釋及其籠統，對于不了解Hystrix的同學來說還是一頭霧水。

在傳統的項目中，一般的架構如下：

在高爆發情況下，如果沒有采用適當的緩存，瀏覽器的請求會直接被web應用傳送到數據庫去，也就說當有多少個瀏覽器請求，就會有多少個數據庫查詢，這個的時候，數據庫往往會不堪重負，出現異常情況。

比如說：

1. 當數據庫查詢過大，導致數據庫服務器內存占用過高。

2. 當SQL較為復雜，導致數據庫CPU占用過高，或者返回結果較慢。

3. 連接數過多，導致鏈接超時。

4. 等等。

在我們整個web應用在，不同的邏輯（或頁面）對數據庫的查詢造成的壓力往往是不一樣的。

比如說：

1. 查看文章詳情頁面，可能是根據文章的主鍵進行查詢，命中數據庫主鍵索引，效率非常高。

2. 某個文章統計頁面，根據復雜的SQ語句查詢數據庫才會得到的結果，效率很第，同時占用數據庫內存和CPU。

如果當“某個文章統計頁面”被大量訪問，數據庫出現異常情況，有新的請求的時候，總會返回數據庫連接超時，同時也包括“查看文章詳情頁面”。此時，對于訪問文章詳情的用戶來說可能會出現500錯誤。

也就是說，“查看文章詳情頁面”和“某個文章統計頁面”兩個不同的頁面（或者說兩個不同的邏輯）會相互影響。

如何解決此類的問題呢？

這就涉及到我們這篇文章要降到的Hystrix，Hystrix能夠對“查看文章詳情頁面”和“某個文章統計頁面”這兩個不同的頁面進行隔離，當任何一個出現問題的時候，不會影響到其他的頁面。

也就說當“某個文章統計頁面”被大量訪問，出現了數據庫異常情況，導致web應用出現500，那么Hystrix要極力去保證“查看文章詳情頁面”是正常的。

如何做到呢？

Hystrix提供了兩種解決方案：

1. 線程池。

2. 信號量。

在“web應用”訪問“數據庫”的時候，Hystrix會把不同的邏輯放到不同的線程池里去，同時會啟用一個“線程池管理員”來查看線程池里所有線程的執行情況，如果某個連接池異常出現達到一定的量，那么此時，所有的請求都不會再請求到數據庫，直接被Hystrix攔截，并會調用一個本地方法來處理“異常達到一定量”的這種情況，這個過程也叫“降級”。

在上述的業務描述中，“某個文章統計頁面”和“查看文章詳情頁面”是兩個不同的邏輯，會被Hystrix放到兩個不同的線程池里，當“某個文章統計頁面”的錯誤率（異常情況）達到一定的量（這個量可以配置），Hystrix立即切斷了“某個文章統計頁面”和數據庫之間的連接，保證“某個文章統計頁面”不會再繼續消耗數據庫資源。而“查看文章詳情頁面”的錯誤率極低或者系統延遲極低，Hystrix對其正常放行。從而達到了隔離的作用。

不過，Hystrix用得更多的是在RPC（Remote Procedure Call）的使用場景，在分布式架構下，不同的系統之間會相互調用，一旦某個子系統出現異常，Hystrix立即切斷其他系統和異常子系統的聯系。

如下圖所示：

假設上圖的頂部“User Request”是訪問某在線商城的個人中心頁面，個人中心頁面里顯示了：個人資料、推薦商品、購物車和我的快遞信息等。

個人資料、推薦商品、購物車、我的快遞信息分別來至于四個子系統。大概由如下代碼組成：

public void userCenter(){

        List<Goods> recommendGoodsList = system1.queryGoodsList();
        List<Goods> myGoodsList = system2.queryMyGoodsList();
        List<ExpressInfo> myExpressInfoList = system3.queyrMyExpressList();
        User myInfo = system4.queryMyInfo();
  
        request.setAttribute(“recommendGoodsList”,recommendGoodsList);
        request.setAttribute(“myGoodsList”,myGoodsList);
        request.setAttribute(“myExpressInfoList”,myExpressInfoList);
        request.setAttribute(“myInfo”,myInfo);

        render(“userCenter.html”);
}

此時，若“快遞信息”子系統出現了問題，如下圖所示： 

1. public void userCenter(){

2.         List<Goods> recommendGoodsList = system1.queryGoodsList();

3.         List<Goods> myGoodsList = system2.queryMyGoodsList();

4.         List<ExpressInfo> myExpressInfoList = system3.queyrMyExpressList();

5.         User myInfo = system4.queryMyInfo();

6.    

7.         request.setAttribute(“recommendGoodsList”,recommendGoodsList);

8.         request.setAttribute(“myGoodsList”,myGoodsList);

9.         request.setAttribute(“myExpressInfoList”,myExpressInfoList);

10.         request.setAttribute(“myInfo”,myInfo);

11.         render(“userCenter.html”);

12. }

那么此時，第四行代碼“ system3.queyrMyExpressList();”會出現等待情況，從而導致所有的請求都會出現等待情況，如下圖：

更加可怕的是，當所有的請求都在等待的時候，系統資源會很快被耗盡，從而導致系統奔潰，甚至連重啟系統都不行（因為重啟后，請求又立即進來消耗資源）。一個服務器的等待，也可能會導致其他服務器出現等待（不同的服務器之間往往都會有相互調用數據的情況），此時所有的業務系統全部奔潰，又稱：雪崩效應。

當有了Hystrix的隔離之后，每個業務都會在自己的線程池里被管理，當List<ExpressInfo> myExpressInfoList = system3.queyrMyExpressList(); 出現問題（延遲或錯誤）達到一定量的時候，system3.queyrMyExpressList();會立即返回數據（一般情況下是空數據，由降級函數執行返回結果）而不會出現等待的情況，從而保證系統正常運作。

我們回頭來看下Hystrix的定義：

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

此時，你是否對Hystrix的定義有所理解了呢？

值得贊賞的是，Hystrix對線程池的管理，還提供了一個可視化的監控系統 hystrix-dashboard 來查看每個線程池的情況。如果你的電腦上安裝有docker，可以通過以下命令來啟動 hystrix-dashboard：

docker run --rm -ti -p 7979:7979 kennedyoliveira/hystrix-dashboard

如果沒有docker環境也沒關系，你也可以執行通過以下方法來編譯啟動 hystrix-dashboard：

1. $ git clone https://github.com/Netflix/Hystrix.git

2. $ cd Hystrix/hystrix-dashboard

3. $ ../gradlew appRun

4. > Building > :hystrix-dashboard:appRun > Running at http://localhost:7979/hystrix-dashboard

啟動 hystrix-dashboard 成功后，可以通過瀏覽器訪問http://localhost:7979/hystrix-dashboard 來查看 hystrix-dashboard 。

如下圖所示：

填寫“web應用”的Hystrix的stream地址后，點擊“monitor stream”按鈕，我們就可以看到Hystrix對整個應用的監控情況了。

備注：在Jboot框架開發的應用中，我們需要在jboot.properties配置“jboot.hystrix.url = /hystrix.stream”，此時Hystrix的stream地址為：http://host:port/hystrix.stream 。

Srping Cloud等要做的事情比較多，不像Jboot一行配置就可以使用，請自行查看其幫助文檔。

到此，Hystrix的介紹就完畢了，這篇文章并沒有涉及到Hystrix如何去使用，網上有非常多的文章來講解如何使用Hystrix，但是卻沒有一篇文章來系統介紹什么是Hystrix。我覺得對任何技術，理解要比使用重要很多，這也是我為什么寫這篇文章的原因。

以上就是如何進行Hystrix開源框架，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。