关于java:Sentinel-vs-Hystrix-限流对比到底怎么选

Sentinel 是阿里中间件团队开源的，面向分布式服务架构的轻量级高可用流量管制组件，次要以流量为切入点，从流量管制、熔断降级、零碎负载爱护等多个维度来帮忙用户爱护服务的稳定性。

大家可能会问：Sentinel 和之前罕用的熔断降级库 Netflix Hystrix 有什么异同呢？

本文将从多个角度对 Sentinel 和 Hystrix 进行比照，帮忙大家进行技术选型。

Overview

先来看一下 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 的侧重点在于：

• 多样化的流量管制
• 熔断降级
• 零碎负载爱护
• 实时监控和控制台

能够看到两者解决的问题还是有比拟大的不同的，上面咱们来别离比照一下。

独特个性

资源模型和执行模型上的比照

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 并不指定执行模型，也不关注利用是如何执行的。Sentinel 的准则非常简单：依据对应资源配置的规定来为资源执行相应的限流 / 降级 / 负载爱护策略。在 Sentinel 中资源定义和规定配置是拆散的。用户先通过 Sentinel API 给对应的业务逻辑定义资源（埋点），而后能够在须要的时候配置规定。埋点形式有两种：

• try-catch 形式（通过 SphU.entry(...)），用户在 catch 块中执行异样解决 / fallback
• if-else 形式（通过 SphO.entry(...)），当返回 false 时执行异样解决 / fallback

从 0.1.1 版本开始，Sentinel 还反对基于注解的资源定义形式，能够通过注解参数指定异样处理函数和 fallback 函数。

从 0.2.0 版本开始，Sentinel 引入异步调用链路反对，能够不便地统计异步调用资源的数据，保护异步调用链路，同时具备了适配异步框架 / 库的能力。

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 等实现。

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 0.2.0 开始反对 热点参数限流，可能实时的统计热点参数并针对热点参数的资源调用进行流量管制。

零碎负载爱护

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 提供集群流量防护的能力。

总结

最初用表格来进行比照总结：

参考：https://github.com/alibaba/Se…

近期热文举荐：

1.1,000+ 道 Java 面试题及答案整顿(2022 最新版)

2. 劲爆！Java 协程要来了。。。

3.Spring Boot 2.x 教程，太全了！

4. 别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！

5.《Java 开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞 + 转发哦！