1.概述

? ? ? ?分布式系統(tǒng)中經(jīng)常會(huì)出現(xiàn)某個(gè)基礎(chǔ)服務(wù)不可用造成整個(gè)系統(tǒng)不可用的情況, 這種現(xiàn)象被稱為服務(wù)雪崩效應(yīng).

?為了應(yīng)對(duì)服務(wù)雪崩, 一種常見(jiàn)的做法是手動(dòng)服務(wù)降級(jí). 而Hystrix的出現(xiàn),給我們提供了另一種選擇.

2.服務(wù)雪崩效應(yīng)的定義

服務(wù)雪崩效應(yīng)是一種因?服務(wù)提供者?的不可用導(dǎo)致?服務(wù)調(diào)用者?的不可用,并將不可用?逐漸放大?的過(guò)程.如果所示:

上圖中, A為服務(wù)提供者, B為A的服務(wù)調(diào)用者, C和D是B的服務(wù)調(diào)用者. 當(dāng)A的不可用,引起B(yǎng)的不可用,并將不可用逐漸放大C和D時(shí), 服務(wù)雪崩就形成了.

3.服務(wù)雪崩效應(yīng)形成的原因

我把服務(wù)雪崩的參與者簡(jiǎn)化為?服務(wù)提供者?和?服務(wù)調(diào)用者, 并將服務(wù)雪崩產(chǎn)生的過(guò)程分為以下三個(gè)階段來(lái)分析形成的原因:

服務(wù)提供者不可用

重試加大流量

服務(wù)調(diào)用者不可用

服務(wù)雪崩的每個(gè)階段都可能由不同的原因造成, 比如造成?服務(wù)不可用?的原因有:

• 硬件故障

• 程序Bug

• 緩存擊穿

• 用戶大量請(qǐng)求

硬件故障可能為硬件損壞造成的服務(wù)器主機(jī)宕機(jī), 網(wǎng)絡(luò)硬件故障造成的服務(wù)提供者的不可訪問(wèn).?
緩存擊穿一般發(fā)生在緩存應(yīng)用重啟, 所有緩存被清空時(shí),以及短時(shí)間內(nèi)大量緩存失效時(shí). 大量的緩存不命中, 使請(qǐng)求直擊后端,造成服務(wù)提供者超負(fù)荷運(yùn)行,引起服務(wù)不可用.?
在秒殺和大促開(kāi)始前,如果準(zhǔn)備不充分,用戶發(fā)起大量請(qǐng)求也會(huì)造成服務(wù)提供者的不可用.

而形成?重試加大流量?的原因有:

• 用戶重試 ? ? （在服務(wù)提供者不可用后, 用戶由于忍受不了界面上長(zhǎng)時(shí)間的等待,而不斷刷新頁(yè)面甚至提交表單）

• 代碼邏輯重試 ? ??.

? ? ? ? ?服務(wù)調(diào)用端的會(huì)存在大量服務(wù)異常后的重試邏輯.?
? ? ? ? 這些重試都會(huì)進(jìn)一步加大請(qǐng)求流量.

最后,?服務(wù)調(diào)用者不可用?產(chǎn)生的主要原因是:

• 同步等待造成的資源耗盡

當(dāng)服務(wù)調(diào)用者使用?同步調(diào)用?時(shí), 會(huì)產(chǎn)生大量的等待線程占用系統(tǒng)資源. 一旦線程資源被耗盡,服務(wù)調(diào)用者提供的服務(wù)也將處于不可用狀態(tài), 于是服務(wù)雪崩效應(yīng)產(chǎn)生了.

4. 服務(wù)雪崩的應(yīng)對(duì)策略

針對(duì)造成服務(wù)雪崩的不同原因, 可以使用不同的應(yīng)對(duì)策略:

流量控制

改進(jìn)緩存模式

服務(wù)自動(dòng)擴(kuò)容

服務(wù)調(diào)用者降級(jí)服務(wù)

流量控制?的具體措施包括:

• 網(wǎng)關(guān)限流

• 用戶交互限流

• 關(guān)閉重試

因?yàn)镹ginx的高性能, 目前一線互聯(lián)網(wǎng)公司大量采用Nginx+Lua的網(wǎng)關(guān)進(jìn)行流量控制, 由此而來(lái)的OpenResty也越來(lái)越熱門(mén).

