Sentinel也就是我们之前的Hystrix，而且比Hystrix功能更加的强大。Sentinel是分布式系统的流量防卫兵，以流量为切入点，从流量控制、流量路由、熔断降级等多个维度保护服务的稳定性。
Sentinel采用的是懒加载，这个接口被访问一次，才会被Sentinel监测到加到簇点链路中。
1.流控规则
阈值类型：
QPS设置的是每秒 的请求数达到一定阈值，是将请求拦在外面判断处理的。
并发线程数设置的是后台处理请求的线程数量 ，是将请求都放进来判断处理的。
1.1流控模式
1.1.1流控模式------直接
哪个接口配置了就直接对此接口生效即可，没什么好说的。
1.1.2流控模式------关联
当关联的资源(接口)达到阈值时，就限流自己，比如配置的资源为testA，关联的资源为testB，如果说testB达到阈值了，testA就会被限流。实际的运用场景就是订单调用支付服务，如果支付服务过载了，那么限流一下订单服务就会比较好，能缓解很大的压力。
1.1.3流控模式------链路
多个不同的请求调用同一个接口时，接口可以配置统计从某个入口资源的请求访问数量，如果超额，则此接口限流，整个链路就相当于断了。
1.2流控效果
1.2.1快速失败
超过阈值直接失败，返回Blocked by Sentinel (flow limiting)
1.2.2预热
当突然有多个请求 同时过来时，可采用预热。预热中有一个冷因子默认为3，此时如果我们配置的单机阈值为10，预热时长为5，表明刚开始的请求最大限度为10/3=3，超过则会快速失败，需要慢慢预热，等到5s之后，才会升至稳定的阈值10。
Sentinel也就是我们之前的Hystrix，而且比Hystrix功能更加的强大。Sentinel是分布式系统的流量防卫兵，以流量为切入点，从流量控制、流量路由、熔断降级等多个维度保护服务的稳定性。
Sentinel采用的是懒加载，这个接口被访问一次，才会被Sentinel监测到加到簇点链路中。
1.2.3排队等待
阈值类型必须设置为QPS，否则无效，我们设置单机阈值为1，超时时间为20000ms，意思时每一秒只能处理一个请求，多余请求的不会丢弃，而是去排队等待，等待的超时时间为20000ms。
2.降级规则
这里演示的是通过哪些方式可以发生熔断来触发sentinel自带的降级。
注意：Sentinel的断路器是没有半开的状态的。
2.1RT
RT是指平均响应时间，当1s(统计时长)内涌入超过5个请求(最小请求数)，如果对应的响应时间超过了设置的阈值(最大RT)，熔断器打开，那么在接下来的时间窗口(熔断时长)内，对这个接口的调用都会触发降级返回，窗口时间过去后，熔断器就会自动关闭。
2.2异常比例
当1s内(统计时长)涌入超过5个请求(最小请求数)，并且每秒的异常比例超过阈值(比例阈值)之后，就会进入熔断，在接下来的时间窗口内，对这个方法的调用会直接降级返回。如果不满足熔断条件，普通调用如果出异常直接报错。
2.3异常数
当1分钟内(统计时长)涌入超过5个请求(最小请求数)，并且1分钟内的异常次数超过阈值(异常数)之后，就会进入熔断，在接下来的时间窗口内，对这个方法的调用会直接降级返回。如果不满足熔断条件，普通调用如果出异常直接报错。
3.Sentinel热点key配置
@SentinelResource注解就是我们之前使用的@HystrixCommand方法，基本相似。
虽然我们经常访问的是同一个接口，比如查询接口，但是由于查询的数据不同，传入的参数也就不同，所以我们可以将一些热门的键 和参数值 进行限流配置，用blockHandler来定义限流访问时我们自己的兜底方法，但是注意这个兜底方法与之前Hystrix中方法中出现的超时、异常等等的兜底方法不一样，它只负责热点的限流兜底，Hystrix那个得用fallback~~。
fallback管运行异常，blockHandler管配置违规。
3.1普通的键情况
3.2特例情况
我们期望第一个参数如果为某个特殊值比如5时，它的限流和平常的不一样，阈值可以达到200。
4.系统规则
系统规则是整体维度的，而不是细分为资源维度，仅对入口流量生效，入口流量指的是进入应用的流量。相当于在最外层做了保护。
5.@SentinelResource注解说明
如果我们使用了@SentinelResource注解，并给value附上了值，如下：
访问此接口后，sentinel控制台会有两个资源名，如下：
此时注意，如果我们给byUrl添加流控，就表明我们要使用自定义的兜底方法，但是我们并没有用blockHandler定义该有的兜底方法，那么如果限流了sentinel不会使用自己默认自带的，会返回error错误信息。
如果我们给/rateLimit/byUrl添加流控，如果限流了sentinel会使用自己默认自带的。
我们现在的兜底方案面临的问题：
1.系统默认的，没有体现我们自己的业务要求。
2.依照现有条件，我们自定义的处理方法又和业务代码耦合在一块，不直观。
3.每个业务方法都添加一个兜底的，那代码膨胀加剧。
4.全局统一的处理方法没有体现。
我们可以创建CustomerBlockHandler类用于自定义限流处理逻辑，将所有的限流兜底方法都定义在一起，外面直接引用即可。如下所示：
6.服务熔断
6.1服务熔断只配置fallback
注意：这里的兜底方法返回值和原方法的返回值类型必须一致。
6.2服务熔断只配置blockHandler
注意：如果没有触发sentinel配置规则，但方法内部出现了异常，此处直接会报错，返回给前台error错误信息，对用户不友好。
6.3fallback和blockHandler都配置
各自找各自的，双剑合璧，威力大增。若 blockHandler 和 fallback 都进行了配置，则被限流降级而抛出 BlockException 时只会进入 blockHandler 处理逻辑。
6.4exceptionsToIgnore
表示忽略异常，比如配置了exceptionsToIgnore = {IllegalArgumentException.class}，就算配置了fallback兜底方法，如果方法出现了IllegalArgumentException异常，不会走兜底方法，而是直接返回error错误信息。
6.5服务熔断OpenFeign
还是以前的那一套，直接使用即可。
7.规则持久化
像我们之前在Sentinel中配置的规则，如果服务关闭或者重启，其规则都没有了，这样肯定是不行的，所以我们可以把规则配置到Nacos中，让Sentinel去和Nacos共享，这样就达到了服务的匹配规则持久化。
-
resource：资源名称；
-
limitApp：来源应用；
-
grade：阈值类型，0表示线程数，1表示QPS；
-
count：单机阈值；
-
strategy：流控模式，0表示直接，1表示关联，2表示链路；
-
controlBehavior：流控效果，0表示快速失败，1表示Warm Up，2表示排队等待；
-
clusterMode：是否集群
8.Hystrix和Sentinel比较
Hystrix和Sentinel都是用于服务容错的组件，但是Sentinel相比于Hystrix更加的强大。
-
对于熔断降级：Hystrix是基于异常比率，而Sentinel有平均响应时间、异常比率、异常数。
-
对于流控效果：Hystrix不支持，而Sentinel有快速失败、预热、排队等待。
-
对于控制台：Hystrix只是简单的监控查看，而Sentinel控制台操作简单，可进行多种配置。