摘要:断路器。
目录
[TOC]
限流、降级、熔断
过载保护:指负载超过系统的承载能力时,系统会自动采取保护措施,确保自身不被压垮。
限流的原理跟熔断有点类似:都是通过判断某个条件来确定是否执行某个策略。但是又有所区别,
- 限流:是只处理自己能力范围之内的请求,超量的请求会被丢弃。
- 熔断:触发过载保护,该节点会暂停服务,直到恢复。
降级和熔断的区别:
常用的流量控制和熔断降级框架是 Netflix 的 Hystrix 和 alibaba 的 Sentinel。
限流
限流:流量控制(flow control),限制对服务端接口接受请求的频率,对超过限制的请求丢弃或放到队列中等待处理。
- 防止服务过载挂掉,可有效应对突发请求过多。
常见限流算法主要有:
- 计数器算法:限制指定时间内(固定窗口)能够通过的总请求数,超过设定的阀值就进行限流。
- 比如数据库连接池、线程池、秒杀的并发数;
- 有一些十分致命的弊端和问题:
- 突刺现象:比如刚开始计数的前期(前 10ms)已经通过了最大的请求数,那么后面的请求只能拒绝。
- 临界问题:在时间窗口的重置节点处突发请求,可以瞬间超过速率限制。用户有可能通过算法的这个漏洞,瞬间压垮应用。
- 假设第1分钟中的第59秒时,来了100个请求,此时没有超过100的限制。
- 然后第2分钟的第1秒来了100个请求。
- 相隔几毫秒,一下子进来200个请求,明显大于设计的目标限流阈值100。
- 滑动窗口算法:计数器算法中,是一个固定的时间窗口,而滑动窗口是将固定窗口再进行细分成多个窗口。优点:减少了临界值带来的并发超过阈值的问题。
- 漏桶算法:是一种恒定速率的限流算法,不管请求量是多少,服务端的处理效率是恒定的。漏桶限制的是请求的流出速率。当漏桶装满水后溢出的部分还是会被丢弃的。
- 与消息队列思想有些类似,都是进行削峰填谷。
- 算法实现:可以准备一个(固定容量)队列来保存暂时处理不了的请求,然后通过一个线程池定期从队列中获取请求来执行。
- 缺点:无法应对突发流量来袭、处理请求会有延迟。
- 令牌桶算法:令牌桶是一个存放固定容量令牌的桶,按照固定速率往桶里添加令牌,填满了就丢弃令牌。请求是否被处理要看桶中令牌是否足够,当令牌数减为零时则拒绝新的请求。在流量低峰时,令牌桶会出现堆积,因此当出现瞬时高峰时,就有足够多的令牌可以获取。
- 是对漏斗算法的一种改进,除了能够起到限流的作用外,还允许一定程度的流量突发。
- 实现方案:
Guava RateLimiter限流,谷歌提供的基于令牌桶算法,比较适用于单实例的系统。
总结:
- 基于时间窗口的限流更适合互联网实施业务限流的场景,即能快速处理、及时响应调用方,避免请求过长的等待时间。
- 令牌桶、漏桶算法更适合阻塞式限流的场景,即后台任务类的限流。
降级
降级:当服务器压力剧增的情况下,(根据当前业务情况及流量)对一些服务和页面(有策略的)降低优先级,以此释放服务器资源保证核心任务的正常运行。目的在于应对系统自身的故障。
- 比如电商大促,业务在峰值时刻,把商品评价、成交记录等功能临时关掉。弃车保帅,保证创建订单、支付等核心功能的正常使用。
熔断
熔断机制:在系统濒临崩溃的时候,立即中断服务,从而保障系统稳定避免崩溃。类似于电器中的“保险丝”。目的在于应对依赖的外部系统或第三方系统的故障。
- 系统自动收集所依赖服务的资源使用情况和性能指标,当恶化或调用失败次数达到某个阈值时就迅速失败,立即切换依赖其他备用服务。
- 例子:熔断触发条件往往跟系统节点的承载能力和服务质量有关,比如 CPU 的使用率超过 90%、请求错误率超过 5%、请求延迟超过 500ms。
Spring Cloud Hystrix 断路器
Sentinel
用于实现熔断与限流等一系列服务保护功能。
-
阿里开源。介绍:https://sentinelguard.io/zh-cn/docs/introduction.html
-
是面向分布式、多语言异构化服务架构的流量治理组件,主要以流量为切入点,从流量路由、流量控制、流量整形、熔断降级、系统(自适应)过载保护、热点流量防护等多个维度来保障微服务的稳定性。
具有如下特性:
- 丰富的应用场景:承接了阿里巴巴近 10 年的双十一大促流量的核心场景,例如秒杀,可以实时熔断下游不可用应用;
- 完备的实时监控:同时提供实时的监控功能。可以在控制台中看到接入应用的单台机器秒级数据,甚至 500 台以下规模的集群的汇总运行情况;
- 广泛的开源生态:提供开箱即用的与其它开源框架/库的整合模块,例如与 Spring Cloud、Dubbo、gRPC 的整合;
- 完善的 SPI 扩展点:提供简单易用、完善的 SPI 扩展点。您可以通过实现扩展点,快速的定制逻辑。
安装控制台
Sentinel控制台:是一个轻量级的控制台应用,可用于实时查看单机资源监控及集群资源汇总,并提供了一系列的规则管理功能,如流控规则、降级规则、热点规则等。
-
先从官网下载Sentinel,这里下载的是
sentinel-dashboard-1.6.3.jar文件,下载地址:https://github.com/alibaba/Sentinel/releases -
下载完成后在命令行输入如下命令运行Sentinel控制台:
1 | |
-
Sentinel控制台默认运行在8080端口上,登录账号密码均为
sentinel:http://localhost:8080- 可以查看单台机器的实时监控数据。
创建sentinel-service模块
用于演示Sentinel的熔断与限流功能。
- 在pom.xml中添加相关依赖,这里使用Nacos作为注册中心,所以需要同时添加Nacos的依赖:
1 | |
- 在application.yml中添加相关配置,主要是配置了Nacos和Sentinel控制台的地址:
1 | |
流量控制、限流功能
流量控制在网络传输中是一个常用的概念,用于调整网络包的发送数据。
- 然而,从系统稳定性角度考虑,在处理请求的速度上,也有非常多的讲究。
- 任意时间到来的请求往往是随机不可控的,而系统的处理能力是有限的。
- 我们需要根据系统的处理能力对流量进行控制。
- Sentinel 作为一个调配器,可以根据需要把随机的请求调整成合适的形状,如下图所示:

流量控制有以下几个角度:
- 资源的调用关系,例如资源的调用链路,资源和资源之间的关系;
- 运行指标,例如 QPS、线程池、系统负载等;
- 控制的效果,例如直接限流、冷启动、排队等。
Sentinel 的设计理念是让您自由选择控制的角度,并进行灵活组合,从而达到想要的效果。
Sentinel Starter 默认为所有的 HTTP 服务提供了限流埋点,也可以通过使用
@SentinelResource来自定义一些限流行为。
创建RateLimitController类
用于测试熔断和限流功能。
1 | |
根据资源名称限流
可以根据@SentinelResource注解中定义的value(资源名称)来进行限流操作,但是需要指定限流处理逻辑。
-
流控规则可以在Sentinel控制台进行配置,先启动Nacos和sentinel-service;
-
由于Sentinel采用的懒加载规则,需要先访问下接口,Sentinel控制台中才会有对应服务信息:http://localhost:8401/rateLimit/byResource
-
在Sentinel控制台配置流控规则,根据@SentinelResource注解的value值:

- 快速访问上面的接口,可以发现返回了自己定义的限流处理信息:

根据URL限流
还可以通过访问的URL来限流,会返回默认的限流处理信息。
- 在Sentinel控制台配置流控规则,使用访问的URL:

- 多次访问该接口,会返回默认的限流处理结果:http://localhost:8401/rateLimit/byUrl