用戶交互限流的具體措施有: 1. 采用加載動(dòng)畫(huà),提高用戶的忍耐等待時(shí)間. 2. 提交按鈕添加強(qiáng)制等待時(shí)間機(jī)制.

改進(jìn)緩存模式?的措施包括:

• 緩存預(yù)加載

• 同步改為異步刷新

服務(wù)自動(dòng)擴(kuò)容?的措施主要有:

• AWS的auto scaling ?（https://aws.amazon.com/cn/autoscaling/）

服務(wù)調(diào)用者降級(jí)服務(wù)?的措施包括:

• 資源隔離

• 對(duì)依賴服務(wù)進(jìn)行分類

• 不可用服務(wù)的調(diào)用快速失敗

資源隔離主要是對(duì)調(diào)用服務(wù)的線程池進(jìn)行隔離.

我們根據(jù)具體業(yè)務(wù),將依賴服務(wù)分為: ?強(qiáng)依賴和若依賴. ?強(qiáng)依賴服務(wù)不可用會(huì)導(dǎo)致當(dāng)前業(yè)務(wù)中止,而弱依賴服務(wù)的不可用不會(huì)導(dǎo)致當(dāng)前業(yè)務(wù)的中止.

不可用服務(wù)的調(diào)用快速失敗一般通過(guò) ?超時(shí)機(jī)制,?熔斷器?和熔斷后的?降級(jí)方法?來(lái)實(shí)現(xiàn).

5. 使用Hystrix預(yù)防服務(wù)雪崩

? ?Hystrix?[h?st'r?ks]的中文含義是豪豬, 因其背上長(zhǎng)滿了刺,而擁有自我保護(hù)能力.

? ?Netflix的?Hystrix?是一個(gè)幫助解決分布式系統(tǒng)交互時(shí)超時(shí)處理和容錯(cuò)的類庫(kù), 它同樣擁有保護(hù)系統(tǒng)的能力.

Hystrix的設(shè)計(jì)原則包括:

• 資源隔離

• 熔斷器

• 命令模式

5.1 資源隔離

貨船為了進(jìn)行防止漏水和火災(zāi)的擴(kuò)散,會(huì)將貨倉(cāng)分隔為多個(gè), 如下圖所示:

這種資源隔離減少風(fēng)險(xiǎn)的方式被稱為:Bulkheads(艙壁隔離模式).?
Hystrix將同樣的模式運(yùn)用到了服務(wù)調(diào)用者上.

在一個(gè)高度服務(wù)化的系統(tǒng)中,我們實(shí)現(xiàn)的一個(gè)業(yè)務(wù)邏輯通常會(huì)依賴多個(gè)服務(wù),比如:?
商品詳情展示服務(wù)會(huì)依賴商品服務(wù), 價(jià)格服務(wù), 商品評(píng)論服務(wù). 如圖所示:

調(diào)用三個(gè)依賴服務(wù)會(huì)共享商品詳情服務(wù)的線程池. 如果其中的商品評(píng)論服務(wù)不可用, 就會(huì)出現(xiàn)線程池里所有線程都因等待響應(yīng)而被阻塞, 從而造成服務(wù)雪崩. 如圖所示:

Hystrix通過(guò)將每個(gè)依賴服務(wù)分配獨(dú)立的線程池進(jìn)行資源隔離, 從而避免服務(wù)雪崩.?
如下圖所示, 當(dāng)商品評(píng)論服務(wù)不可用時(shí), 即使商品服務(wù)獨(dú)立分配的20個(gè)線程全部處于同步等待狀態(tài),也不會(huì)影響其他依賴服務(wù)的調(diào)用.

5.2 熔斷器模式

熔斷器模式定義了熔斷器開(kāi)關(guān)相互轉(zhuǎn)換的邏輯:

服務(wù)的健康狀況 = 請(qǐng)求失敗數(shù) / 請(qǐng)求總數(shù).?
熔斷器開(kāi)關(guān)由關(guān)閉到打開(kāi)的狀態(tài)轉(zhuǎn)換是通過(guò)當(dāng)前服務(wù)健康狀況和設(shè)定閾值比較決定的.

當(dāng)熔斷器開(kāi)關(guān)關(guān)閉時(shí), 請(qǐng)求被允許通過(guò)熔斷器. 如果當(dāng)前健康狀況高于設(shè)定閾值, 開(kāi)關(guān)繼續(xù)保持關(guān)閉. 如果當(dāng)前健康狀況低于設(shè)定閾值, 開(kāi)關(guān)則切換為打開(kāi)狀態(tài).

當(dāng)熔斷器開(kāi)關(guān)打開(kāi)時(shí), 請(qǐng)求被禁止通過(guò).

當(dāng)熔斷器開(kāi)關(guān)處于打開(kāi)狀態(tài), 經(jīng)過(guò)一段時(shí)間后, 熔斷器會(huì)自動(dòng)進(jìn)入半開(kāi)狀態(tài), 這時(shí)熔斷器只允許一個(gè)請(qǐng)求通過(guò). 當(dāng)該請(qǐng)求調(diào)用成功時(shí), 熔斷器恢復(fù)到關(guān)閉狀態(tài). 若該請(qǐng)求失敗, 熔斷器繼續(xù)保持打開(kāi)狀態(tài), 接下來(lái)的請(qǐng)求被禁止通過(guò).

熔斷器的開(kāi)關(guān)能保證服務(wù)調(diào)用者在調(diào)用異常服務(wù)時(shí), 快速返回結(jié)果, 避免大量的同步等待.

并且熔斷器能在一段時(shí)間后繼續(xù)偵測(cè)請(qǐng)求執(zhí)行結(jié)果, 提供恢復(fù)服務(wù)調(diào)用的可能.

5.3 命令模式

? ? ? ?Hystrix 使用命令模式 (繼承HystrixCommand類) 來(lái)包裹具體的服務(wù)調(diào)用邏輯(run方法) ,

? ? ? ?并在命令模式中添加了服務(wù)調(diào)用失敗后的降級(jí)邏輯(getFallback) .

同時(shí)我們?cè)贑ommand的構(gòu)造方法中可以定義當(dāng)前服務(wù)線程池和熔斷器的相關(guān)參數(shù). 如下代碼所示:

