javascript
Spring Cloud Alibaba 雪崩效应和容错解决方案
Spring Cloud Alibaba 雪崩效應(yīng)和容錯解決方案
文章目錄
- 1. 雪崩效應(yīng)
- 1.1. 舉個例子:
- 2. 常見的容錯方案:
- 2.1.超時:
- 2.2. 限流:
- 2.3. 倉壁模式:
- 2.3.1. 現(xiàn)實(shí)中的倉壁模式:
- 2.3.2. 軟件中的倉壁模式:
- 2.4. 斷路器模式
- 2.4.1. 現(xiàn)實(shí)中的斷路器:
- 2.4.2. 軟件中的斷路器:
1. 雪崩效應(yīng)
微服務(wù)架構(gòu)的系統(tǒng)包含很多微服務(wù),微服務(wù)之間通過輕量級的通信機(jī)制進(jìn)行通信,構(gòu)建成了一個完成的應(yīng)用系統(tǒng)。但是,每個微服務(wù)不能保證100%可用的,網(wǎng)絡(luò)呢?有時也會出問題
1.1. 舉個例子:
現(xiàn)在有一個高并發(fā)的應(yīng)用系統(tǒng)它包含4個微服務(wù),一開始每個微服務(wù)都是正常的,然后,在某一個時間點(diǎn),微服務(wù)A突然掛了,所有的實(shí)例都掛了,而這是一個高并發(fā)的應(yīng)用系統(tǒng).
B服務(wù)還在分光的調(diào)用A服務(wù)的API呢,現(xiàn)在A服務(wù)掛了,現(xiàn)在B服務(wù)發(fā)往A服務(wù)的請求,就會強(qiáng)制等待 ,直到請求超時,而在java程序里面,一個請求呢,往往對應(yīng)著一個線程,如果請求被強(qiáng)制等待,那么線程就會被強(qiáng)制阻塞,一直到請求超時的時候,這個線程才會被釋放,由于,這是一個高并發(fā)的應(yīng)用系統(tǒng),阻塞的線程就會越來越多,而線程對應(yīng)的服務(wù)器的計算資源,比方說內(nèi)存、cpu,如果不作任何處理的話,終有一天B服務(wù)所在的服務(wù)器,再也無法創(chuàng)建新的線程了,于是B服務(wù)也掛了。
簡言之,B服務(wù)是被A服務(wù)拖垮的,同樣的道理,C服務(wù)和D服務(wù)調(diào)用B服務(wù),C和D 也會被B服務(wù)拖垮,我們把基礎(chǔ)服務(wù)故障導(dǎo)致上層服務(wù)故障,并且這個故障不斷放大的過程,稱之為雪崩效應(yīng),這樣現(xiàn)象就像是滾雪球一樣越滾越大,最后整個服務(wù)可能都掛了,在一些英文書里面常常把雪崩效應(yīng)稱之為cascading failure 級聯(lián)失效 級聯(lián)故障。
2. 常見的容錯方案:
A服務(wù)掛了,B服務(wù)做好了容錯,就不會被A服務(wù)拖垮。
業(yè)界常使用的使用這些容錯方案,可以有效的避免雪崩效應(yīng)
2.1.超時:
比如說為每一次請求設(shè)置超時時間,假若為1s,不管這次請求會不會成功,這個線程就會被釋放,這樣只要線程釋放的速度夠快,那么,B服務(wù)就不會被A服務(wù)拖垮了
2.2. 限流:
在一個高并發(fā)的應(yīng)用系統(tǒng)中,采坑能存在大量的線程阻塞,如果我們經(jīng)過評估,發(fā)現(xiàn)微服務(wù)B的實(shí)例最大能夠承載的qps是1000,那么,我們就可以為微服務(wù)B設(shè)置一個限流的值,比方說是800qps,或者其他一個低于1000qps的閾值,這個時候,只要某一個實(shí)例達(dá)到這個閾值,再有流量進(jìn)來,就直接拒絕,通過這種方式,也實(shí)現(xiàn)了對自己的保護(hù),至少B服務(wù)不會被A服務(wù)拖到宕機(jī)。
2.3. 倉壁模式:
2.3.1. 現(xiàn)實(shí)中的倉壁模式:
泰坦尼克號,號稱永不沉沒的船,是基于技術(shù)而言的,用到了倉壁模式,一條船被劃分了3個船艙,每個船艙之間,用2塊鋼板焊死,即使,某一個船艙進(jìn)水也不會影響其他船艙,當(dāng)時,泰坦尼克號的設(shè)計能夠容納2個主倉的進(jìn)水船依然能夠正常工作,所謂主倉就是中間兩邊兩個比較大的倉。3個倉進(jìn)水了,超出了泰坦尼克號的容錯能力,于是,就悲劇了。
2.3.2. 軟件中的倉壁模式:
AController 有自己獨(dú)立的線程池,比方叫thread-pool-1 coreSize=10
調(diào)用其他API掛了,對于高并發(fā)的應(yīng)用,這個線程池就滿了,然后,去排隊,再然后就直接拒絕了,線程池大家應(yīng)該是很熟悉,線程池有自己的拒絕策略。
同理,BController 有自己獨(dú)立的線程池,比方叫thread-pool-2 coreSize=10,
此時,AController 線程池滿了或者拒絕了不會影響B(tài)Controller ,因?yàn)槎加凶约旱木€程池。
如果用船艙的例子類比的話,現(xiàn)在這2個Controller 就好比2個船艙,Controller 之間用2個獨(dú)立的線程池焊死,AController 類中的API調(diào)不通,就相當(dāng)于這個船倉進(jìn)水了,那么,你的船艙進(jìn)水和我的船艙沒有關(guān)系,這就是倉壁模式。
2.4. 斷路器模式
斷路器是服務(wù)容錯里面最高端的方案
2.4.1. 現(xiàn)實(shí)中的斷路器:
每個人家里都有斷路器,就是電閘。
斷路器說白了就是監(jiān)控加開關(guān),它會實(shí)時監(jiān)控電路的狀態(tài),但發(fā)現(xiàn)某段時間內(nèi),電流過大,他就認(rèn)為電路短路了,然后就會跳閘,從而保護(hù)電路不被燒毀。
2.4.2. 軟件中的斷路器:
舉個栗子:
比如說AController 中,調(diào)用API時,我監(jiān)控5s以內(nèi)的錯誤率、錯誤次數(shù)等等,如果錯誤率達(dá)到閾值又或者錯誤次數(shù)達(dá)到一定的閾值,我就認(rèn)為調(diào)用的服務(wù)已經(jīng)掛了,然后就跳閘,不去調(diào)用遠(yuǎn)程的api服務(wù)了。
正常狀態(tài)下,斷路器關(guān)閉
創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯,堅持創(chuàng)作打卡瓜分現(xiàn)金大獎總結(jié)
以上是生活随笔為你收集整理的Spring Cloud Alibaba 雪崩效应和容错解决方案的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: tomcat9 启动中提示 org.ap
- 下一篇: Spring概念理解