依賴隔離

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

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

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

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

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

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

命令執(zhí)行：如果隔離策略參數(shù)execution.isolation.strategy設(shè)置為SEMAPHORE，Hystrix會使用信號量替代線程池來控制依賴服務(wù)的并發(fā)控制。
降級邏輯：當(dāng)Hystrix嘗試降級邏輯時(shí)候，它會在調(diào)用線程中使用信號量。
信號量的默認(rèn)值為10，我們也可以通過動態(tài)刷新配置的方式來控制并發(fā)線程的數(shù)量。對于信號量大小的估算方法與線程池并發(fā)度的估算類似。僅訪問內(nèi)存數(shù)據(jù)的請求一般耗時(shí)在1ms以內(nèi)，性能可以達(dá)到5000rps，這樣級別的請求我們可以將信號量設(shè)置為1或者2，我們可以按此標(biāo)準(zhǔn)并根據(jù)實(shí)際請求耗時(shí)來設(shè)置信號量。

如何使用

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

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

從現(xiàn)在開始，我這邊會將近期研發(fā)的springcloud微服務(wù)云架構(gòu)的搭建過程和精髓記錄下來，幫助更多有興趣研發(fā)spring cloud框架的朋友，希望可以幫助更多的好學(xué)者。大家來一起探討spring cloud架構(gòu)的搭建過程及如何運(yùn)用于企業(yè)項(xiàng)目。
源碼來源：minglisoft.cn/honghu/tech…

總結(jié)

以上是生活随笔為你收集整理的Spring Cloud构建微服务架构-Hystrix依赖隔离的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。