如何進行Hystrix開源框架

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

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

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

Hystrix的介紹：

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

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

在傳統(tǒng)的項目中，一般的架構(gòu)如下：

在高爆發(fā)情況下，如果沒有采用適當?shù)木彺妫瑸g覽器的請求會直接被web應(yīng)用傳送到數(shù)據(jù)庫去，也就說當有多少個瀏覽器請求，就會有多少個數(shù)據(jù)庫查詢，這個的時候，數(shù)據(jù)庫往往會不堪重負，出現(xiàn)異常情況。

比如說：

1. 當數(shù)據(jù)庫查詢過大，導(dǎo)致數(shù)據(jù)庫服務(wù)器內(nèi)存占用過高。

2. 當SQL較為復(fù)雜，導(dǎo)致數(shù)據(jù)庫CPU占用過高，或者返回結(jié)果較慢。

3. 連接數(shù)過多，導(dǎo)致鏈接超時。

4. 等等。

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

比如說：

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

2. 某個文章統(tǒng)計頁面，根據(jù)復(fù)雜的SQ語句查詢數(shù)據(jù)庫才會得到的結(jié)果，效率很第，同時占用數(shù)據(jù)庫內(nèi)存和CPU。

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

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

如何解決此類的問題呢？

這就涉及到我們這篇文章要降到的Hystrix，Hystrix能夠?qū)Α安榭次恼略斍轫撁妗焙汀澳硞€文章統(tǒng)計頁面”這兩個不同的頁面進行隔離，當任何一個出現(xiàn)問題的時候，不會影響到其他的頁面。

也就說當“某個文章統(tǒng)計頁面”被大量訪問，出現(xiàn)了數(shù)據(jù)庫異常情況，導(dǎo)致web應(yīng)用出現(xiàn)500，那么Hystrix要極力去保證“查看文章詳情頁面”是正常的。

如何做到呢？

Hystrix提供了兩種解決方案：

1. 線程池。

2. 信號量。

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

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

不過，Hystrix用得更多的是在RPC（Remote Procedure Call）的使用場景，在分布式架構(gòu)下，不同的系統(tǒng)之間會相互調(diào)用，一旦某個子系統(tǒng)出現(xiàn)異常，Hystrix立即切斷其他系統(tǒng)和異常子系統(tǒng)的聯(lián)系。

如下圖所示：

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

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

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”);
}

此時，若“快遞信息”子系統(tǒng)出現(xiàn)了問題，如下圖所示： 

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();”會出現(xiàn)等待情況，從而導(dǎo)致所有的請求都會出現(xiàn)等待情況，如下圖：

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

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

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

“Hystrix 供分布式系統(tǒng)使用，提供延遲和容錯功能，隔離遠程系統(tǒng)、訪問和第三方程序庫的訪問點，防止級聯(lián)失敗，保證復(fù)雜的分布系統(tǒng)在面臨不可避免的失敗時，仍能有其彈性?！?/p>

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

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

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

如果沒有docker環(huán)境也沒關(guān)系，你也可以執(zhí)行通過以下方法來編譯啟動 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應(yīng)用”的Hystrix的stream地址后，點擊“monitor stream”按鈕，我們就可以看到Hystrix對整個應(yīng)用的監(jiān)控情況了。

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

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

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

以上就是如何進行Hystrix開源框架，小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降?。希望你能通過這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注億速云行業(yè)資訊頻道。