Sentinel VS Hystrix技術選型

一, Sentinel VS Hystrix

Sentinel 項目地址：

https://github.com/alibaba/Sentinel

Hystrix項目地址:

https://github.com/Netflix/Hystrix

2、整體說明

先來看一下 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 的關注點在於以隔離和熔斷爲主的容錯機制，超時或被熔斷的調用將會快速失敗，並能夠提供 fallback 機制。

而 Sentinel 的側重點在於：

• 多樣化的流量控制

• 熔斷降級

• 系統負載保護

• 實時監控和控制檯

能夠看到二者解決的問題仍是有比較大的不一樣的，下面咱們來具體對比一下。

3、共同特性

一、資源模型和執行模型上的對比

Hystrix 的資源模型設計上採用了命令模式，將對外部資源的調用和 fallback 邏輯封裝成一個命令對象（HystrixCommand/ HystrixObservableCommand），其底層的執行是基於 RxJava 實現的。每一個 Command 建立時都要指定 commandKey 和 groupKey（用於區分資源）以及對應的隔離策略（線程池隔離 or 信號量隔離）。線程池隔離模式下須要配置線程池對應的參數（線程池名稱、容量、排隊超時等），而後 Command 就會在指定的線程池按照指定的容錯策略執行；信號量隔離模式下須要配置最大併發數，執行 Command 時 Hystrix 就會限制其併發調用。

Sentinel 的設計則更爲簡單。相比 Hystrix Command 強依賴隔離規則，Sentinel 的資源定義與規則配置的耦合度更低。Hystrix 的 Command 強依賴於隔離規則配置的緣由是隔離規則會直接影響 Command 的執行。在執行的時候 Hystrix 會解析 Command 的隔離規則來建立 RxJava Scheduler 並在其上調度執行，如果線程池模式則 Scheduler 底層的線程池爲配置的線程池，如果信號量模式則簡單包裝成當前線程執行的 Scheduler。

而Sentinel則不同，開發的時候只須要考慮這個方法/代碼是否須要保護，置於用什麼來保護，能夠任什麼時候候動態實時的區修改。

從 0.1.1 版本開始，Sentinel 還支持基於註解的資源定義方式，能夠經過註解參數指定異常處理函數和 fallback 函數。Sentinel 提供多樣化的規則配置方式。除了直接經過 loadRules API 將規則註冊到內存態以外，用戶還能夠註冊各類外部數據源來提供動態的規則。用戶能夠根據系統當前的實時狀況去動態地變動規則配置，數據源會將變動推送至 Sentinel 並即時生效。

二、隔離設計上的對比

隔離是 Hystrix 的核心功能之一。Hystrix 提供兩種隔離策略：線程池隔離（Bulkhead Pattern）和信號量隔離，其中最推薦也是最經常使用的是線程池隔離。Hystrix 的線程池隔離針對不一樣的資源分別建立不一樣的線程池，不一樣服務調用都發生在不一樣的線程池中，在線程池排隊、超時等阻塞狀況時能夠快速失敗，並能夠提供 fallback 機制。線程池隔離的好處是隔離度比較高，能夠針對某個資源的線程池去進行處理而不影響其它資源，可是代價就是線程上下文切換的 overhead 比較大，特別是對低延時的調用有比較大的影響。

可是，實際狀況下，線程池隔離並無帶來很是多的好處。最直接的影響，就是會讓機器資源碎片化。考慮這樣一個常見的場景，在 Tomcat 之類的 Servlet 容器使用 Hystrix，自己 Tomcat 自身的線程數目就很是多了（可能到幾十或一百多），若是加上 Hystrix 爲各個資源建立的線程池，總共線程數目會很是多（幾百個線程），這樣上下文切換會有很是大的損耗。另外，線程池模式比較完全的隔離性使得 Hystrix 能夠針對不一樣資源線程池的排隊、超時狀況分別進行處理，但這實際上是超時熔斷和流量控制要解決的問題，若是組件具有了超時熔斷和流量控制的能力，線程池隔離就顯得沒有那麼必要了。

Hystrix 的信號量隔離限制對某個資源調用的併發數。這樣的隔離很是輕量級，僅限制對某個資源調用的併發數，而不是顯式地去建立線程池，因此 overhead 比較小，可是效果不錯。但缺點是沒法對慢調用自動進行降級，只能等待客戶端本身超時，所以仍然可能會出現級聯阻塞的狀況。

Sentinel 能夠經過併發線程數模式的流量控制來提供信號量隔離的功能。而且結合基於響應時間的熔斷降級模式，能夠在不穩定資源的平均響應時間比較高的時候自動降級，防止過多的慢調用佔滿併發數，影響整個系統。

三、熔斷降級的對比

Sentinel 和 Hystrix 的熔斷降級功能本質上都是基於熔斷器模式（Circuit Breaker Pattern）。Sentinel 與 Hystrix 都支持基於失敗比率（異常比率）的熔斷降級，在調用達到必定量級而且失敗比率達到設定的閾值時自動進行熔斷，此時全部對該資源的調用都會被 block，直到過了指定的時間窗口後才啓發性地恢復。上面提到過，Sentinel 還支持基於平均響應時間的熔斷降級，能夠在服務響應時間持續飆高的時候自動熔斷，拒絕掉更多的請求，直到一段時間後才恢復。這樣能夠防止調用很是慢形成級聯阻塞的狀況。

