1 基本介紹

Sentinel 和 Hystrix 的原則是一致的: 當(dāng)檢測(cè)到調(diào)用鏈路中某個(gè)資源出現(xiàn)不穩(wěn)定的表現(xiàn)，例如請(qǐng)求響應(yīng)時(shí)間長(zhǎng)或異常比例升高的時(shí)候，則對(duì)這個(gè)資源的調(diào)用進(jìn)行限制，讓請(qǐng)求快速失敗，避免影響到其它的資源而導(dǎo)致級(jí)聯(lián)故障。

Sentinel 對(duì)這個(gè)問題采取了兩種手段:

通過并發(fā)線程數(shù)進(jìn)行限制
和資源池隔離的方法不同，Sentinel 通過限制資源并發(fā)線程的數(shù)量，來減少不穩(wěn)定資源對(duì)其它資源的影響。這樣不但沒有線程切換的損耗，也不需要您預(yù)先分配線程池的大小。當(dāng)某個(gè)資源出現(xiàn)不穩(wěn)定的情況下，例如響應(yīng)時(shí)間變長(zhǎng)，對(duì)資源的直接影響就是會(huì)造成線程數(shù)的逐步堆積。當(dāng)線程數(shù)在特定資源上堆積到一定的數(shù)量之后，對(duì)該資源的新請(qǐng)求就會(huì)被拒絕。堆積的線程完成任務(wù)后才開始繼續(xù)接收請(qǐng)求。

針對(duì)慢調(diào)用和異常對(duì)資源進(jìn)行降級(jí)
除了對(duì)并發(fā)線程數(shù)進(jìn)行控制以外，Sentinel 還可以根據(jù)響應(yīng)時(shí)間和異常等不穩(wěn)定因素來快速對(duì)不穩(wěn)定的調(diào)用進(jìn)行熔斷。當(dāng)依賴的資源出現(xiàn)響應(yīng)時(shí)間過長(zhǎng)后，所有對(duì)該資源的訪問都會(huì)被直接拒絕，直到過了指定的時(shí)間窗口之后才重新漸進(jìn)式地恢復(fù)。

系統(tǒng)自適應(yīng)保護(hù)

Sentinel 同時(shí)提供系統(tǒng)維度的自適應(yīng)保護(hù)能力。防止雪崩，是系統(tǒng)防護(hù)中重要的一環(huán)。當(dāng)系統(tǒng)負(fù)載較高的時(shí)候，如果還持續(xù)讓請(qǐng)求進(jìn)入，可能會(huì)導(dǎo)致系統(tǒng)崩潰，無法響應(yīng)。在集群環(huán)境下，網(wǎng)絡(luò)負(fù)載均衡會(huì)把本應(yīng)這臺(tái)機(jī)器承載的流量轉(zhuǎn)發(fā)到其它的機(jī)器上去。如果這個(gè)時(shí)候其它的機(jī)器也處在一個(gè)邊緣狀態(tài)的時(shí)候，這個(gè)增加的流量就會(huì)導(dǎo)致這臺(tái)機(jī)器也崩潰，最后導(dǎo)致整個(gè)集群不可用。

針對(duì)這個(gè)情況，Sentinel 提供了對(duì)應(yīng)的保護(hù)機(jī)制，讓系統(tǒng)的入口流量和系統(tǒng)的負(fù)載達(dá)到一個(gè)平衡，保證系統(tǒng)在能力范圍之內(nèi)處理最多的請(qǐng)求。

而Hystrix內(nèi)部提供了兩種模式執(zhí)行邏輯：信號(hào)量、線程池。

2 Hystrix信號(hào)量和線程池區(qū)別

來自hystrix官網(wǎng)
默認(rèn)情況下，Hystrix使用線程池模式。
不過兩者有什么區(qū)別，在實(shí)際場(chǎng)景中如何選擇？

如果要使用信號(hào)量模式，需要配置參數(shù)execution.isolation.strategy =ExecutionIsolationStrategy.SEMAPHORE.

2.1 信號(hào)量模式

在該模式下，接收請(qǐng)求和執(zhí)行下游依賴在同一個(gè)線程內(nèi)完成，不存在線程上下文切換所帶來的性能開銷，所以大部分場(chǎng)景應(yīng)該選擇信號(hào)量模式，但是在下面這種情況下，信號(hào)量模式并非是一個(gè)好的選擇。