public class Service1HystrixCommand extends HystrixCommand<Response> {private Service1 service;private Request request;public Service1HystrixCommand(Service1 service, Request request){supper(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ServiceGroup")).andCommandKey(HystrixCommandKey.Factory.asKey("servcie1query")).andThreadPoolKey(HystrixThreadPoolKey.Factory.asKey("service1ThreadPool")).andThreadPoolPropertiesDefaults(HystrixThreadPoolProperties.Setter().withCoreSize(20))//服務(wù)線程池?cái)?shù)量 .andCommandPropertiesDefaults(HystrixCommandProperties.Setter().withCircuitBreakerErrorThresholdPercentage(60)//熔斷器關(guān)閉到打開(kāi)閾值.withCircuitBreakerSleepWindowInMilliseconds(3000)//熔斷器打開(kāi)到關(guān)閉的時(shí)間窗長(zhǎng)度 ))this.service = service;this.request = request;);}@Overrideprotected Response run(){return service1.call(request);}@Overrideprotected Response getFallback(){return Response.dummy();} }

?

在使用了Command模式構(gòu)建了服務(wù)對(duì)象之后, 服務(wù)便擁有了熔斷器和線程池的功能.?

5.4 Hystrix的內(nèi)部處理邏輯

下圖為Hystrix服務(wù)調(diào)用的內(nèi)部邏輯:?

構(gòu)建Hystrix的Command對(duì)象, 調(diào)用執(zhí)行方法.

Hystrix檢查當(dāng)前服務(wù)的熔斷器開(kāi)關(guān)是否開(kāi)啟, 若開(kāi)啟, 則執(zhí)行降級(jí)服務(wù)getFallback方法.

若熔斷器開(kāi)關(guān)關(guān)閉, 則Hystrix檢查當(dāng)前服務(wù)的線程池是否能接收新的請(qǐng)求, 若超過(guò)線程池已滿, 則執(zhí)行降級(jí)服務(wù)getFallback方法.

若線程池接受請(qǐng)求, 則Hystrix開(kāi)始執(zhí)行服務(wù)調(diào)用具體邏輯run方法.

若服務(wù)執(zhí)行失敗, 則執(zhí)行降級(jí)服務(wù)getFallback方法, 并將執(zhí)行結(jié)果上報(bào)Metrics更新服務(wù)健康狀況.

若服務(wù)執(zhí)行超時(shí), 則執(zhí)行降級(jí)服務(wù)getFallback方法, 并將執(zhí)行結(jié)果上報(bào)Metrics更新服務(wù)健康狀況.

若服務(wù)執(zhí)行成功, 返回正常結(jié)果.

若服務(wù)降級(jí)方法getFallback執(zhí)行成功, 則返回降級(jí)結(jié)果.

若服務(wù)降級(jí)方法getFallback執(zhí)行失敗, 則拋出異常.

六 ?Hystrix Metrics的實(shí)現(xiàn)

Hystrix的Metrics中保存了當(dāng)前服務(wù)的健康狀況, 包括服務(wù)調(diào)用總次數(shù)和服務(wù)調(diào)用失敗次數(shù)等.

根據(jù)Metrics的計(jì)數(shù), 熔斷器從而能計(jì)算出當(dāng)前服務(wù)的調(diào)用失敗率, 用來(lái)和設(shè)定的閾值比較從而決定熔斷器的狀態(tài)切換邏輯.

因此Metrics的實(shí)現(xiàn)非常重要.

6.1 之前的滑動(dòng)窗口實(shí)現(xiàn)

Hystrix在這些版本中的使用自己定義的滑動(dòng)窗口數(shù)據(jù)結(jié)構(gòu)來(lái)記錄當(dāng)前時(shí)間窗的各種事件(成功,失敗,超時(shí),線程池拒絕等)的計(jì)數(shù).?
事件產(chǎn)生時(shí), 數(shù)據(jù)結(jié)構(gòu)根據(jù)當(dāng)前時(shí)間確定使用舊桶還是創(chuàng)建新桶來(lái)計(jì)數(shù), 并在桶中對(duì)計(jì)數(shù)器經(jīng)行修改.?
這些修改是多線程并發(fā)執(zhí)行的, 代碼中有不少加鎖操作,邏輯較為復(fù)雜.

6.2 之后的滑動(dòng)窗口實(shí)現(xiàn)

Hystrix在這些版本中開(kāi)始使用RxJava的Observable.window()實(shí)現(xiàn)滑動(dòng)窗口.
RxJava的window使用后臺(tái)線程創(chuàng)建新桶, 避免了并發(fā)創(chuàng)建桶的問(wèn)題.
同時(shí)RxJava的單線程無(wú)鎖特性也保證了計(jì)數(shù)變更時(shí)的線程安全. 從而使代碼更加簡(jiǎn)潔.?
以下為我使用RxJava的window方法實(shí)現(xiàn)的一個(gè)簡(jiǎn)易滑動(dòng)窗口Metrics, 短短幾行代碼便能完成統(tǒng)計(jì)功能,足以證明RxJava的強(qiáng)大:

@Test public void timeWindowTest() throws Exception{ Observable<Integer> source = Observable.interval(50, TimeUnit.MILLISECONDS).map(i -> RandomUtils.nextInt(2)); source.window(1, TimeUnit.SECONDS).subscribe(window -> { int[] metrics = new int[2]; window.subscribe(i -> metrics[i]++, InternalObservableUtils.ERROR_NOT_IMPLEMENTED, () -> System.out.println("窗口Metrics:" + JSON.toJSONString(metrics))); }); TimeUnit.SECONDS.sleep(3); }

?

6.3 在spingCloud中如何使用hystrix

@FeignClient(value = "wsbs-fpcx", fallback = FpsjcxServiceHystric.class) public interface FpsjCxSchedualService {}

總結(jié)

通過(guò)使用Hystrix,我們能方便的防止雪崩效應(yīng), 同時(shí)使系統(tǒng)具有自動(dòng)降級(jí)和自動(dòng)恢復(fù)服務(wù)的效果.

?

疑問(wèn)：

疑問(wèn)一： 6.1 6.2 具體含義？?

?

?

參考：https://www.jianshu.com/p/3463571febc2

轉(zhuǎn)載于:https://www.cnblogs.com/xingzc/p/7511888.html

總結(jié)

以上是生活随笔為你收集整理的防雪崩利器：熔断器 Hystrix 的原理与使用的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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