自定义限流处理逻辑
可以自定义通用的限流处理逻辑,然后在@SentinelResource中指定。
- 创建CustomBlockHandler类用于自定义限流处理逻辑:
1 | |
- 在RateLimitController中使用自定义限流处理逻辑:
1 | |
熔断降级功能
除了流量控制以外,降低调用链路中的不稳定资源也是 Sentinel 的使命之一。由于调用关系的复杂性,如果调用链路中的某个资源出现了不稳定,最终会导致请求发生堆积。这个问题和 Hystrix 里面描述的问题是一样的。

Sentinel 和 Hystrix 的原则是一致的: 当调用链路中某个资源出现不稳定,例如,表现为 timeout,异常比例升高的时候,则对这个资源的调用进行限制,并让请求快速失败,避免影响到其它的资源,最终产生雪崩的效果。
Sentinel 支持对服务间调用进行保护,对故障应用进行熔断操作,这里我们使用RestTemplate来调用nacos-user-service服务所提供的接口来演示下该功能。
- 首先需要使用@SentinelRestTemplate来包装下RestTemplate实例:
1 | |
- 添加CircleBreakerController类,定义对nacos-user-service提供接口的调用:
1 | |
-
启动nacos-user-service和sentinel-service服务:
-
由于并没有在nacos-user-service中定义id为4的用户,所有访问如下接口会返回服务降级结果:http://localhost:8401/breaker/fallback/4
1 |
|
- 由于使用了exceptionsToIgnore参数忽略了NullPointerException,所以访问接口报空指针时不会发生服务降级:http://localhost:8401/breaker/fallbackException/2,返回 Whitelabel Error。
与Feign结合使用
Sentinel也适配了Feign组件,使用Feign进行服务间调用时,也可以使用Sentinel来进行熔断。
- 首先需要在pom.xml中添加Feign相关依赖:
1 | |
- 在application.yml中打开Sentinel对Feign的支持:
1 | |
-
在应用启动类上添加@EnableFeignClients启动Feign的功能;
-
创建一个UserService接口,用于定义对nacos-user-service服务的调用:
1 | |
- 创建UserFallbackService类实现UserService接口,用于处理服务降级逻辑:
1 | |
- 在UserFeignController中使用UserService通过Feign调用nacos-user-service服务中的接口:
1 | |
- 调用如下接口会发生服务降级,返回服务降级处理信息:http://localhost:8401/user/4
1 |
|
使用Nacos存储规则
默认情况下,当在Sentinel控制台中配置规则时,控制台推送规则方式是:通过API将规则推送至客户端并直接更新到内存中。一旦重启应用,规则将消失。
下面介绍下如何将配置规则进行持久化,以存储到Nacos为例。

-
首先直接在配置中心创建规则,配置中心将规则推送到客户端;
-
Sentinel控制台也从配置中心去获取配置信息。
功能演示
- 先在pom.xml中添加相关依赖:
1 | |
- 修改application.yml配置文件,添加Nacos数据源配置:
1 | |
- 在Nacos中添加配置:

- 添加配置信息如下:
1 | |
- 相关参数解释:
- resource:资源名称;
- limitApp:来源应用;
- grade:阈值类型,0表示线程数,1表示QPS;
- count:单机阈值;
- strategy:流控模式,0表示直接,1表示关联,2表示链路;
- controlBehavior:流控效果,0表示快速失败,1表示Warm Up,2表示排队等待;
- clusterMode:是否集群。
- 发现Sentinel控制台已经有了如下限流规则:

- 快速访问测试接口,可以发现返回了限流处理信息:

CircuitBreaker 断路器
CircuitBreaker的目的是保护分布式系统免受故障和异常,提高系统的可用性和健壮性。
- 当一个组件或服务出现故障时,CircuitBreaker会迅速切换到开放OPEN状态(保险丝跳闸断电),阻止请求发送到该组件或服务从而避免更多的请求发送到该组件或服务。
- 这可以减少对该组件或服务的负载,防止进一步崩溃,并使整个系统能够继续正常运行。
- 同时,还可以提高系统的可用性和健壮性,因为它可以在分布式系统的各个组件之间自动切换,从而避免单点故障的问题。
熔断(服务熔断+服务降级)
- CircuitBreaker只是一套规范和接口,落地实现者实际上是Resilience4J