成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

高并發(fā)整體可用性:一文詳解降級(jí)、限流和熔斷

開發(fā) 架構(gòu)
本文希望可以用最通俗的解釋和貼切的實(shí)例來帶大家了解什么是限流、降級(jí)和熔斷。

 水滿則溢,月盈則虧,任何事物都不可能無限制的發(fā)展,我們的系統(tǒng)服務(wù)能力也一樣。

當(dāng)隨著流量的不斷增長(zhǎng),達(dá)到或超過服務(wù)本身的可承載范圍,系統(tǒng)服務(wù)的自我保護(hù)機(jī)制的建立就顯得很重要了。

本文希望可以用最通俗的解釋和貼切的實(shí)例來帶大家了解什么是限流、降級(jí)和熔斷。

Part1限流 - 自知之明和眼力見

一個(gè)是本身的承載能力,一個(gè)是依賴方的服務(wù)能力,其實(shí)都是從當(dāng)前系統(tǒng)的角度來說,

1.1自知之明之被動(dòng)限流

我只有這么大的能力,只能服務(wù)這么多客戶!

系統(tǒng)對(duì)自身的承載能力需要有一個(gè)清晰的認(rèn)識(shí),對(duì)于超過承載能力的額外調(diào)用,要適當(dāng)拒絕。

而怎樣衡量系統(tǒng)承載能力是一個(gè)問題。

一般的我們有兩種常見方案:一是定義閾值和規(guī)則,二是自適應(yīng)限流策略。

閾值和規(guī)則是owner通過對(duì)業(yè)務(wù)的把控和自身的存儲(chǔ)、連接的現(xiàn)狀,根據(jù)人工經(jīng)驗(yàn)制定的。這樣的策略一般不會(huì)出什么大問題,但是不夠靈活,對(duì)請(qǐng)求反饋的靈敏度和資源的利用率不夠。

相對(duì)的,自適應(yīng)策略則是一種動(dòng)態(tài)限流策略,是通過對(duì)系統(tǒng)當(dāng)前的運(yùn)行狀況,動(dòng)態(tài)的調(diào)整限流閾值,在機(jī)器資源和流量處理之間尋找一個(gè)平衡。

如阿里開源的Sentinel限流器,在動(dòng)態(tài)限流策略上支持[1]:

  •  Load 自適應(yīng):系統(tǒng)的 load1 作為啟發(fā)指標(biāo),進(jìn)行自適應(yīng)系統(tǒng)保護(hù)。當(dāng)系統(tǒng) load1 超過設(shè)定的啟發(fā)值,且系統(tǒng)當(dāng)前的并發(fā)線程數(shù)超過估算的系統(tǒng)容量時(shí)才會(huì)觸發(fā)系統(tǒng)保護(hù)。
  •  CPU usage:當(dāng)系統(tǒng) CPU 使用率超過閾值即觸發(fā)系統(tǒng)保護(hù)(取值范圍 0.0-1.0),比較靈敏。
  •  平均 RT:當(dāng)單臺(tái)機(jī)器上所有入口流量的平均 RT 達(dá)到閾值即觸發(fā)系統(tǒng)保護(hù),單位是毫秒。
  •  并發(fā)線程數(shù):當(dāng)單臺(tái)機(jī)器上所有入口流量的并發(fā)線程數(shù)達(dá)到閾值即觸發(fā)系統(tǒng)保護(hù)。
  •  入口 QPS:當(dāng)單臺(tái)機(jī)器上所有入口流量的 QPS 達(dá)到閾值即觸發(fā)系統(tǒng)保護(hù)。

1.2眼力見之主動(dòng)限流

合作方只有那么大的能力,我只能索取這么多!

對(duì)下游依賴系統(tǒng)的服務(wù)能力,需要有一個(gè)精準(zhǔn)的判斷,對(duì)于服務(wù)能力弱的下游系統(tǒng),要適當(dāng)減少調(diào)用,得有點(diǎn)眼力見,對(duì)不對(duì)。