比如一個(gè)接口中依賴了3個(gè)下游：serviceA、serviceB、serviceC，且這3個(gè)服務(wù)返回的數(shù)據(jù)互相不依賴，這種情況下如果針對(duì)A、B、C的熔斷降級(jí)使用信號(hào)量模式，那么接口耗時(shí)就等于請(qǐng)求A、B、C服務(wù)耗時(shí)的總和，無疑這不是好的方案。

另外，為了限制對(duì)下游依賴的并發(fā)調(diào)用量，可以配置Hystrix的execution.isolation.semaphore.maxConcurrentRequests，當(dāng)并發(fā)請(qǐng)求數(shù)達(dá)到閾值時(shí)，請(qǐng)求線程可以快速失敗，執(zhí)行降級(jí)。

實(shí)現(xiàn)也很簡(jiǎn)單，一個(gè)簡(jiǎn)單的計(jì)數(shù)器，當(dāng)請(qǐng)求進(jìn)入熔斷器時(shí)，執(zhí)行tryAcquire(),計(jì)數(shù)器加1，結(jié)果大于閾值的話，就返回false，發(fā)生信號(hào)量拒絕事件，執(zhí)行降級(jí)邏輯。當(dāng)請(qǐng)求離開熔斷器時(shí)，執(zhí)行release()，計(jì)數(shù)器減1。

2.2 線程池模式

在該模式下，用戶請(qǐng)求會(huì)被提交到各自的線程池中執(zhí)行，把執(zhí)行每個(gè)下游服務(wù)的線程分離，從而達(dá)到資源隔離的作用。當(dāng)線程池來不及處理并且請(qǐng)求隊(duì)列塞滿時(shí)，新進(jìn)來的請(qǐng)求將快速失敗，可以避免依賴問題擴(kuò)散。

在信號(hào)量模式提到的問題，對(duì)所依賴的多個(gè)下游服務(wù)，通過線程池的異步執(zhí)行，可以有效的提高接口性能。

優(yōu)勢(shì)

• 減少所依賴服務(wù)發(fā)生故障時(shí)的影響面，比如ServiceA服務(wù)發(fā)生異常，導(dǎo)致請(qǐng)求大量超時(shí)，對(duì)應(yīng)的線程池被打滿，這時(shí)并不影響ServiceB、ServiceC的調(diào)用。
• 如果接口性能有變動(dòng)，可以方便的動(dòng)態(tài)調(diào)整線程池的參數(shù)或者是超時(shí)時(shí)間，前提是Hystrix參數(shù)實(shí)現(xiàn)了動(dòng)態(tài)調(diào)整。

缺點(diǎn)

• 請(qǐng)求在線程池中執(zhí)行，肯定會(huì)帶來任務(wù)調(diào)度、排隊(duì)和上下文切換帶來的開銷。
• 因?yàn)樯婕暗娇缇€程，那么就存在ThreadLocal數(shù)據(jù)的傳遞問題，比如在主線程初始化的ThreadLocal變量，在線程池線程中無法獲取

2.3 注意

因?yàn)镠ystrix默認(rèn)使用了線程池模式，所以對(duì)于每個(gè)Command，在初始化的時(shí)候，會(huì)創(chuàng)建一個(gè)對(duì)應(yīng)的線程池，如果項(xiàng)目中需要進(jìn)行降級(jí)的接口非常多，比如有上百個(gè)的話，不太了解Hystrix內(nèi)部機(jī)制的同學(xué)，按照默認(rèn)配置直接使用，可能就會(huì)造成線程資源的大量浪費(fèi)。

3 Sentinel介紹

Spring cloud Alibaba Sentinel：https://blog.csdn.net/ZGL_cyy/article/details/130874410

SpringCloud Sentinel實(shí)戰(zhàn)限流熔斷降級(jí)應(yīng)用：https://blog.csdn.net/ZGL_cyy/article/details/130874410

SpringCloud Sentinel集成Gateway和實(shí)時(shí)監(jiān):https://blog.csdn.net/ZGL_cyy/article/details/130874653文章來源地址http://www.zghlxwxcb.cn/news/detail-705732.html

到了這里，關(guān)于Hystrix和Sentinel熔斷降級(jí)設(shè)計(jì)理念的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！