這是圍繞 Sentinel 的使用場(chǎng)景、技術(shù)對(duì)比和實(shí)現(xiàn)、開(kāi)發(fā)者實(shí)踐等維度推出的系列文章的第三篇。

? 第一篇回顧：

Dubbo 的流量防衛(wèi)兵 | Sentinel如何通過(guò)限流實(shí)現(xiàn)服務(wù)的高可用性 -?傳送門(mén)

? 第二篇回顧：

RocketMQ 的保險(xiǎn)絲| Sentinel 如何通過(guò)勻速請(qǐng)求和冷啟動(dòng)來(lái)保障服務(wù)的穩(wěn)定性 -?傳送門(mén)

Sentinel 是阿里中間件團(tuán)隊(duì)研發(fā)的面向分布式服務(wù)架構(gòu)的輕量級(jí)高可用流量控制組件，于今年7月正式開(kāi)源。Sentinel 主要以流量為切入點(diǎn)，從流量控制、熔斷降級(jí)、系統(tǒng)負(fù)載保護(hù)等多個(gè)維度來(lái)幫助用戶提升服務(wù)的穩(wěn)定性。大家可能會(huì)問(wèn)：Sentinel 和之前經(jīng)常用到的熔斷降級(jí)庫(kù) Netflix Hystrix 有什么異同呢？本文將從資源模型和執(zhí)行模型、隔離設(shè)計(jì)、熔斷降級(jí)、實(shí)時(shí)指標(biāo)統(tǒng)計(jì)設(shè)計(jì)等角度將 Sentinel 和 Hystrix 進(jìn)行對(duì)比，希望在面臨技術(shù)選型的時(shí)候，對(duì)各位開(kāi)發(fā)者能有所幫助。

一、總體說(shuō)明

先來(lái)看一下 Hystrix 的官方介紹：

Hystrix is a library that helps you control the interactions between these distributed services by adding latency tolerance and fault tolerance logic. Hystrix does this by isolating points of access between the services, stopping cascading failures across them, and providing fallback options, all of which improve your system’s overall resiliency.

可以看到 Hystrix 的關(guān)注點(diǎn)在于以隔離和熔斷為主的容錯(cuò)機(jī)制，超時(shí)或被熔斷的調(diào)用將會(huì)快速失敗，并可以提供 fallback 機(jī)制。

而 Sentinel 的側(cè)重點(diǎn)在于：

• 多樣化的流量控制
• 熔斷降級(jí)
• 系統(tǒng)負(fù)載保護(hù)
• 實(shí)時(shí)監(jiān)控和控制臺(tái)

可以看到兩者解決的問(wèn)題還是有比較大的不同的，下面我們來(lái)具體對(duì)比一下。

二、共同特性

1、資源模型和執(zhí)行模型上的對(duì)比

Hystrix 的資源模型設(shè)計(jì)上采用了命令模式，將對(duì)外部資源的調(diào)用和 fallback 邏輯封裝成一個(gè)命令對(duì)象（HystrixCommand/ HystrixObservableCommand），其底層的執(zhí)行是基于 RxJava 實(shí)現(xiàn)的。每個(gè) Command 創(chuàng)建時(shí)都要指定 commandKey 和 groupKey（用于區(qū)分資源）以及對(duì)應(yīng)的隔離策略（線程池隔離 or 信號(hào)量隔離）。線程池隔離模式下需要配置線程池對(duì)應(yīng)的參數(shù)（線程池名稱、容量、排隊(duì)超時(shí)等），然后 Command 就會(huì)在指定的線程池按照指定的容錯(cuò)策略執(zhí)行；信號(hào)量隔離模式下需要配置最大并發(fā)數(shù)，執(zhí)行 Command 時(shí) Hystrix 就會(huì)限制其并發(fā)調(diào)用。

Sentinel 的設(shè)計(jì)則更為簡(jiǎn)單。相比 Hystrix Command 強(qiáng)依賴隔離規(guī)則，Sentinel 的資源定義與規(guī)則配置的耦合度更低。Hystrix 的 Command 強(qiáng)依賴于隔離規(guī)則配置的原因是隔離規(guī)則會(huì)直接影響 Command 的執(zhí)行。在執(zhí)行的時(shí)候 Hystrix 會(huì)解析 Command 的隔離規(guī)則來(lái)創(chuàng)建 RxJava Scheduler 并在其上調(diào)度執(zhí)行，若是線程池模式則 Scheduler 底層的線程池為配置的線程池，若是信號(hào)量模式則簡(jiǎn)單包裝成當(dāng)前線程執(zhí)行的 Scheduler。

