Sentinel服务熔断和流控

mmj_up

已于 2023-08-27 15:08:10 修改

阅读量94

点赞数

文章标签： sentinel spring cloud

于 2023-08-27 14:45:54 首次发布

本文链接：https://blog.csdn.net/mmj_internet/article/details/132523269

版权

介绍

随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 是面向分布式服务架构的流量控制组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统负载保护、热点防护等多个维度来帮助开发者保障微服务的稳定性。

Spring Cloud Alibaba Sentinel 同时兼具了熔断器和流控的功能。

Sentinel和Hystrix对比

熔断

微服务架构的系统通常会包含多个微服务，各个微服务可能部署在不同的机器上并通过网络进行通信，那么就不可避免会遇到 “网络请求超时” 、“微服务不可用” 等问题，这就会进一步引起依赖它的微服务不可用，这样不断引发服务故障的现象称为『雪崩效应』，最终的结果是整个应用系统瘫痪。

为了解决上述问题，编程领域（参考现实生活）提出了熔断器：使用熔断器模式，如果请求出现异常，所有请求都会直接返回，而不会等待或阻塞，这样可以减少资源的浪费。熔断器所造成的这种现象也叫『快速失败（fast fall）』。

我们在服务的 “请求发起方” 使用 Sentinel 整合 OpenFeign 进行熔断降级。

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

熔断规则

慢调用比例

如下配置：在一秒内，发5次请求，如果每次请求的响应时间超过500毫秒，这种比例达到0.5（50%），就进行熔断，熔断时长就是10秒。如：1秒内有5次请求，其中有3次请求响应时间超过了500毫秒，那么这个比例就是60%，大于50%，此时就熔断，然后降级。

异常数

如下配置：一秒内发送5次请求，如果有3次失败（异常），则直接熔断，然后降级。

异常比例

如下配置：1秒钟发送5次请求，如果调用接口最终失败的比例超过了20%，则熔断9s。

流控

限流功能指的是 Sentinel（类似于过滤器、拦截器的效果）在收到请求后，拒绝请求的放行（至 Controller），而是直接返回，从而减少对 Controller，乃至 Service 的触发执行。

熔断和限流的区别在于，熔断是确确实实发生了错误，而限流是人为（根据设置）强行让一部分请求被打回。

在实际使用中我们是这样安排的：

在服务发起方，Sentinel 整合 OpenFeign 实现熔断功能；
在服务被调方，Sentinel 整合 Spring MVC 实现限流功能。

总结：流控针对provider，熔断降级针对consumer

流控规则

在菜单左侧的簇点链路和流控规则都可以针对服务接口添加流控规则：

当我们的服务接口资源被访问的时候，就会出现在簇点链路列表中，我们可以针对该服务接口资源配置流程控制规则

说明：

资源名：表示我们针对哪个接口资源进行流控规则配置，如：/test2/{id}
针对来源：表示针对哪一个服务访问当前接口资源的时候进行限流，default 表示不区分访问来源。如填写服务名称：xxx-service，表示 xxx-service 访问前接口资源的时候进行限流，其他服务访问该接口资源的时候不限流，一般就是默认为default即可。
阈值类型/单机阈值：QPS，每秒钟请求数量。上图配置表示每秒钟超过2次请求的时候进行限流；当然我们可以设置线程数，表示开启 n 个线程处理资源请求，这个不是只每秒2个线程，对服务端 /test1请求，资源接口的 2 个线程都被占用的时候，其他访问失败！一般用的都是QPS

是否集群：默认情况下我们的限流策略都是针对单个服务的，当然sentinel 提供了集群限流的功能。

除非你的微服务规模特别大，一般不要使用集群模式。集群模式需要各节点与 token server 交互才可以，会增加网络交互次数，一定程度上会拖慢你的服务响应时间。

上面的限流规则用一句话说：对于任何来源的请求，当超过每秒 2 次的标准之后就直接限流，访问失败抛出 BlockException 异常！

流控规则高级选项

1.流控模式

直接：当前资源达到限流标准时就直接限流，默认值。
关联：假设/important接口的重要程度要高于 /normal接口，如果，/important接口的访问压力很大，那么，可以『牺牲』掉 /normal 接口，全力保证 /important 接口的正常运行。
链路：链路限流和关联限流的思路很像，假设我们要去请求某个微服务，该微服务有2个接口（/query和/add），而这两个接口又调用了同一个service层的方法(如：doSomething（）方法)，那么，我们可以『站在 doSomething的方法』的角度上进行设置：如果是 /query接口在调用service层的 doSomething方法，那么就进行限流，而 /add接口的调用就不限流，或设置为更宽松一些的流控。

2.流控效果

快速失败：很简单的说就是达到限流标准后，请求就被拦截，直接失败。（HTTP状态码：429 too many request），默认值。
Warm up：预热模式，也有叫冷启动，主要是为系统启动时设置预热时间，底层有预热因子是3，在系统刚启动时，使用的阈值不再是每秒多少个请求，而是设置的阈值除以预热因子，在预热的时间内，逐渐提升阈值，最后达到设置的阈值（也就是每秒多少个请求），好处是预防系统刚启动时，突发大量的请求，服务容易宕机。