前言

在上一篇《Spring Cloud構(gòu)建微服務(wù)架構(gòu)：服務(wù)容錯保護(Hystrix服務(wù)降級)》中，我們已經(jīng)體驗了如何使用@HystrixCommand來為一個依賴資源定義服務(wù)降級邏輯。實現(xiàn)方式非常簡單，同時對于降級邏輯還能實現(xiàn)一些更加復(fù)雜的級聯(lián)降級等策略。之前對于使用Hystrix來實現(xiàn)服務(wù)容錯保護時，除了服務(wù)降級之外，我們還提到過線程隔離、斷路器等功能。那么在本篇中我們就來具體說說線程隔離。

依賴隔離

“艙壁模式”對于熟悉Docker的讀者一定不陌生，Docker通過“艙壁模式”實現(xiàn)進程的隔離，使得容器與容器之間不會互相影響。而Hystrix則使用該模式實現(xiàn)線程池的隔離，它會為每一個Hystrix命令創(chuàng)建一個獨立的線程池，這樣就算某個在Hystrix命令包裝下的依賴服務(wù)出現(xiàn)延遲過高的情況，也只是對該依賴服務(wù)的調(diào)用產(chǎn)生影響，而不會拖慢其他的服務(wù)。

通過對依賴服務(wù)的線程池隔離實現(xiàn)，可以帶來如下優(yōu)勢：

• 應(yīng)用自身得到完全的保護，不會受不可控的依賴服務(wù)影響。即便給依賴服務(wù)分配的線程池被填滿，也不會影響應(yīng)用自身的額其余部分。
• 可以有效的降低接入新服務(wù)的風(fēng)險。如果新服務(wù)接入后運行不穩(wěn)定或存在問題，完全不會影響到應(yīng)用其他的請求。
• 當依賴的服務(wù)從失效恢復(fù)正常后，它的線程池會被清理并且能夠馬上恢復(fù)健康的服務(wù)，相比之下容器級別的清理恢復(fù)速度要慢得多。
• 當依賴的服務(wù)出現(xiàn)配置錯誤的時候，線程池會快速的反應(yīng)出此問題(通過失敗次數(shù)、延遲、超時、拒絕等指標的增加情況)。同時，我們可以在不影響應(yīng)用功能的情況下通過實時的動態(tài)屬性刷新(后續(xù)會通過Spring Cloud Config與Spring Cloud Bus的聯(lián)合使用來介紹)來處理它。
• 當依賴的服務(wù)因?qū)崿F(xiàn)機制調(diào)整等原因造成其性能出現(xiàn)很大變化的時候，此時線程池的監(jiān)控指標信息會反映出這樣的變化。同時，我們也可以通過實時動態(tài)刷新自身應(yīng)用對依賴服務(wù)的閾值進行調(diào)整以適應(yīng)依賴方的改變。
• 除了上面通過線程池隔離服務(wù)發(fā)揮的優(yōu)點之外，每個專有線程池都提供了內(nèi)置的并發(fā)實現(xiàn)，可以利用它為同步的依賴服務(wù)構(gòu)建異步的訪問。

總之，通過對依賴服務(wù)實現(xiàn)線程池隔離，讓我們的應(yīng)用更加健壯，不會因為個別依賴服務(wù)出現(xiàn)問題而引起非相關(guān)服務(wù)的異常。同時，也使得我們的應(yīng)用變得更加靈活，可以在不停止服務(wù)的情況下，配合動態(tài)配置刷新實現(xiàn)性能配置上的調(diào)整。

雖然線程池隔離的方案帶了如此多的好處，但是很多使用者可能會擔(dān)心為每一個依賴服務(wù)都分配一個線程池是否會過多地增加系統(tǒng)的負載和開銷。對于這一點，使用者不用過于擔(dān)心，因為這些顧慮也是大部分工程師們會考慮到的，Netflix在設(shè)計Hystrix的時候，認為線程池上的開銷相對于隔離所帶來的好處是無法比擬的。同時，Netflix也針對線程池的開銷做了相關(guān)的測試，以證明和打消Hystrix實現(xiàn)對性能影響的顧慮。