而Sentinel則不一樣，開(kāi)發(fā)的時(shí)候只需要考慮這個(gè)方法/代碼是否需要保護(hù)，置于用什么來(lái)保護(hù)，可以任何時(shí)候動(dòng)態(tài)實(shí)時(shí)的區(qū)修改。

從 0.1.1 版本開(kāi)始，Sentinel 還支持基于注解的資源定義方式，可以通過(guò)注解參數(shù)指定異常處理函數(shù)和 fallback 函數(shù)。Sentinel 提供多樣化的規(guī)則配置方式。除了直接通過(guò) loadRules API 將規(guī)則注冊(cè)到內(nèi)存態(tài)之外，用戶還可以注冊(cè)各種外部數(shù)據(jù)源來(lái)提供動(dòng)態(tài)的規(guī)則。用戶可以根據(jù)系統(tǒng)當(dāng)前的實(shí)時(shí)情況去動(dòng)態(tài)地變更規(guī)則配置，數(shù)據(jù)源會(huì)將變更推送至 Sentinel 并即時(shí)生效。

2、隔離設(shè)計(jì)上的對(duì)比

隔離是 Hystrix 的核心功能之一。Hystrix 提供兩種隔離策略：線程池隔離（Bulkhead Pattern）和信號(hào)量隔離，其中最推薦也是最常用的是線程池隔離。Hystrix 的線程池隔離針對(duì)不同的資源分別創(chuàng)建不同的線程池，不同服務(wù)調(diào)用都發(fā)生在不同的線程池中，在線程池排隊(duì)、超時(shí)等阻塞情況時(shí)可以快速失敗，并可以提供 fallback 機(jī)制。線程池隔離的好處是隔離度比較高，可以針對(duì)某個(gè)資源的線程池去進(jìn)行處理而不影響其它資源，但是代價(jià)就是線程上下文切換的 overhead 比較大，特別是對(duì)低延時(shí)的調(diào)用有比較大的影響。

但是，實(shí)際情況下，線程池隔離并沒(méi)有帶來(lái)非常多的好處。最直接的影響，就是會(huì)讓機(jī)器資源碎片化。考慮這樣一個(gè)常見(jiàn)的場(chǎng)景，在 Tomcat 之類的 Servlet 容器使用 Hystrix，本身 Tomcat 自身的線程數(shù)目就非常多了（可能到幾十或一百多），如果加上 Hystrix 為各個(gè)資源創(chuàng)建的線程池，總共線程數(shù)目會(huì)非常多（幾百個(gè)線程），這樣上下文切換會(huì)有非常大的損耗。另外，線程池模式比較徹底的隔離性使得 Hystrix 可以針對(duì)不同資源線程池的排隊(duì)、超時(shí)情況分別進(jìn)行處理，但這其實(shí)是超時(shí)熔斷和流量控制要解決的問(wèn)題，如果組件具備了超時(shí)熔斷和流量控制的能力，線程池隔離就顯得沒(méi)有那么必要了。

Hystrix 的信號(hào)量隔離限制對(duì)某個(gè)資源調(diào)用的并發(fā)數(shù)。這樣的隔離非常輕量級(jí)，僅限制對(duì)某個(gè)資源調(diào)用的并發(fā)數(shù)，而不是顯式地去創(chuàng)建線程池，所以 overhead 比較小，但是效果不錯(cuò)。但缺點(diǎn)是無(wú)法對(duì)慢調(diào)用自動(dòng)進(jìn)行降級(jí)，只能等待客戶端自己超時(shí)，因此仍然可能會(huì)出現(xiàn)級(jí)聯(lián)阻塞的情況。

