Sentinel VS Hystrix技术选型
一, Sentinel VS Hystrixreact
Sentinel 项目地址：git
https://github.com/alibaba/Sentinelgithub
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、总结