因?yàn)椋^大部分的業(yè)務(wù)系統(tǒng)都不是單獨(dú)存在的,會(huì)依賴很多其他的系統(tǒng),這些依賴方的服務(wù)能力,就像是木桶短板,限制了當(dāng)前系統(tǒng)的處理能力。這個(gè)時(shí)候就需要把下游當(dāng)做一個(gè)整體來考慮。

因此,需要把集群限流和單機(jī)限流配合起來使用,特別是下游服務(wù)的實(shí)例數(shù)、服務(wù)能力等和當(dāng)前系統(tǒng)有較大差距的時(shí)候,集群限流還是必要的。

一種方案:是通過收集服務(wù)節(jié)點(diǎn)的請(qǐng)求日志,統(tǒng)計(jì)請(qǐng)求量,并通過限流配置,控制節(jié)點(diǎn)限流邏輯:

摘自:微服務(wù)治理:體系、架構(gòu)及實(shí)踐

我將其稱為后置限流,即收集各個(gè)節(jié)點(diǎn)的請(qǐng)求量和既定閾值對(duì)比,超過則反饋到各個(gè)節(jié)點(diǎn),依賴單機(jī)限流進(jìn)行比例限流。

另一種方案:是限流總控服務(wù),根據(jù)配置生產(chǎn)token,然后各個(gè)節(jié)點(diǎn)消費(fèi)token,正常獲取token后才能繼續(xù)業(yè)務(wù):

摘自:Sentinel

我將其稱為前置限流,預(yù)先確定分配好可用的token,省去了匯總和反饋的處理機(jī)制,相比而言,這種控制方式要相對(duì)精準(zhǔn)和優(yōu)雅。

1.3同步轉(zhuǎn)異步

合作方雖然能力有限,但態(tài)度很好,加班加點(diǎn)的處理;而我們的客戶也很友好,同意多等等

一個(gè)非常經(jīng)典的例子,就是第三方支付平臺(tái)的還款業(yè)務(wù),用過的同學(xué)應(yīng)該都有體會(huì),一般都是支付完成之后等一會(huì)才會(huì)收到銷賬的通知。

這個(gè)時(shí)延的底層邏輯是什么呢?

一般的,金融機(jī)構(gòu)的服務(wù)接口,因?yàn)槠鋽?shù)據(jù)一致性和系統(tǒng)穩(wěn)定性的要求,性能方面可能不如互聯(lián)網(wǎng)公司的系統(tǒng)。

那么,當(dāng)?shù)搅嗽鲁踉履┑倪€款高峰,如果把支持成功用戶的銷賬請(qǐng)求一股腦的都?jí)航o機(jī)構(gòu),后果可想而知。

但是,對(duì)于用戶來說,整個(gè)流程是可以被拆分的,用戶側(cè)只要完成支付操作就可以了。至于最終結(jié)果,可以允許延后被通知。

因此,基本上,金融網(wǎng)關(guān)在處理機(jī)構(gòu)銷賬都是異步的,即先將各業(yè)務(wù)的銷賬請(qǐng)求落地,然后異步的限速輪詢待處理的單據(jù),再和機(jī)構(gòu)交互。

其實(shí),不僅僅是在金融領(lǐng)域,只要我們的業(yè)務(wù)處理速度存在差異,且流程可以被拆分,即可考慮這種架構(gòu)思路,來緩解系統(tǒng)壓力,保障業(yè)務(wù)可用性。

Part2降級(jí) - 丟車保帥

事發(fā)突然,能力有限,我只能緊著幾個(gè)重要客戶服務(wù)!

那么,什么情況需要降級(jí),什么鏈路可以被降級(jí)呢?

當(dāng)整個(gè)業(yè)務(wù)處于高峰期,或活動(dòng)脈沖期,當(dāng)服務(wù)的負(fù)載很高,逼近了服務(wù)承載閾值,即可以考慮服務(wù)降級(jí)來保障主功能可用。

可以降級(jí)的一定是非核心的鏈路,比如網(wǎng)購場(chǎng)景下的積分抵扣,如果降級(jí)積分抵扣鏈路,其實(shí)不影響大部分的支付功能。

