流量控制在网络传输中是一个常用的概念,它用于调整网络包的发送数据。在网络传输中,任意时间到来的请求往往是随机不可控的,而系统的处理能力是有限的。我们需要根据系统的处理能力对流量进行控制
在调用系统的时候,如果调用链路中的某个资源出现了不稳定,最终会导致请求发生堆积,进而导致级联错误
而熔断降级就可以解决这个问题,所谓的熔断降级就是当检测到调用链路中某个资源出现不稳定的表现,例如请求响应时间长或异常比例升高的时候,则对这个资源的调用进行限制,让请求快速失败,避免影响到其它的资源而导致级联故障
官方仓库:码云:https://gitee.com/rmlb/Sentinel
GitHub:https://github.com/alibaba/Sentinel/
官网:https://sentinelguard.io/zh-cn/
资源:资源是Sentinel的关键概念。它可以是Java应用程序中的任何内容,例如,由应用程序提供的服务,或由应用程序调用的其他应用提供的服务,甚至可以是一段代码。只要通过Sentinel API定义的代码,就是资源,能够被Sentinel保护起来。大部分情况下,可以使用方法签名、URL甚至是服务名称作为资源名来标示资源
规则:规则指的是围绕资源的实时状态设定的规则,可以包括流量控制规则、熔断降级规则以及系统保护规则。所有规则可以动态实时调整
丰富的应用场景: Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景,例如秒杀(即突发流量控制在系统容量可以承受的范围)、消息削峰填谷(对于突然到来的大量请求,您可以配置流控规则,以稳定的速度逐步处理这些请求,从而避免流量突刺造成系统负载过高)、集群流量控制、实时熔断下游不可用应用等
完备的实时监控: Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据,甚至 500 台以下规模的集群的汇总运行情况
广泛的开源生态: Sentinel 提供开箱即用的与其它开源框架 / 库的整合模块,例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel
完善的 SPI 扩展点: Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等
核心库(Java 客户端): 不依赖任何框架 / 库,能够运行于所有 Java 运行时环境,同时对 Dubbo / Spring Cloud 等框架也有较好的支持
控制台(Dashboard): 基于 Spring Boot 开发,打包后可以直接运行,不需要额外的 Tomcat 等应用容器
对比
|
sentinel |
Hystrix |
Resilience4j |
隔离策略 |
信号量隔离(并发线程数隔离) |
线程池隔离/信号量隔离 |
信号量隔离 |
熔断降级策略 |
基于响应时间、异常比率、异常数 |
基于异常比率 |
基于异常比率、响应时间 |
实时统计实现 |
滑动窗口 |
滑动窗口 |
Ring Bit Buffer |
动态规则配置 |
支持多种数据资源 |
支持多种数据资源 |
有限支持 |
扩展性 |
多个扩展点 |
插件的形式 |
接口的形式 |
基于注解 |
支持 |
支持 |
支持 |
限流 |
基于 QPS,支持基于调用关系的限流 |
有限的支持 |
Rate Limiter |
流量整形 |
支持预热模式、匀速器模式、预热排队模式 |
不支持 |
简单的 Rate Limiter 模式 |
系统自适应保护 |
支持 |
不支持 |
不支持 |
控制台 |
提供开箱即用的控制台,可配置规则,查看秒级监控,机器发现等 |
简单的监控查看 |
不提供控制台,可对接其他监控系统 |
Sentinel 中所有的规则都可以在内存中动态的查询和修改,修改之后立即生效,同时Sentinel 也提供了相关的 API 供用户使用
主要有一下几种规则:
1、流量控制规则
2、熔断降级规则
3、系统保护规则
4、来源访问规则
5、动态规则扩展
流量控制其原理是监控应用流量的QPS或并发线程数等指标,当达到指定的阈值时对流量进行控制,以避免被瞬时的流量高峰冲垮,从而保障应用的高可用性
流量控制主要有两种方式:
1、并发线程数:并发线程数限流用于保护业务线程数不被耗尽
2、QPS:当QPS超过某个阈值的时候,则采取措施进行流量控制
一条限流规则主要由下面几个因素组成,可以组合这些元素来实现不同的限流效果:
1、resource:资源名,即限流规则的作用对象
2、count:限流阈值
3、grade:限流阈值类型(QPS或并发线程数)
4、limitApp:流控针对的调用来源,若为default则不区分调用来源
5、strategy:调用关系限流策略
6、controlBehavior:流量控制效果(直接拒绝、Warm Up、匀速排队)
直接拒绝
(RuleConstant.CONTROL_BEHAVIOR_DEFAULT)方式是默认的流量控制方式,当QPS超过任意规则的阈值后,新的请求就会被立即拒绝,拒绝方式为抛出FlowException。这种方式适用于对系统处理能力确切已知的情况下,比如通过压测确定了系统的准确水位时
Warm Up(RuleConstant.CONTROL_BEHAVIOR_WARM_UP)方式,即预热/冷启动方式。当系统长期处于低水位的情况下,当流量突然增加时,直接把系统拉升到高水位可能瞬间把系统压垮。通过冷启动,让通过的流量缓慢增加,在一定时间内逐渐增加到阈值上限,给冷系统一个预热的时间,避免冷系统被压垮
匀速排队
(RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER)方式会严格控制请求通过的间隔时间,也即是让请求以均匀的速度通过,对应的是漏桶算法
同一个资源可以同时有多个限流规则,检查规则时会依次检查
熔断降级会在调用链路中某个资源出现不稳定状态时(例如调用超时或异常比例升高),对这个资源的调用进行限制,让请求快速失败,避免影响到其它的资源而导致级联错误。当资源被降级后,在接下来的降级时间窗口之内,对该资源的调用都自动熔断(默认行为跑出DegradeException)
熔断降级规则(DegradeRule)包含下面几个重要的属性:
Field |
说明 |
默认值 |
Resource |
资源名, |
即规则的作用对象 |
Grade |
熔断策略,支持慢调用比例/异常比例/异常数策略 |
慢调用比例 |
Count |
慢调用比例模式下为慢调用临界 RT(超出该值计为慢调用);异常比例/异常数模式下为对应的阈值 |
|
timeWindow |
熔断时长,单位为s |
|
minRequestAmount |
熔断触发的最小请求数,请求数小于该值时即使异常比率超出阈值也不会熔断 |
5 |
statIntervalMs |
统计时长(单位为ms),如60*1000代表分钟级 |
1000ms |
slowRatioThreshold |
慢调用比例阈值,仅慢调用比例模式有效 |
|
同一个资源可以同时有多个降级规则,检查规则时会依次检查
Sentinel提供以下几种熔断策略:
慢调用比例(SLOW_REQUEST_RATIO):选择以慢调用比例作为阈值,需要设置允许的慢调用RT(即最大的响应时间),请求的响应时间大于该值则统计为慢调用。当单位统计时长(statIntervalMs)内请求数目大于设置的最小请求数目,并且慢调用的比例大于阈值,则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN状态),若接下来的一个请求响应时间小于设置的慢调用RT则结束熔断,若大于设置的慢调用RT则会再次被熔断。
异常比例(ERROR_RATIO):当单位统计时长(statIntervalMs)内请求数目大于设置的最小请求数目,并且异常的比例大于阈值,则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN状态),若接下来的一个请求成功完成(没有错误)则结束熔断,否则会再次被熔断。异常比率的阈值范围是 [0.0, 1.0],代表0% - 100%。
异常数(ERROR_COUNT):当1分钟内的异常数目超过阈值之后会自动进行熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN状态),若接下来的一个请求成功完成(没有错误)则结束熔断,否则会再次被熔断
1、规则管理及推送
如果不做任何修改,SentinelDashboard的推送规则方式是通过API将规则推送至客户端并直接更新到内存中,应用重启规则就会消失
Push模式:
Push模式的数据源,如远程配置中心(ZooKeeper、Nacos、Apollo等等),由Sentinel控制台统一进行管理,直接进行推送,数据源仅负责获取配置中心推送的配置并更新到本地。数据流向为:Sentinel控制台→配置中心→Sentinel数据源(存储)→Sentinel客户端
2、监控
Sentinel控制台中监控数据聚合后直接存在内存中,未进行持久化,且仅保留最近5分钟的监控数据,默认的监控数据包含应用名称、时间戳、资源名称、异常数、请求通过数、请求拒绝数、平均响应时间等信息,可以结合一些时序数据库存储监控信息,如InfluxDB
>>>>>>>>> 接下一篇学习: https://www.cnblogs.com/Alay/p/15488108.html <<<<<<<<<<<<<<