技术选型：为什么要使用Sentinel？

Hystrix已经停止更新后，大部分的技术选型会转向Sentinel，也就是 Spring Cloud Alibaba 刚刚开源的，但是为什么我们要使用它呢，我们从 Sentinel 和 Hystrix 的对比入手

Hystrix 的关注点是在 隔离 和 熔断 为主的容错机制，超时或被熔断的调用会快速失败，并可以提供 fallback 机制

Sentinel 主要是以流量为切入点，从流量控制，熔断降级，系统负载保护等多个维度来帮助用户保护服务的稳定性

共同特性：

隔离设计

Hystrix 有两种隔离策略

• Hystrix 线程池隔离
  针对不同的资源分别创建不同的线程池，不同服务调用都发生在不同的线程池中，在线程池排队、超时等阻塞情况时可以快速失败，并可以提供 fallback 机制。线程池隔离的好处是隔离度比较高，可以针对某个资源的线程池去进行处理而不影响其它资源，但是代价就是线程上下文切换的 overhead 比较大，特别是对低延时的调用有比较大的影响。

• 信号量隔离
  Hystrix 的信号量隔离比较简单，无法对慢调用自动进行降级，只能等待客户端自己超时，因此仍然可能会出现级联阻塞的情况。
  它其实是一个计数器。一个请求进来就会减少一个信号，一个请求完成就会增加一个信号。信号量的调用是同步的，也就是说他会阻塞直到请求回来。所以他自身是不能实现超时的，因此这里的超时只能依靠协议的超时来做，否则是无法释放的。所以当此服务不对外部服务依赖同时自身没有大量的计算或者说经过这个服务的时间比较短，则非常适合信号量。

Sentinel

• 通过并发线程数模式的流量控制来提供信号量隔离功能
  这样的隔离非常轻量级，仅限制对某个资源调用的并发数，而不是显式地去创建线程池，所以不用担心线程切换的问题，并且结合基于响应时间的熔断降级模式，可以在不稳定资源的平均响应时间比较高的时候自动降级，防止过多的慢调用占满并发数，影响整个系统。

熔断降级对比

Sentinel 和 Hystrix 的熔断降级功能本质上都是基于熔断器模式。Sentinel 与 Hystrix 都支持基于异常比率的熔断降级，在调用达到一定量级并且失败比率达到设定的阈值时自动进行熔断，此时所有对该资源的调用都会被阻塞 ，直到过了指定的时间窗口后才启发性地恢复。

Sentinel 还支持基于平均响应时间的熔断降级，可以在服务响应时间持续飙高的时候自动熔断，拒绝掉更多的请求，直到一段时间后才恢复。这样可以防止调用非常慢造成级联阻塞的情况。

控制台：

Hystrix：
Hystrix 提供了实时监控的页面，可以看到 刚刚调用的api状态和断路状态等。
这个dashboard需要在项目中自己部署，具体的步骤从网上搜一搜有很多博客。

Sentinel：
Sentinel 提供一个轻量级的开源控制台，它提供机器发现以及健康情况管理、监控（单机和集群），规则管理和推送的功能。还有鉴权功能也是必不可少的

监控：簇点链路中会显示刚刚调用过的资源（单机实时），实时监控 汇总资源信息（集群聚合），实时监控仅存储5分钟以内的数据，如果需要持久化，需要通过调用实时监控接口定制

规则管理和推送主要是统一管理推送规则，可以实时更改规则
鉴权：默认的账户密码为 sentinel 可以通过参数设置

• -Dsentinel.dashboard.auth.username=sentinel 用于指定控制台的登录用户名为 sentinel；
• -Dsentinel.dashboard.auth.password=123456 用于指定控制台的登录密码为 123456；如果省略这两个参数，默认用户和密码均为 sentinel；
• -Dserver.servlet.session.timeout=7200 用于指定 Spring Boot 服务端 session 的过期时间，如 7200 表示 7200 秒；60m 表示 60 分钟，默认为 30 分钟；
• 也可以在 spring properties 中进行配置

其他的内容请查看官网：官网

Sentinel 的特性

Hystrix 主要是隔离和熔断，但是 Sentinel 侧重于

• 多样化的流量控制
• 熔断降级
• 系统负载保护
• 实时监控和控制台

下面我们仔细说明一下sentinel

流量控制

Sentinel 可以针对不同的调用关系，以不同的运行指标（如 QPS、并发调用数、系统负载等）为基准，对资源调用进行流量控制，将随机的请求调整成合适的形状。
Sentinel 支持多样化的流量整形策略，在 QPS 过高的时候可以自动将流量调整成合适的形状。常用的有：
流控效果：

• 快速失败：直接失败，抛异常

• Warm Up：根据 codeFactor （冷加载因子，默认 3） 的值，从阈值/codeFactor ，经过预热时长，才达到设置的QPS阈值
  假设：起始阈值为10/3 经过5秒后阈值逐渐升值到10

• 排队等待：匀速排队，让请求以均匀的速度通过，阈值类型必须设成QPS 否则无效，设置含义： /testA 每秒1次请求，超过的话就排队等待，等待的超时时间为20000毫秒严格控制了请求通过的时间间隔，同时堆积的请求将会排队，超过超时时长的请求直接被拒绝。

Sentinel 还支持基于调用关系的限流（也就是流控模式）
• 直接：api达到限流条件时，直接限流
• 关联：当关联的资源达到阈值时，就限流自己
• 链路：只记录指定链路上的流量（指定资源从入口资源进来的流量，如果达到阈值，就进行限流）【api级别的针对来源】

系统负载保护

Sentinel 同时提供系统维度的自适应保护能力。防止雪崩，是系统防护中重要的一环。当系统负载较高的时候，如果还持续让请求进入，可能会导致系统崩溃，无法响应。在集群环境下，网络负载均衡会把本应这台机器承载的流量转发到其它的机器上去。如果这个时候其它的机器也处在一个边缘状态的时候，这个增加的流量就会导致这台机器也崩溃，最后导致整个集群不可用。
针对这个情况，Sentinel 提供了对应的保护机制，让系统的入口流量和系统的负载达到一个平衡，保证系统在能力范围之内处理最多的请求。

可见的，相比于Hystrix来说，Sentinel 是当前转型的一个选择，毕竟长远来看 Hystrix已经停止更新，而且当前的Sentinel 适用程度也比 Hystrix相对好一些。