那么,在系統(tǒng)中我們一般采用的降級(jí)方案有哪些呢?

1、頁面降級(jí):即從用戶操作頁面進(jìn)行操作,直接限制和截?cái)嗄彻δ艿娜肟冢?/p>

從頁面入口對(duì)積分鏈路降級(jí)

如上圖所示,該業(yè)務(wù)場(chǎng)景下,是否使用積分,是在頁面渲染階段決定并返回給前段進(jìn)行頁面拼接的。

當(dāng)我們需要對(duì)其進(jìn)行降級(jí)時(shí),會(huì)通過控制平臺(tái)進(jìn)行降級(jí)開關(guān)切換,系統(tǒng)讀到降級(jí)開啟后,會(huì)返回前段積分降級(jí)的標(biāo)識(shí),前端將不再顯示積分抵扣入口。即從入口處截?cái)喾e分鏈路的執(zhí)行,達(dá)到降級(jí)的目的。

2、存儲(chǔ)降級(jí):使用緩存方式來降級(jí)頻繁操作的存儲(chǔ)

https://blog.csdn.net/di_ko/article/details/118058080

對(duì)于秒殺業(yè)務(wù)這種寫多讀少的場(chǎng)景,對(duì)DB的壓力是非常大的,一般的,我們會(huì)采用上圖所示的緩存架構(gòu),用緩存操作代替DB操作,用異步MQ代替同步接口,也屬于一種存儲(chǔ)的降級(jí)行為。

3、讀降級(jí):對(duì)于非核心信息的讀請(qǐng)求禁用

微信的搶紅包場(chǎng)景,紅包列表的展示屬于搶紅包的非核心鏈路,因此,對(duì)于列表展示,在業(yè)務(wù)壓力較大的情況下,對(duì)頭像等信息的讀,可以直接禁用。

4、寫降級(jí):直接禁止相關(guān)寫操作的服務(wù)請(qǐng)求

總結(jié),一句話概括降級(jí)的核心--丟車保帥。以損失部分體驗(yàn)的代價(jià),來換取整個(gè)業(yè)務(wù)鏈路的穩(wěn)定性和持續(xù)可用。

Part3熔斷- 大局觀

合作方遇到困難了,不能為了自己把人家逼上絕路,別把自己也拖垮!出于人道主義,還得時(shí)不時(shí)問詢下,Are you ok ?

熔斷機(jī)制之所以被我賦予大局觀的美稱,是因?yàn)槠渌鉀Q的問題是級(jí)聯(lián)故障和服務(wù)雪崩!

在分布式的環(huán)境下,異常是常態(tài)。如上圖所示,當(dāng)服務(wù)C出現(xiàn)調(diào)用異常時(shí),會(huì)在服務(wù)B中出現(xiàn)大量的請(qǐng)求超時(shí)和調(diào)用延遲。

這些調(diào)用也是需要占用系統(tǒng)資源的,當(dāng)大量請(qǐng)求積壓,服務(wù)B的線程池等資源也會(huì)隨之耗盡,最終導(dǎo)致整個(gè)服務(wù)鏈路的雪崩都是有可能的。

因此,當(dāng)服務(wù)C出現(xiàn)異常時(shí),對(duì)服務(wù)C的調(diào)用適當(dāng)暫停,同時(shí)不斷監(jiān)測(cè)其接口是否恢復(fù),對(duì)于整個(gè)鏈路的健康非常有必要的,上述針對(duì)C的處理過程就是熔斷。

Hystrix官方熔斷流程[2]

從上圖可以看到,熔斷操作的三個(gè)關(guān)鍵點(diǎn):

  •  熔斷算法,即什么情況即會(huì)被判定為需要熔斷
  •  熔斷后處理,即當(dāng)前系統(tǒng)不進(jìn)行遠(yuǎn)程調(diào)用,但調(diào)用結(jié)果需要有替代邏輯
  •  熔斷恢復(fù),適當(dāng)?shù)臋z測(cè)機(jī)制,用于結(jié)束熔斷,恢復(fù)正常服務(wù)調(diào)用。