Sentinel 可以通過(guò)并發(fā)線程數(shù)模式的流量控制來(lái)提供信號(hào)量隔離的功能。并且結(jié)合基于響應(yīng)時(shí)間的熔斷降級(jí)模式，可以在不穩(wěn)定資源的平均響應(yīng)時(shí)間比較高的時(shí)候自動(dòng)降級(jí)，防止過(guò)多的慢調(diào)用占滿并發(fā)數(shù)，影響整個(gè)系統(tǒng)。

3、熔斷降級(jí)的對(duì)比

Sentinel 和 Hystrix 的熔斷降級(jí)功能本質(zhì)上都是基于熔斷器模式（Circuit Breaker Pattern）。Sentinel 與 Hystrix 都支持基于失敗比率（異常比率）的熔斷降級(jí)，在調(diào)用達(dá)到一定量級(jí)并且失敗比率達(dá)到設(shè)定的閾值時(shí)自動(dòng)進(jìn)行熔斷，此時(shí)所有對(duì)該資源的調(diào)用都會(huì)被 block，直到過(guò)了指定的時(shí)間窗口后才啟發(fā)性地恢復(fù)。上面提到過(guò)，Sentinel 還支持基于平均響應(yīng)時(shí)間的熔斷降級(jí)，可以在服務(wù)響應(yīng)時(shí)間持續(xù)飆高的時(shí)候自動(dòng)熔斷，拒絕掉更多的請(qǐng)求，直到一段時(shí)間后才恢復(fù)。這樣可以防止調(diào)用非常慢造成級(jí)聯(lián)阻塞的情況。

4、實(shí)時(shí)指標(biāo)統(tǒng)計(jì)實(shí)現(xiàn)的對(duì)比

Hystrix 和 Sentinel 的實(shí)時(shí)指標(biāo)數(shù)據(jù)統(tǒng)計(jì)實(shí)現(xiàn)都是基于滑動(dòng)窗口的。Hystrix 1.5 之前的版本是通過(guò)環(huán)形數(shù)組實(shí)現(xiàn)的滑動(dòng)窗口，通過(guò)鎖配合 CAS 的操作對(duì)每個(gè)桶的統(tǒng)計(jì)信息進(jìn)行更新。Hystrix 1.5 開(kāi)始對(duì)實(shí)時(shí)指標(biāo)統(tǒng)計(jì)的實(shí)現(xiàn)進(jìn)行了重構(gòu)，將指標(biāo)統(tǒng)計(jì)數(shù)據(jù)結(jié)構(gòu)抽象成了響應(yīng)式流（reactive stream）的形式，方便消費(fèi)者去利用指標(biāo)信息。同時(shí)底層改造成了基于 RxJava 的事件驅(qū)動(dòng)模式，在服務(wù)調(diào)用成功/失敗/超時(shí)的時(shí)候發(fā)布相應(yīng)的事件，通過(guò)一系列的變換和聚合最終得到實(shí)時(shí)的指標(biāo)統(tǒng)計(jì)數(shù)據(jù)流，可以被熔斷器或 Dashboard 消費(fèi)。

Sentinel 目前抽象出了 Metric 指標(biāo)統(tǒng)計(jì)接口，底層可以有不同的實(shí)現(xiàn)，目前默認(rèn)的實(shí)現(xiàn)是基于 LeapArray 的滑動(dòng)窗口，后續(xù)根據(jù)需要可能會(huì)引入 reactive stream 等實(shí)現(xiàn)。

三、Sentinel 特性

除了之前提到的兩者的共同特性之外，Sentinel 還提供以下的特色功能：

1、輕量級(jí)和高性能

Sentinel 作為一個(gè)功能完備的高可用流量管控組件，其核心 sentinel-core 沒(méi)有任何多余依賴，打包后只有不到 200 KB，非常輕量級(jí)。開(kāi)發(fā)者可以放心地引入 sentinel-core 而不需擔(dān)心依賴問(wèn)題。同時(shí)，Sentinel 提供了多種擴(kuò)展點(diǎn)，用戶可以很方便地根據(jù)需求去進(jìn)行擴(kuò)展，并且無(wú)縫地切合到 Sentinel 中。

引入 Sentinel 帶來(lái)的性能損耗非常小。只有在業(yè)務(wù)單機(jī)量級(jí)超過(guò) 25W QPS 的時(shí)候才會(huì)有一些顯著的影響（5% - 10% 左右），單機(jī) QPS 不太大的時(shí)候損耗幾乎可以忽略不計(jì)。

