SpringCloudAlibaba——Sentinel-CSDN博客

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 Up2表示排队等待

• clusterMode是否集群

8.Hystrix和Sentinel比较

Hystrix和Sentinel都是用于服务容错的组件但是Sentinel相比于Hystrix更加的强大。

• 对于熔断降级Hystrix是基于异常比率而Sentinel有平均响应时间、异常比率、异常数。

• 对于流控效果Hystrix不支持而Sentinel有快速失败、预热、排队等待。

• 对于控制台Hystrix只是简单的监控查看而Sentinel控制台操作简单可进行多种配置。