之前在《在所依賴存儲(chǔ)不授信的場(chǎng)景下實(shí)現(xiàn)柔性事務(wù)降級(jí)》一文中提到過,我們的分布式事務(wù),會(huì)依賴底層存儲(chǔ)做元數(shù)據(jù)存儲(chǔ)和一致性校驗(yàn)。

但是底層存儲(chǔ)的穩(wěn)定性稍有不足,這里就涉及到了服務(wù)熔斷的處理:

  •  當(dāng)我們通過關(guān)鍵字監(jiān)控,檢測(cè)到底層存儲(chǔ)的操作異常操作某閾值時(shí),就會(huì)通過腳本觸發(fā)一個(gè)開關(guān)切換的操作。
  •  此開關(guān)打開的作用是,棄用底層存儲(chǔ),直接走兜底消息隊(duì)列,以保障絕大部分請(qǐng)求得以正常進(jìn)行。
  •  在開發(fā)開啟的時(shí)間段內(nèi),用試探線程去試探底層存儲(chǔ)是否恢復(fù),當(dāng)探測(cè)到存儲(chǔ)恢復(fù)正常時(shí),切換開關(guān)恢復(fù)到正常鏈路。(這一步目前還未實(shí)現(xiàn),用人工代替了) 

 

責(zé)任編輯:龐桂玉 來源: Coder的技術(shù)之路
相關(guān)推薦

2021-09-28 13:55:54

高并發(fā)限流架構(gòu)

2021-05-24 09:15:42

Go熔斷熔斷器

2021-10-06 19:01:45

高并發(fā)熔斷預(yù)熱

2020-12-21 06:13:52

高可用Nacos服務(wù)端

2021-08-20 11:05:14

高并發(fā)架構(gòu)分布式

2021-08-29 20:02:38

高并發(fā)集群部署

2010-12-31 14:36:15

ExchangeSer

2010-06-03 15:23:48

2013-08-28 10:30:39

vSphere

2012-09-04 13:43:31

SQL Server

2024-02-27 09:48:25

Redis集群數(shù)據(jù)庫

2014-07-31 14:25:53

2012-07-04 11:21:07

OpenStack

2011-08-25 15:42:49

2024-12-11 08:35:55

2024-11-29 16:02:17

2024-08-13 15:42:19

2010-08-24 15:20:45

Oracle

2018-07-11 09:34:55

分布式架構(gòu)高可用

2009-02-26 16:59:36

VMware虛擬化虛擬機(jī)
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)

主站蜘蛛池模板: 黄色国产在线视频 | 国产一区二区三区 | 亚洲国产aⅴ成人精品无吗 国产精品永久在线观看 | 免费在线观看黄视频 | 99精品一区二区 | 国产精品免费小视频 | 一级欧美一级日韩片免费观看 | 中文字幕亚洲视频 | 国产91在线播放精品91 | 人人鲁人人莫人人爱精品 | 免费在线观看一区二区三区 | 欧美成年人视频在线观看 | 日韩成人免费视频 | 日本大片在线播放 | 国产日韩一区 | 成人精品一区亚洲午夜久久久 | 国产日韩在线观看一区 | av毛片 | 综合色婷婷 | 久久精品欧美一区二区三区不卡 | 欧美日韩久久 | 欧美啪啪 | xx视频在线 | 欧美日韩久久精品 | 久热国产精品视频 | 日韩中文字幕一区 | 久久99精品国产自在现线小黄鸭 | 福利视频三区 | 国产精品视屏 | 国产一在线观看 | 欧美精品在线一区 | 国内精品免费久久久久软件老师 | 国产精品久久久久久一级毛片 | 黄片毛片免费看 | 成人片网址 | 日韩成人一区 | 亚洲精品一区二区三区在线 | 欧美日韩免费在线 | 久久久久久久av麻豆果冻 | 亚洲二区在线 | 国产一级电影在线 |