下圖是Netflix Hystrix官方提供的一個Hystrix命令的性能監(jiān)控，該命令以每秒60個請求的速度(QPS)向一個單服務(wù)實例進行訪問，該服務(wù)實例每秒運行的線程數(shù)峰值為350個。

從圖中的統(tǒng)計我們可以看到，使用線程池隔離與不使用線程池隔離的耗時差異如下表所示：

在99%的情況下，使用線程池隔離的延遲有9ms，對于大多數(shù)需求來說這樣的消耗是微乎其微的，更何況為系統(tǒng)在穩(wěn)定性和靈活性上所帶來的巨大提升。雖然對于大部分的請求我們可以忽略線程池的額外開銷，而對于小部分延遲本身就非常小的請求(可能只需要1ms)，那么9ms的延遲開銷還是非常昂貴的。實際上Hystrix也為此設(shè)計了另外的一個解決方案：信號量。

Hystrix中除了使用線程池之外，還可以使用信號量來控制單個依賴服務(wù)的并發(fā)度，信號量的開銷要遠比線程池的開銷小得多，但是它不能設(shè)置超時和實現(xiàn)異步訪問。所以，只有在依賴服務(wù)是足夠可靠的情況下才使用信號量。在HystrixCommand和HystrixObservableCommand中2處支持信號量的使用：

• 命令執(zhí)行：如果隔離策略參數(shù)execution.isolation.strategy設(shè)置為SEMAPHORE，Hystrix會使用信號量替代線程池來控制依賴服務(wù)的并發(fā)控制。
• 降級邏輯：當Hystrix嘗試降級邏輯時候，它會在調(diào)用線程中使用信號量。

信號量的默認值為10，我們也可以通過動態(tài)刷新配置的方式來控制并發(fā)線程的數(shù)量。對于信號量大小的估算方法與線程池并發(fā)度的估算類似。僅訪問內(nèi)存數(shù)據(jù)的請求一般耗時在1ms以內(nèi)，性能可以達到5000rps，這樣級別的請求我們可以將信號量設(shè)置為1或者2，我們可以按此標準并根據(jù)實際請求耗時來設(shè)置信號量。

如何使用

說了那么多依賴隔離的好處，那么我們?nèi)绾问褂肏ystrix來實現(xiàn)依賴隔離呢?其實，我們在上一篇定義服務(wù)降級的時候，已經(jīng)自動的實現(xiàn)了依賴隔離。

在上一篇的示例中，我們使用了@HystrixCommand來將某個函數(shù)包裝成了Hystrix命令，這里除了定義服務(wù)降級之外，Hystrix框架就會自動的為這個函數(shù)實現(xiàn)調(diào)用的隔離。所以，依賴隔離、服務(wù)降級在使用時候都是一體化實現(xiàn)的，這樣利用Hystrix來實現(xiàn)服務(wù)容錯保護在編程模型上就非常方便的，并且考慮更為全面。除了依賴隔離、服務(wù)降級之外，還有一個重要元素：斷路器。我們將在下一篇做詳細的介紹，這三個重要利器構(gòu)成了Hystrix實現(xiàn)服務(wù)容錯保護的強力組合拳。

更多Spring Cloud內(nèi)容請持續(xù)關(guān)注我的博客更新或在《Spring Cloud微服務(wù)實戰(zhàn)》中獲取。

代碼示例

樣例工程將沿用之前在碼云和GitHub上創(chuàng)建的SpringCloud-Learning項目，重新做了一下整理。通過不同目錄來區(qū)分Brixton和Dalston的示例。

碼云：點擊查看

GitHub：點擊查看

【本文為51CTO專欄作者“翟永超”的原創(chuàng)稿件，轉(zhuǎn)載請通過51CTO聯(lián)系作者獲取授權(quán)】

戳這里，看該作者更多好文