1、springCloudNetFlix 包含內(nèi)容
- 提供的模式包括服務(wù)發(fā)現(xiàn)（Eureka）
- 斷路器（Hystrix）
- 智能路由（Zuul）
- 客戶端負(fù)載平衡（Ribbon）。
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ù)提供者不可用
- 重試加大流量
- 服務(wù)調(diào)用者不可用
3.1 服務(wù)不可用
- 硬件故障
硬件故障可能為硬件損壞造成的服務(wù)器主機(jī)宕機(jī), 網(wǎng)絡(luò)硬件故障造成的服務(wù)提供者的不可訪問(wèn). - 程序Bug
- 緩存擊穿
緩存擊穿一般發(fā)生在緩存應(yīng)用重啟, 所有緩存被清空時(shí),以及短時(shí)間內(nèi)大量緩存失效時(shí). 大量的緩存不命中, 使請(qǐng)求直擊后端,造成服務(wù)提供者超負(fù)荷運(yùn)行,引起服務(wù)不可用. - 用戶大量請(qǐng)求
在秒殺和大促開(kāi)始前,如果準(zhǔn)備不充分,用戶發(fā)起大量請(qǐng)求也會(huì)造成服務(wù)提供者的不可用.
3.2 重試加大流量
- 用戶重試
在服務(wù)提供者不可用后, 用戶由于忍受不了界面上長(zhǎng)時(shí)間的等待,而不斷刷新頁(yè)面甚至提交表單. - 代碼邏輯重試
服務(wù)調(diào)用端的會(huì)存在大量服務(wù)異常后的重試邏輯.
3.3 服務(wù)調(diào)用者不可用
- 同步等待造成的資源耗盡
當(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ù)雪崩的對(duì)應(yīng)策略
4.1 應(yīng)對(duì)服務(wù)不可用
- 流量控制
- 改進(jìn)緩存模式
- 服務(wù)自動(dòng)擴(kuò)容
- 服務(wù)調(diào)用者降級(jí)服務(wù)
4.2 應(yīng)對(duì)流量控制
- 網(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ī)制.
4.3 改進(jìn)緩存模式
- 緩存預(yù)加載
- 同步改為異步刷新
4.4 服務(wù)自動(dòng)擴(kuò)容
- AWS的auto scaling
4.5 服務(wù)調(diào)用者降級(jí)服務(wù)
- 資源隔離 ： 資源隔離主要是對(duì)調(diào)用服務(wù)的線程池進(jìn)行隔離
- 對(duì)依賴(lài)服務(wù)進(jìn)行分類(lèi) ： 我們根據(jù)具體業(yè)務(wù),將依賴(lài)服務(wù)分為: 強(qiáng)依賴(lài)和若依賴(lài). 強(qiáng)依賴(lài)服務(wù)不可用會(huì)導(dǎo)致當(dāng)前業(yè)務(wù)中止,而弱依賴(lài)服務(wù)的不可用不會(huì)導(dǎo)致當(dāng)前業(yè)務(wù)的中止.
- 不可用服務(wù)的調(diào)用快速失敗 ： 不可用服務(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ò)的類(lèi)庫(kù), 它同樣擁有保護(hù)系統(tǒng)的能力.
5.1 Hystrix的設(shè)計(jì)原則包括:
- 資源隔離
- 熔斷器
- 命令模式
5.2 資源隔離
在一個(gè)高度服務(wù)化的系統(tǒng)中,我們實(shí)現(xiàn)的一個(gè)業(yè)務(wù)邏輯通常會(huì)依賴(lài)多個(gè)服務(wù),比如:
商品詳情展示服務(wù)會(huì)依賴(lài)商品服務(wù), 價(jià)格服務(wù), 商品評(píng)論服務(wù). 如圖所示:
調(diào)用三個(gè)依賴(lài)服務(wù)會(huì)共享商品詳情服務(wù)的線程池. 如果其中的商品評(píng)論服務(wù)不可用, 就會(huì)出現(xiàn)線程池里所有線程都因等待響應(yīng)而被阻塞, 從而造成服務(wù)雪崩. 如圖所示:
Hystrix通過(guò)將每個(gè)依賴(lài)服務(wù)分配獨(dú)立的線程池進(jìn)行資源隔離, 從而避免服務(wù)雪崩.
如下圖所示, 當(dāng)商品評(píng)論服務(wù)不可用時(shí), 即使商品服務(wù)獨(dú)立分配的20個(gè)線程全部處于同步等待狀態(tài),也不會(huì)影響其他依賴(lài)服務(wù)的調(diào)用.
5.3 熔斷器模式
熔斷器模式定義了熔斷器開(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.4、命令模式
Hystrix使用命令模式(繼承HystrixCommand類(lèi))來(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;
);
}
@Override
protected Response run(){
return service1.call(request);
}
@Override
protected Response getFallback(){
return Response.dummy();
}
}
在使用了Command模式構(gòu)建了服務(wù)對(duì)象之后, 服務(wù)便擁有了熔斷器和線程池的功能.
Hystrix的內(nèi)部處理邏輯
下圖為Hystrix服務(wù)調(diào)用的內(nèi)部邏輯:
1、構(gòu)建Hystrix的Command對(duì)象, 調(diào)用執(zhí)行方法.
2、Hystrix檢查當(dāng)前服務(wù)的熔斷器開(kāi)關(guān)是否開(kāi)啟, 若開(kāi)啟, 則執(zhí)行降級(jí)服務(wù)getFallback方法.
3、若熔斷器開(kāi)關(guān)關(guān)閉, 則Hystrix檢查當(dāng)前服務(wù)的線程池是否能接收新的請(qǐng)求, 若超過(guò)線程池已滿, 則執(zhí)行降級(jí)服務(wù)getFallback方法.
4、若線程池接受請(qǐng)求, 則Hystrix開(kāi)始執(zhí)行服務(wù)調(diào)用具體邏輯run方法.
5、若服務(wù)執(zhí)行失敗, 則執(zhí)行降級(jí)服務(wù)getFallback方法, 并將執(zhí)行結(jié)果上報(bào)Metrics更新服務(wù)健康狀況.
6、若服務(wù)執(zhí)行超時(shí), 則執(zhí)行降級(jí)服務(wù)getFallback方法, 并將執(zhí)行結(jié)果上報(bào)Metrics更新服務(wù)健康狀況.
7、若服務(wù)執(zhí)行成功, 返回正常結(jié)果.
8、若服務(wù)降級(jí)方法getFallback執(zhí)行成功, 則返回降級(jí)結(jié)果.
9、若服務(wù)降級(jí)方法getFallback執(zhí)行失敗, 則拋出異常.
6、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)非常重要.
1.4之前的滑動(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ù)雜.
1.5之后的滑動(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);
}
\