2、流量控制

Sentinel 可以針對(duì)不同的調(diào)用關(guān)系，以不同的運(yùn)行指標(biāo)（如 QPS、并發(fā)調(diào)用數(shù)、系統(tǒng)負(fù)載等）為基準(zhǔn)，對(duì)資源調(diào)用進(jìn)行流量控制，將隨機(jī)的請(qǐng)求調(diào)整成合適的形狀。

Sentinel 支持多樣化的流量整形策略，在 QPS 過(guò)高的時(shí)候可以自動(dòng)將流量調(diào)整成合適的形狀。常用的有：

• 直接拒絕模式：即超出的請(qǐng)求直接拒絕。
• 慢啟動(dòng)預(yù)熱模式：當(dāng)流量激增的時(shí)候，控制流量通過(guò)的速率，讓通過(guò)的流量緩慢增加，在一定時(shí)間內(nèi)逐漸增加到閾值上限，給冷系統(tǒng)一個(gè)預(yù)熱的時(shí)間，避免冷系統(tǒng)被壓垮。

• 勻速器模式：利用 Leaky Bucket 算法實(shí)現(xiàn)的勻速模式，嚴(yán)格控制了請(qǐng)求通過(guò)的時(shí)間間隔，同時(shí)堆積的請(qǐng)求將會(huì)排隊(duì)，超過(guò)超時(shí)時(shí)長(zhǎng)的請(qǐng)求直接被拒絕。Sentinel 還支持基于調(diào)用關(guān)系的限流，包括基于調(diào)用方限流、基于調(diào)用鏈入口限流、關(guān)聯(lián)流量限流等，依托于 Sentinel 強(qiáng)大的調(diào)用鏈路統(tǒng)計(jì)信息，可以提供精準(zhǔn)的不同維度的限流。

目前 Sentinel 對(duì)異步調(diào)用鏈路的支持還不是很好，后續(xù)版本會(huì)著重改善支持異步調(diào)用。

3、系統(tǒng)負(fù)載保護(hù)

Sentinel 對(duì)系統(tǒng)的維度提供保護(hù)，負(fù)載保護(hù)算法借鑒了 TCP BBR 的思想。當(dāng)系統(tǒng)負(fù)載較高的時(shí)候，如果仍持續(xù)讓請(qǐng)求進(jìn)入，可能會(huì)導(dǎo)致系統(tǒng)崩潰，無(wú)法響應(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)求。

4、實(shí)時(shí)監(jiān)控和控制面板

Sentinel 提供 HTTP API 用于獲取實(shí)時(shí)的監(jiān)控信息，如調(diào)用鏈路統(tǒng)計(jì)信息、簇點(diǎn)信息、規(guī)則信息等。如果用戶正在使用 Spring Boot/Spring Cloud 并使用了Sentinel Spring Cloud Starter，還可以方便地通過(guò)其暴露的 Actuator Endpoint 來(lái)獲取運(yùn)行時(shí)的一些信息，如動(dòng)態(tài)規(guī)則等。未來(lái) Sentinel 還會(huì)支持標(biāo)準(zhǔn)化的指標(biāo)監(jiān)控 API，可以方便地整合各種監(jiān)控系統(tǒng)和可視化系統(tǒng)，如 Prometheus、Grafana 等。

Sentinel控制臺(tái)（Dashboard）提供了機(jī)器發(fā)現(xiàn)、配置規(guī)則、查看實(shí)時(shí)監(jiān)控、查看調(diào)用鏈路信息等功能，使得用戶可以非常方便地去查看監(jiān)控和進(jìn)行配置。

5、生態(tài)

Sentinel 目前已經(jīng)針對(duì) Servlet、Dubbo、Spring Boot/Spring Cloud、gRPC 等進(jìn)行了適配，用戶只需引入相應(yīng)依賴并進(jìn)行簡(jiǎn)單配置即可非常方便地享受 Sentinel 的高可用流量防護(hù)能力。未來(lái) Sentinel 還會(huì)對(duì)更多常用框架進(jìn)行適配，并且會(huì)為 Service Mesh 提供集群流量防護(hù)的能力。

四、總結(jié)

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的技术选型：Sentinel vs Hystrix的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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