精华内容
下载资源
问答
  • Sentinel熔断降级

    2021-07-30 14:19:39
    Sentinel熔断降级 降级策略 我们通常用以下几种方式来衡量资源是否处于稳定的状态: 平均响应时间 (DEGRADE_GRADE_RT):当资源的平均响应时间超过阈值(DegradeRule 中的 count,以 ms 为单位)之后,资源进入准...

    Sentinel熔断降级

    降级策略

    我们通常用以下几种方式来衡量资源是否处于稳定的状态:

    • 平均响应时间 (DEGRADE_GRADE_RT):当资源的平均响应时间超过阈值(DegradeRule 中的 count,以 ms 为单位)之后,资源进入准降级状态。接下来如果持续进入 5 个请求,它们的 RT 都持续超过这个阈值,那么在接下的时间窗口(DegradeRule 中的 timeWindow,以 s 为单位)之内,对这个方法的调用都会自动地返回(抛出 DegradeException)。注意 Sentinel 默认统计的 RT 上限是 4900 ms,超出此阈值的都会算作 4900 ms,若需要变更此上限可以通过启动配置项 -Dcsp.sentinel.statistic.max.rt=xxx 来配置。
    • 异常比例 (DEGRADE_GRADE_EXCEPTION_RATIO):当资源的每秒异常总数占通过量的比值超过阈值(DegradeRule 中的 count)之后,资源进入降级状态,即在接下的时间窗口(DegradeRule 中的 timeWindow,以 s 为单位)之内,对这个方法的调用都会自动地返回。异常比率的阈值范围是 [0.0, 1.0],代表 0% - 100%。
    • 异常数 (DEGRADE_GRADE_EXCEPTION_COUNT):当资源近 1 分钟的异常数目超过阈值之后会进行熔断。
      注意:异常降级仅针对业务异常,对 Sentinel 限流降级本身的异常(BlockException)不生效。为了统计异常比例或异常数,需要通过 Tracer.trace(ex) 记录业务异常。

    作用

    对调用链路中不稳定的资源进行熔断降级是保障高可用的重要措施之一。由于调用关系的复杂性,如果调用链路中的某个资源不稳定,最终会导致请求发生堆积。Sentinel 熔断降级会在调用链路中某个资源出现不稳定状态时(例如调用超时或异常比例升高),对这个资源的调用进行限制,让请求快速失败,避免影响到其它的资源而导致级联错误。当资源被降级后,在接下来的降级时间窗口之内,对该资源的调用都自动熔断(默认行为是抛出 DegradeException)

    慢调用比例

    慢调用比例(SLOW_REQUEST_RATIO):选择以慢调用比例作为阈值,需要设置允许的慢调用 RT(即最大的响应时间),请求的响应时间大于该值则统计为慢调用。当单位统计时长(statIntervalMs)内请求数目大于设置的最小请求数目,并且慢调用的比例大于阈值,则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN 状态),若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断,若大于设置的慢调用 RT 则会再次被熔断。

    代码,

    为了方便测试添加这一句代码

    TimeUnit.MILLISECONDS.sleep(1500);
    

    sentinel中添加降级规则!
    在这里插入图片描述

    在这里插入图片描述

    重启服务进行调用

    服务限流

    异常比例

    异常比例 (ERROR_RATIO):当单位统计时长(statIntervalMs)内请求数目大于设置的最小请求数目,并且异常的比例大于阈值,则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN 状态),若接下来的一个请求成功完成(没有错误)则结束熔断,否则会再次被熔断。异常比率的阈值范围是 [0.0, ],代表 0% - 100%。

    在降级方法中添加

    int i=1/0;
    

    访问此方法必定会报错

    添加降级规则

    在这里插入图片描述

    访问此方法

    Blocked by Sentinel (flow limiting)

    进行了降级处理

    如果不加此降级策略每次必定会报错,会调用此方法异常

    异常数

    异常数 (ERROR_COUNT):当单位统计时长内的异常数目超过阈值之后会自动进行熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN 状态),若接下来的一个请求成功完成(没有错误)则结束熔断,否则会再次被熔断。

    sentinel中添加
    在这里插入图片描述

    访问5次

    Whitelabel Error Page

    This application has no explicit mapping for /error, so you are seeing this as a fallback.

    Fri Jul 30 14:15:47 CST 2021

    There was an unexpected error (type=Internal Server Error, status=500).

    第六次

    Blocked by Sentinel (flow limiting)
    
    展开全文
  • Sentinel 熔断降级

    2021-09-28 10:17:14
    熔断降级规则(DegradeRule)包含下面几个重要的属性: Field 说明 默认值 resource 资源名,即规则的作用对象 grade 熔断策略,支持慢调用比例/异常比例/异常数策略 慢调用比例 ..

    本篇继续我们的Sentinel,本篇记录一下Sentinel的熔断降级,各位看到此博客的小伙伴,如有不对的地方请及时通过私信我或者评论此博客的方式指出,以免误人子弟。多谢!

    详细资料看官方文档  点此查看  

    环境说明: 统一改为官方推荐的版本。

    版本对应 点此查看

    目录

    降级规则介绍

    降级策略 - 慢调用比例

    完善测试类

    配置

    测试 

    降级策略 - 异常比例

    完善测试类

    配置

    测试 

    降级策略 - 异常数

    配置

    测试


    降级规则介绍

    先看下Sentinel降级规则的添加页面:


    熔断降级规则(DegradeRule)包含下面几个重要的属性:

    Field说明默认值
    resource资源名,即规则的作用对象
    grade熔断策略,支持慢调用比例/异常比例/异常数策略慢调用比例
    count慢调用比例模式下为慢调用临界 RT(超出该值计为慢调用);异常比例/异常数模式下为对应的阈值
    timeWindow熔断时长,单位为 s
    minRequestAmount熔断触发的最小请求数,请求数小于该值时即使异常比率超出阈值也不会熔断(1.7.0 引入)5
    statIntervalMs统计时长(单位为 ms),如 60*1000 代表分钟级(1.8.0 引入)1000 ms
    slowRatioThreshold慢调用比例阈值,仅慢调用比例模式有效(1.8.0 引入)

    Sentinel 提供以下几种熔断策略:

    • 慢调用比例 (SLOW_REQUEST_RATIO):选择以慢调用比例作为阈值,需要设置允许的慢调用 RT(即最大的响应时间),请求的响应时间大于该值则统计为慢调用。当单位统计时长(statIntervalMs)内请求数目大于设置的最小请求数目,并且慢调用的比例大于阈值,则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN 状态),若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断,若大于设置的慢调用 RT 则会再次被熔断。
    • 异常比例 (ERROR_RATIO):当单位统计时长(statIntervalMs)内请求数目大于设置的最小请求数目,并且异常的比例大于阈值,则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN 状态),若接下来的一个请求成功完成(没有错误)则结束熔断,否则会再次被熔断。异常比率的阈值范围是 [0.0, 1.0],代表 0% - 100%。
    • 异常数 (ERROR_COUNT):当单位统计时长内的异常数目超过阈值之后会自动进行熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN 状态),若接下来的一个请求成功完成(没有错误)则结束熔断,否则会再次被熔断。

    下面分别对三种熔断策略进行记录

    降级策略 - 慢调用比例

    完善测试类

    在FlowLimitController类中增加以下测试方法。

        @GetMapping("/testD")
        public String testD() {
            try {
                TimeUnit.SECONDS.sleep(1);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            return "------testD";
        }

    配置

    以下配置的含义为:如果1秒内持续进入大于等于5个请求,并且请求响应的时间大于200ms时,这个请求即为慢调用,当慢调用的比例大于1时会触发降级,直到5秒后新的请求的响应时间小于200ms时,才结束熔断。

    测试 

    使用jmeter创建如下线程组访问 http://localhost:8401/testD

    启动线程组后我们在浏览器访问 http://localhost:8401/testD 报错如下,说明降级生效: 

    过几秒后jmeter线程跑完再次访问 http://localhost:8401/testD 可以正常访问。

    降级策略 - 异常比例

    完善测试类

    在FlowLimitController类中增加以下测试方法。

        @GetMapping("/testE")
        public String testE() {
            log.info("testE 测试异常比例");
            int age = 10 / 0;
            return "------testE 测试异常比例";
        }

    配置

    以下配置的含义为:如果1秒内持续进入大于等于5个请求,并且请求中报异常的比例超过0.2则触发降级(降级时间持续5秒),5秒后,新的请求若正常返回,才结束熔断。 

    测试 

    访问 http://localhost:8401/testE 结果如下:

    使用上面创建的线程组并修改http请求的访问地址为 http://localhost:8401/testE 

    启动线程组后我们再浏览器访问 http://localhost:8401/testE 报错如下,说明降级生效: 

    过几秒后jmeter线程跑完再次访问 http://localhost:8401/testE 结果如下:

    降级策略 - 异常数

    配置

    以下配置的含义为:如果1秒内持续进入大于等于5个请求,并且请求异常数超过5时,会触发降级(降级时间持续5秒),5秒后,新的请求若正常返回,才结束熔断。

    测试

    效果同 降级策略 - 异常比例。

    展开全文
  • Sentinel熔断降级说明

    千次阅读 2020-09-26 14:24:52
    前言Sentinel在1.8.0版本对熔断降级做了大的调整,可以定义任意时长的熔断时间,引入了半开启恢复支持。下面梳理下相关特性一、熔断状态熔断有三种状态,分别为OPEN、HALF_O...

    前言

    Sentinel在1.8.0版本对熔断降级做了大的调整,可以定义任意时长的熔断时间,引入了半开启恢复支持。下面梳理下相关特性

    一、熔断状态

     

    熔断有三种状态,分别为OPEN、HALF_OPEN、CLOSED。

    状态说明
    OPEN表示熔断开启,拒绝所有请求
    HALF_OPEN探测恢复状态,如果接下来的一个请求顺利通过则结束熔断,否则继续熔断
    CLOSED表示熔断关闭,请求顺利通过

    二、熔断策略

     

    熔断降级支持慢调用比例、异常比例、异常数三种熔断策略。先明确下面两个概念:慢调用:指耗时大于阈值RT的请求称为慢调用,阈值RT由用户设置

    最小请求数:允许通过的最小请求数量,在最小请求数量内不发生熔断,由用户设置

    1.慢调用比例

     
    属性说明
    最大RT需要设置的阈值,超过该值则为慢应用
    比例阈值慢调用占所有的调用的比率,范围:[0~1]
    熔断时长在这段时间内发生熔断、拒绝所有请求
    最小请求数即允许通过的最小请求数,在该数量内不发生熔断

    执行逻辑

    熔断(OPEN):请求数大于最小请求数并且慢调用的比率大于比例阈值则发生熔断,熔断时长为用户自定义设置。

    探测(HALFOPEN):当熔断过了定义的熔断时长,状态由熔断(OPEN)变为探测(HALFOPEN)。

    • 如果接下来的一个请求小于最大RT,说明慢调用已经恢复,结束熔断,状态由探测(HALF_OPEN)变更为关闭(CLOSED)

    • 如果接下来的一个请求大于最大RT,说明慢调用未恢复,继续熔断,熔断时长保持一致

    2.异常比例

     

    通过计算异常比例与设置阈值对比的一种策略。

    属性说明
    异常比例阈值异常比例=发生异常的请求数÷请求总数取值范围:[0~1]
    熔断时长在这段时间内发生熔断、拒绝所有请求
    最小请求数即允许通过的最小请求数,在该数量内不发生熔断

    执行逻辑

    熔断(OPEN):当请求数大于最小请求并且异常比例大于设置的阈值时触发熔断,熔断时长由用户设置。

    探测(HALFOPEN):当超过熔断时长时,由熔断(OPEN)转为探测(HALFOPEN)

    • 如果接下来的一个请求未发生错误,说明应用恢复,结束熔断,状态由探测(HALF_OPEN)变更为关闭(CLOSED)

    • 如果接下来的一个请求继续发生错误,说明应用未恢复,继续熔断,熔断时长保持一致

    3.异常数

     

    通过计算发生异常的请求数与设置阈值对比的一种策略。

    属性说明
    异常数请求发生异常的数量
    熔断时长在这段时间内发生熔断、拒绝所有请求
    最小请求数即允许通过的最小请求数,在该数量内不发生熔断

    执行逻辑

    熔断(OPEN):当请求数大于最小请求并且异常数量大于设置的阈值时触发熔断,熔断时长由用户设置。探测(HALFOPEN):当超过熔断时长时,由熔断(OPEN)转为探测(HALFOPEN)

    • 如果接下来的一个请求未发生错误,说明应用恢复,结束熔断,状态由探测(HALF_OPEN)变更为关闭(CLOSED)

    • 如果接下来的一个请求继续发生错误,说明应用未恢复,继续熔断,熔断时长保持一致

    三、规则参数说明

    熔断降级DegradeRule中的属性进行说明

    属性说明
    resource资源名称
    grade降级策略 0:慢调用比例 1:异常比例 2:异常数量
    count用户设置的阈值,根据不同的策略分别表示最大RT、异常比例阈值、异常数阈值
    timeWindow熔断时长
    minRequestAmount最小请求数,默认为5
    slowRatioThreshold慢调用比率阈值,默认为1.0
    statIntervalMs熔断时长,默认为1秒

    四、规则格式示例

    1.慢调用策略

     

    [
        {
            "count": 3000,
            "grade": 0,
            "limitApp": "default",
            "minRequestAmount": 100,
            "resource": "degrade01",
            "slowRatioThreshold": 0.5,
            "statIntervalMs": 1000,
            "timeWindow": 5
        }
    ]
    

    2.异常比例

     

    {
        "count": 0.3,
        "grade": 1,
        "limitApp": "default",
        "minRequestAmount": 200,
        "resource": "degrade02",
        "slowRatioThreshold": 1,
        "statIntervalMs": 1000,
        "timeWindow": 5
    }
    

    3.异常数

     

    {
        "count": 1000,
        "grade": 2,
        "limitApp": "default",
        "minRequestAmount": 300,
        "resource": "degrade03",
        "slowRatioThreshold": 1,
        "statIntervalMs": 1000,
        "timeWindow": 5
    }
    

    作者丨梁勇
    来源丨瓜农老梁(ID:gh_01130ae30a83)
    欢迎关注公众号“瓜农老梁”


    「瓜农老梁  学习同行」    

           

    展开全文
  • Alibaba Sentinel熔断降级/限流框架不完全解析关于Alibaba Sentinel熔断降级/限流框架一段话的Sentinel介绍新的改变功能快捷键合理的创建标题,有助于目录的生成如何改变文本的样式插入链接与图片如何插入一段漂亮的...

    关于Alibaba Sentinel熔断降级/限流框架

    阿里在集群防御、熔断限流方向所做可圈可点。 其中 github: Sentinel 在其中扮演着很重要的角色。 相对于类似的框架如 Hystrix(多得多的文档), 更加符合中国互联网工程师的思维习惯。

    接下来的内容如果觉得啰嗦可以直接跳到Sentinel架构介绍小节

    类似的防御体系:

    1. 美团的github: OCTO更像是集全公司的力量, 由上而下的要求全公司接入的、集中治理的平台。
    2. 滴滴对熔断、限流上更多的每个独立的团队自行发展, 各成体系。

    以及其他企业的预案方案,想要轻松接入都不容易。 想要最低成本的接入熔断、限流,Sentinel更合适。

    本文将持续迭代。

    这里有对熔断、限流的包含源码解析的详解: Alibaba Sentinel 限流、熔断实现详解

    一段话的介绍

    预案

    对可预期的问题, 例如 依赖的某服务不可用网络可能不稳定DB服务器不稳定下星期要进行大规模抢购可能有人恶意爬取 等这些不符合当前业务运行规则的。
    设计一个处理方案, 来规避这些问题。

    一般处理方案(简单列举):

    • 两地三中心
    • 服务器紧急扩容(参考微博)
    • 代码中添加if else语句切换请求来源
    • ···

    通过建立一些针对可预期的问题的处理方案, 最低限度的保证自己系统的主体服务可用性

    限流

    通过压测测试出当前系统的最大负载能力,然后配置超过这个负载能力的请求全部丢弃、或者排队等待。
    在长链路调用中,以最低承受单点为基准, 超过这个单点的负载能力的请求全部丢弃、或者排队等待。

    通过限制调用方对自己的调用,起到保护自己系统的效果

    熔断
    在Sentinel中, 熔断往往跟降级靠在一起(我更加认为降级本就是预案的一部分,限流是预案、熔断也是预案,熔断却不一定都是降级)。

    所有的对外部的调用都认为是不可控的。
    其中部分调用是必须依赖的, 部分调用是可以被替代的(如查缓存改查DB)。

    当我们对外部的请求发生异常, 例如超时、抛出异常, 且超过一定的阈值。这个时候我们可以理解为外部依赖不可用,多次请求也只是在浪费时间。这个时候可以禁止访问外部、或者直接返回默认值。

    通过限制自己对外部系统的调用, 起到节约响应时间、维护链路稳定的作用

    Alibaba Sentinel建立的用处就是在针对服务上的熔断与限流。此Sentinel不同于Redis的Sentinel
    它提供一个客户端SDK, 通过编写熔断、限流规则, 起到熔断、限流的作用。
    同时它提供一个服务端(非必须), 能够更好的监控客户端运行状态,同时免编码的直接下发规则给客户端。

    我基于Sentinel做的一个对Hello World的限流(看不到文件可直接下载):

    Sentinel使用方式

    部署Sentinel的客户端

    参考Github介绍 Sentinel新手指南 以及 如何使用

    大致这么几部:

    1. 引入依赖(pom/sentinel-core.jar
    2. 代码编写植入
    3. 定义规则(支持本地配置规则, 使用Sentinel Dashboard配置规则)。

    相对来说Sentinel的接入非常轻便简单了。但是遇到每一段代码都植入Sentinel给定的代码, 也是很麻烦, 因此可以参考小节 基于Sentinel所做易用性拓展

    参考官方demo:

    // 代码编写植入
    public static void main(String[] args) {
        // 配置规则.
        initFlowRules();
    
        while (true) {
            // 1.5.0 版本开始可以直接利用 try-with-resources 特性
            try (Entry entry = SphU.entry("HelloWorld")) {
                // 被保护的逻辑
                System.out.println("hello world");
    	} catch (BlockException ex) {
                // 处理被流控的逻辑
    	    System.out.println("blocked!");
    	}
        }
    }
    
    // 定义规则(支持本地配置规则, 使用Sentinel Dashboard配置规则)。
    private static void initFlowRules(){
        List<FlowRule> rules = new ArrayList<>();
        FlowRule rule = new FlowRule();
        rule.setResource("HelloWorld");
        rule.setGrade(RuleConstant.FLOW_GRADE_QPS);
        // Set limit QPS to 20.
        rule.setCount(20);
        rules.add(rule);
        FlowRuleManager.loadRules(rules);
    }
    

    部署Sentinel的服务端

    服务端非必须, 主要提供规则配置和下发。 对简化编码有很大的帮助。

    参考Github介绍 Sentinel 控制台

    服务端UI功能:

    名称概述用法其他
    实时监控采集当前资源的限流信息观察
    簇点链路把代码中植入的资源上报统一熔断、限流自动上报功能,很棒
    流控规则限流根据资源, 支持访问资源的QPS和访问资源的线程数限流一般是限制 QPS
    降级规则熔断降级根据资源,请求超时、异常、数超阈值熔断异于hystrix,时间窗口后直接恢复
    热点规则未知未知未知
    系统规则未知未知未知
    授权规则未知未知未知
    集群流控见名知意--
    机器列表见名知意--

    Sentinel架构介绍

    对Sentinel的介绍, 仅限于客户端(服务端并不是必须的产品)。参考源码 Sentinelsentinel-core
    Sentinel中的核心概念 resource(资源), 定义为被Sentinel保护的所有的事物。
    所有的预案操作都是依据资源而定的。

    sentinel-core直观代码分层:

    ➜  sentinel-core git:(master) tree -d
    .
    └── src
        └── main
           └── java
              └── com
                  └── alibaba
                      └── csp
                          └── sentinel
                              ├── annotation
                              ├── cluster
                              │   ├── client
                              │   ├── log
                              │   └── server
                              ├── concurrent
                              ├── config
                              ├── context
                              ├── eagleeye
                              ├── init
                              ├── log
                              ├── metric
                              │   └── extension
                              │       └── callback
                              ├── node
                              │   └── metric
                              ├── property
                              ├── slotchain
                              ├── slots
                              │   ├── block
                              │   │   ├── authority
                              │   │   ├── degrade
                              │   │   └── flow
                              │   │       └── controller
                              │   ├── clusterbuilder
                              │   ├── logger
                              │   ├── nodeselector
                              │   ├── statistic
                              │   │   ├── base
                              │   │   ├── data
                              │   │   └── metric
                              │   │       └── occupy
                              │   └── system
                              ├── spi
                              └── util
                                  └── function
    

    如上树形包结构, 重点关注这几个包:

    包名概述其他
    cluster在客户端自成集群中 限流生效后续专门讲
    node数据节点, 存储SDK基于Resource运行时的包括RT、异常数等数据-
    solt插件,限流、熔断、监控都是基于插件来的非常重要
    slotchain每次对资源的调用都需要走一次插件责任链式solt
    context上下文载体基于 ThreadLocal

    Sentinel Chain

    Sentinel 以插件的形式,将功能打包在客户端SDK中。
    插件可以构成一条单链(责任链模式)。限流、熔断、日志等功能, 都被打包在链条中。

    其中的每一个节点, 就是 solt
    详见com.alibaba.csp.sentinel.slotchain.AbstractLinkedProcessorSlot
    通过next指向下一个需要处理的节点。

    通常用到的solt

    概述其他
    NodeSelectorSlot维护一条调用链(Sentinel代码嵌套调用)。
    链首维护着一个DefaultNode
    构成其它信息树的根节点。
    这个类很重要,但是也很简单。就是维护一个调用树。
    ClusterBuilderSlot类似NodeSelectorSlot,维护的是ClusterNode
    存储着调用次数、线程数等信息。
    主要用于限流处FlowSlot
    -
    LogSlot在后续插件抛异常之后记一笔记录异常
    StatisticSlot在统计信息中记一笔后续熔点、限流数据的的来源
    SystemSlot基于整个应用的Load、QPS等限制-
    AuthoritySlot映射处理规则中的黑白名单-
    FlowSlot限流控制可直接参阅源码
    DegradeSlot熔断控制可直接参阅源码

    Node

    看接口定义, 它就是一个存储程序运行时的节点。
    com.alibaba.csp.sentinel.node.Node

    节点作用
    StatisticNode资源统计(计算规则), 其它Node的父类。 solt依赖StatisticNode持有的数据工作
    ClusterNode该节点中保存了资源的总体的运行时统计信息,包括rt,线程数,qps等等,
    相同的资源会全局共享同一个ClusterNode,以便用于全局QPS、线程数限制
    DefaultNode该节点持有指定上下文中指定资源的统计信息(NodeSelectorSlot创建),
    当在同一个上下文(嵌套Sentinel)中次调用entry方法时,该节点可能会创建有一系列的子节点。
    每个DefaultNode中会关联一个ClusterNode
    他们俩的区别在于DefaultNode更多的关注于当前Context的实时指标,
    ClusterNode更多的关注当前资源在所有的Context的指标(主要用这个
    EntranceNode该节点在创建context的时候即被创建出来, 在一次调用链上下文中往往是头部节点

    Sentinel执行流程图(我是重点,点我

    针对 Sentinel 所推荐的基础语法, 对其实现细致做解剖分析:

        try {
    	    entry = SphU.entry("HelloWorld");
            // 资源中的逻辑.
            System.out.println("hello world");
    	} catch (BlockException e1) {
    	    System.out.println("blocked!");
    	} finally {
    	   if (entry != null) {
    	       entry.exit();
    	   }
    	}
    
    Created with Raphaël 2.2.0 进入被包围代码块 获取上下文Context 处于嵌套代码中? ThreadLocal 获得Context 构建任务链ProcessorSlot Chain 1.NodeSelectorSlot 2.ClusterBuilderSlot 3.LogSlot 4.StatisticSlot 5.SystemSlot 6.AuthoritySlot 7.FlowSlot 8.DegradeSlot 依据链条逐个判断处理。 不符合规则则直接抛出 BlockException 在finally中逐个执行每个Solt的exit逻辑 受保护逻辑完毕 创建Context 构建EntranceNode链首 yes no

    整体的逻辑相对简单。是对一个责任链的调用
    重点在于整体数据链路的串联, 以及每个Solt的处理细则。

    功能实现解析

    限流功能

    Sentinel的限流实现比较简单, 支持集群限流(单讲)和单机限流。实现方式委托给了包com.alibaba.csp.sentinel.slots.block.flow.controller 下的实现。 分别支持快速失败(DefaultController)、Warm up(热加载限流, WarmUpController)、排队等待(RateLimiterController)三种模式。
    .
    它隶属于FlowSlot插件


    快速失败模式下的限流实现很简单, 通过获取ClusterNode中记录的当前每秒钟通过的请求数(clusterNode), 加上当前请求需要的请求数(一般是1), 如果大于规则的设定值, 直接抛出异常,请求丢弃。 被限流。

    Warm up 下的实现类似于Guava的限流实现, 采取 令牌桶 的方式。

    1. 从配置好规则开始, 限流大小从0逐步增长至预设限流大小。
    2. 每次执行限流判断的时候, 从令牌桶中重新判断是否需要灌入令牌。
    3. 快速失败模式一样, 如果已经消费的令牌数加上需要的令牌数多于可取令牌数。 不被限流。

    排队等待 模式很显然, 一般情况都会想到漏桶算法。 参见 Github 匀速器

    1. 排队等待采取了一种猜测等待时间的方法。
    2. 如果一个请求来了, 需要排队, 若预计等待时间过了依旧不满足限流条件, 自然放行。
    3. 而预计等待时间在限流条件下, 还会等待超时, 则自然直接拒绝掉。否则休眠之后放行。
    4. 排队等待的将支持后续排队, 被限流的程序则不再会被执行。

    想看详细的介绍?
    这里有包含源码解析的详解: Alibaba Sentinel 限流、熔断实现详解

    熔断功能

    熔断功能的实现就更简单了。
    熔断提供三种熔断模式:RT(超时时间), 异常比例(异常数在所有请求数中的占比),异常数(具体阈值)
    .
    它隶属于DegradeSlot插件
    它也都是依据于 ClusterNode 提供的信息做的熔断。


    RT 模式 还在写。

    想看详细的介绍?
    这里有包含源码解析的详解: Alibaba Sentinel 限流、熔断实现详解

    为什么用时间窗口(Node计算规则实现)

    这段主要描述的内容是Sentinel怎么精确的控制每一秒的。
    此处 https://juejin.im/post/5c3607b5e51d4542253faec3 有一个非常详细的介绍, 欢迎参阅。
    如下简单介绍:

    滑动窗口 Sentinel 的时间统计, 全放在了滑动窗口中去执行。依次委托步骤为:

    Node(StatisticNode) -> Metric(ArrayMetric) -> WindowWrap(BucketLeapArray) -> MetricBucket -> LongAdder
    

    滑动窗口如下解释:

    • 按秒滑动: 每秒长1000ms, 分两个窗口, 则每个窗口500ms
    • 按分滑动: 每分长60000ms, 分六十个窗口, 则每个窗口1000ms

    仅以每秒为例:
    任意一个时间点, 一定落在一秒的前500ms, 或者落在后500ms当面毫秒 - 当前毫秒 % 500)。
    滑动窗口, 通过当前时间点,一定知道自己位于哪个窗口中(LeapArray#currentWindow(long)),起始时间点是多少。
    .
    由上, 所有的统计(加、减)都可以基于时间窗口。

    具体case:
    后面计算限流的时候, 限定每秒QPS=N。 则只需要知道前500ms加上后500ms的请求数M, 加上当前这次请求需要的请求数X(每个窗口中的LongAdder, 数据, 以空间换时间, CAS累加成本太高), 是不是大于预设值N就好了。

    而每次做QPS累加, 是StatisticSlot在后续Slot计算未抛出异常之后才执行的。每次获取QPS,都需要得到当前的时间窗口(需要得到锁)

    那回归正题, 为什么使用时间窗口呢, 秒级的时间窗口又为什么是2个呢以我看来, 原因如下:

    1. 请求的到来并不是均匀的, 可能在一秒的前500ms根本没有请求。这个时候计算每秒的QPS需要由后500ms + 下一秒的前500ms
    2. 时间窗口的数量起码得能被时间长度(1s=1000ms/1m=60000ms)整除吧。
      • 并发环境中,时间窗口间隔越小, 当前线程位于窗口分界点的概率就越高。
      • 并发环境中,改修当前时间点所处的窗口,是需要加锁的,窗口越多,加锁越频繁。
      • 窗口多到一定程度,所有线程全花在计算时间窗口上去了。

    客户端与服务端通讯

    可靠性分析

    本文对可靠性着手的点有可用性、稳定性、高能效。所有的CASE都基于单台机器承受QPS100上限、单次任务执行200ms计算(模拟我部门生产环境)
    点会很多, 遇见一个提一个。

    可靠性

    高能效

    • Sentinel是有性能损失的。 甚至在高负载环境下, 可能达到5ms(数据基于生产环境混布,同机器有吃CPU的服务)

    这个小结的目的是分析出在使用Sentinel上的时候遇见的坑。
    实际生产活动中, 一般的企业维持100QPS的可能性并不高。还是并发环境的可能性就更低了。
    Sentinel依然是一个非常优秀的, 可以服务于生产环境的预案工具。

    集群限流

    基于Sentinel所做易用性拓展

    展开全文
  • 现代微服务架构都是分布式的,由非常多的服务组成。不同服务之间相互调用,组成复杂的调用链路。...因此我们需要对不稳定的弱依赖服务调用进行熔断降级,暂时切断不稳定调用,避免局部不稳定因素导致整体的雪崩。
  • Springcloud-alibaba-sentinel熔断降级

    千次阅读 2019-08-21 15:48:10
    Sentinel熔断降级会在调用链路中某个资源出现不稳定状态时(例如调用超时或异常比例升高),对这个资源的调用进行限制,让请求快速失败,避免影响到其它的资源而导致级联错误。当资源被降级后,在接下来的降级时间...
  • Sentinel熔断降级规则

    2021-06-07 09:08:07
    除了流量控制以外,对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。一个服务常常会调用别的模块,可能是另外的一个远程服务、数据库,或者第三方 API 等。例如,支付的时候,可能需要远程调用...
  • 使用场景: 项目调用了别人提供的dubbo接口,为避免dubbo服务出现异常,导致dubbo消费者服务异常,所以需要设置熔断降级规则,保护dubbo消费者服务。 1.引入依赖 <dependency> <groupId>...
  • Sentinel版本:1.8.0 1.8.0 对熔断特性做了大量升级,低于此版本的谨慎参考 2. 熔断策略 2.1 慢调用比例 最大 RT(即最大的响应时间):请求的响应时间大于RT则统计为慢调用。 当单位统计时长(默认1秒)内,请求...
  • 该版本是本年度最重要的版本之一,包含大量特性改进与 bug 修复,尤其是针对熔断降级特性的完善升级(支持任意统计时长、慢调用比例降级策略、熔断器事件监听)。在经过数月的打磨后,Sentinel 1.8.0 版本正式发布!...
  • 1、在yaml文件进行设置 意思是在本地资源中找到flowrule.json文件,里面有我们... sentinel: datasource: ds1: file: file: classpath:flowrule.json data-type: json rule-type: flow flowrule.json的内容 [ {
  • 一、熔断降级介绍与配置 概述:除了上一章节讲解的sentinel的流量控制之外,sentinel还提供了熔断降级功能。与处理高并发的系统自我保护机制不同的是,熔断降级主要防止当前接口不可用时,导致依赖该接口的服务也不...
  • Sentinel熔断降级

    2021-02-05 10:54:25
    sentinel的安装和项目集成:https://blog.csdn.net/www1056481167/article/details/113679945 jmeter下载地址https://archive.apache.org/dist/jmeter/source/#sig(模拟并发使用) RT(平均响应时间) 选择以慢...
  • Sentinel熔断降级

    2019-09-29 08:55:34
    Sentinel熔断降级会在调用链路中某个资源出现不稳定状态时(例如调用超时或异常比例升高),对这个资源的调用进行限制,让请求快速失败,避免影响到其它的资源而导致级联错误。当资源被降级后,在接下来的降级时间...
  • Sentinel系列 熔断降级

    2020-06-03 14:55:30
    Sentinel 熔断降级会在调用链路中某个资源出现不稳定状态时(例如调用超时或异常比例升高),对这个资源的调用进行限制,让请求快速失败,避免影响到其它的资源而导致级联错误。当资源被降级后,在接下来的降级时间...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 7,246
精华内容 2,898
关键字:

sentinel熔断降级