四、實時指標統計實現的對比

Hystrix 和 Sentinel 的實時指標數據統計實現都是基於滑動窗口的。Hystrix 1.5 以前的版本是經過環形數組實現的滑動窗口，經過鎖配合 CAS 的操做對每一個桶的統計信息進行更新。Hystrix 1.5 開始對實時指標統計的實現進行了重構，將指標統計數據結構抽象成了響應式流（reactive stream）的形式，方便消費者去利用指標信息。同時底層改形成了基於 RxJava 的事件驅動模式，在服務調用成功/失敗/超時的時候發佈相應的事件，經過一系列的變換和聚合最終獲得實時的指標統計數據流，能夠被熔斷器或 Dashboard 消費。

Sentinel 目前抽象出了 Metric 指標統計接口，底層能夠有不一樣的實現，目前默認的實現是基於 LeapArray 的滑動窗口，後續根據須要可能會引入 reactive stream 等實現。

4、Sentinel 特性

除了以前提到的二者的共同特性以外，Sentinel 還提供如下的特點功能：

一、輕量級、高性能

Sentinel 做爲一個功能完備的高可用流量管控組件，其核心 sentinel-core 沒有任何多餘依賴，打包後只有不到 200 KB，很是輕量級。開發者能夠放心地引入 sentinel-core 而不需擔憂依賴問題。同時，Sentinel 提供了多種擴展點，用戶能夠很方便地根據需求去進行擴展，而且無縫地切合到 Sentinel 中。

引入 Sentinel 帶來的性能損耗很是小。只有在業務單機量級超過 25W QPS 的時候纔會有一些顯著的影響（5% - 10% 左右），單機 QPS 不太大的時候損耗幾乎能夠忽略不計。

二、流量控制

Sentinel 能夠針對不一樣的調用關係，以不一樣的運行指標（如 QPS、併發調用數、系統負載等）爲基準，對資源調用進行流量控制，將隨機的請求調整成合適的形狀。

Sentinel 支持多樣化的流量整形策略，在 QPS 太高的時候能夠自動將流量調整成合適的形狀。經常使用的有：

• 直接拒絕模式：即超出的請求直接拒絕。

• 慢啓動預熱模式：當流量激增的時候，控制流量經過的速率，讓經過的流量緩慢增長，在必定時間內逐漸增長到閾值上限，給冷系統一個預熱的時間，避免冷系統被壓垮。

 

• 勻速器模式：利用 Leaky Bucket 算法實現的勻速模式，嚴格控制了請求經過的時間間隔，同時堆積的請求將會排隊，超過超時時長的請求直接被拒絕。Sentinel 還支持基於調用關係的限流，包括基於調用方限流、基於調用鏈入口限流、關聯流量限流等，依託於 Sentinel 強大的調用鏈路統計信息，能夠提供精準的不一樣維度的限流。

  目前 Sentinel 對異步調用鏈路的支持還不是很好，後續版本會着重改善支持異步調用。

三、系統負載保護

Sentinel 對系統的維度提供保護，負載保護算法借鑑了 TCP BBR 的思想。當系統負載較高的時候，若是仍持續讓請求進入，可能會致使系統崩潰，沒法響應。在集羣環境下，網絡負載均衡會把本應這臺機器承載的流量轉發到其它的機器上去。若是這個時候其它的機器也處在一個邊緣狀態的時候，這個增長的流量就會致使這臺機器也崩潰，最後致使整個集羣不可用。針對這個狀況，Sentinel 提供了對應的保護機制，讓系統的入口流量和系統的負載達到一個平衡，保證系統在能力範圍以內處理最多的請求。

 

四、實時監控和控制面板

Sentinel 提供 HTTP API 用於獲取實時的監控信息，如調用鏈路統計信息、簇點信息、規則信息等。若是用戶正在使用 Spring Boot/Spring Cloud 並使用了Sentinel Spring Cloud Starter，還能夠方便地經過其暴露的 Actuator Endpoint 來獲取運行時的一些信息，如動態規則等。將來 Sentinel 還會支持標準化的指標監控 API，能夠方便地整合各類監控系統和可視化系統，如 Prometheus、Grafana 等。

Sentinel控制檯（Dashboard）提供了機器發現、配置規則、查看實時監控、查看調用鏈路信息等功能，使得用戶能夠很是方便地去查看監控和進行配置。

五、生態

Sentinel 目前已經針對 Servlet、Dubbo、Spring Boot/Spring Cloud、gRPC 等進行了適配，用戶只需引入相應依賴並進行簡單配置便可很是方便地享受 Sentinel 的高可用流量防禦能力。將來 Sentinel 還會對更多經常使用框架進行適配，而且會爲 Service Mesh 提供集羣流量防禦的能力。

5、總結

轉載地址 : https://www.jianshu.com/p/d1f22a555065