关于容错组件的停更/升级/替换

服务降级：

• Hystrix ：官网不极力推荐，但是中国企业中还在大规模使用,对于限流和熔断降级虽然在1.5版本官方还支

（版本稳定），但现在官方已经开始推荐大家使用Resilience4j

• Resilience4J ：官网推荐使用，但是国内很少用这个。
• Sentienl ：来自于Spring Cloud ??ibaba，在中国企业替换Hystrix的组件，国内强烈建议使用

流量与容错管理之Hystrix

Hystrix概述

1. Hystrix简介

Hystrix是Netflix公司的一个开源项目，在分布式环境中，许多服务依赖项中的一些必然会失败，Hystrix主要作用是通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力，而有效减少微服务中雪崩发生 ， 提高系统的整体性能。

2. Hystrix工作原理

Hystrix Metrics解释：

Metrics中保存了当前服务的健康状况,包括服务调用总次数和服务调用失败次数等. 根据Metrics的计数, 熔断器从而能计算出当前服务的调用失败率, 用来和设定的阈值比较从而决定熔断器的状态和切换逻辑.

3. Hystrix业务能力

熔断

• 当应用(B)无法提供服务时，对上游请求熔断
• A---call--B,B不可用，直接熔断B
• B不可用、qps、失败率

降级

• 降级与熔断紧密相关，当边缘业务不再提供服务的时候；直接下线，通过fallback响应；即为服务降级

隔离

• 实现请求隔离算法是线程池或信号量
• Hystrix在用户请求和服务之间加入了线程池，如果线程池已满调用将被立即拒绝（降级后进入fallback）
• 信号隔离也可以用于限制并发访问（熔断进入fallback）

限流

• 当对服务进行限流时，超过的流量将直接 Fallback，即熔断。
• 这里的限流是针对熔断的具体描述

熔断VS降级

相同点：

• 目标一致 都是从可用性和可靠性出发，为了防止系统崩溃；
• 熔断与降级都需要fallback

不同点：

• 触发原因不同 服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑

雪崩效应介绍

1.下图主要描述了产生雪崩效应的流程图

（AB不可用）

• B服务调用A服务，A服务不可用，导致B服务不停重试和阻塞，最后B服务变为不可用

（系统不可用）

• c服务调用B服务，B服务不可用，导致C服务不停重试和阻塞，最后C服务变为不可用

至此，所有服务均不可用，产生了服务雪崩效应

雪崩形成大致可以分成三个阶段（造成雪崩的原因）：

服务提供者不可用

• 用户大量请求：在秒杀和大促开始前,如果准备不充分,用户发起大量请求也会造成服务提供者的不可用.

重试加大流量

• 用户重试：在服务提供者不可用后, 用户由于忍受不了界面上长时间的等待,而不断刷新页面甚至提交表单.
• 代码逻辑重试：服务调用端的会存在大量服务异常后的重试逻辑.

服务调用者不可用

• 同步等待造成的资源耗尽: 当服务调用者使用 同步调用 时, 会产生大量的等待线程占用系统资源. 一旦线程资源被耗尽,服务调用者提供的服务也将处于不可用状态, 于是服务雪崩效应产生了.

雪崩场景

在微服务系统中， 一个用户请求可能需要调用几个服务才能完成。

如下图，在所有的服务都处于可用状态时， 一个用户请求需要调用A 、H 、I 和P 服务。

当某一个服务，例如服务I，出现网络延迟或者故障时，即使服务A 、H 和P 可用，由于服务I 的不可用，整个用户请求会处于阻塞状态，并等待服务I 的响应（如下图）。

Hystrix降级处理

降级应用场景：

• 人工降级 ：秒杀、双11的时候主动降级（确保核心业务、边缘业务降级）
• 超时

1.创建模块

创建nacos-ribbon-client 模块，使用Ribbon+RestTemplate中使用Hystrix

2. 引入起步依赖

3. 修改application.yml

4. 启动熔断器

5. 创建RibbonConfig配置类

6. 创建RibbonController类

1、超时引发的降级（try里面）

2、积分服务停止也可以引发降级

7、积分服务代码

8. 启动

分别启动 nacos-client-hystrix、nacos-ribbon-client，如下图

9. 访问

Hystrix熔断处理

典型的场景

• 请求量激增（单位时间内qps达到峰值）
• 出现异常
• 调用的失败率过大（动态计算）

1）场景：并发15流量限制

场景: 通过coreSize设置接口的并发数据为15；如果并发流量为20个，那么其他5个并发则进入降级

修改上面的 例子

• com.itheima.hystrix.service.RibbonService增加方法
• 修改HystrixCommand注解

jmeter设置

设置并发20

修改端口

清泉路径

开始执行

流量与容错管理之Sentinel

Sentinel 概述

概述

Sentinel是阿里开源的项目，提供了流量控制、熔断降级、系统负载保护等多个维度来保障服务之间的稳定性。

Sentinel的流控操作起来非常简单，在控制台进行配置即可看见效，所见即所得

官网

https://github.com/alibaba/Sentinel

中文

https://github.com/alibaba/Sentinel/wiki/%E4%BB%8B%E7%BB%8D

https://sentinelguard.io/zh-cn/docs/introduction.html

Sentinel 的使用可以分为两个部分:

• 核心库（Java 客户端）： 不依赖任何框架/库，能够运行于 Java 7 及以上的版本的运行时环境，同时对Dubbo / Spring Cloud 等框架也有较好的支持。
• 控制台（Dashboard） ：控制台主要负责管理推送规则、监控、集群限流分配管理、机器发现等

差异化

构建Sentinel控制台

Sentinel构建方式：

1、可以从 release 页面 下载最新版本的控制台 jar 包。

2、也可以从最新版本的源码自行构建 Sentinel 控制台：

• 下载 控制台 工程
• 使用以下命令将代码打包成一个 fat jar: mvn clean package

1、Sentinel使用Jar构建

2、Sentinel启动

• Dserver.port 指定控制台的端口
• -Dcsp.sentinel.dashboard.server 指定控制台的地址，相当于自己注册自己，这样启动后就能看到自身的信息，向sentinel-
• dashboard控制台发送心跳包的sentinel-dashboard控制台地址
• -Dproject.name指定接入的应用名称

从 Sentinel 1.6.0 起，Sentinel 控制台引入基本的 登录 功能，默认用户名和密码都是 sentinel

3、访问

默认用户名密码为sentinel sentinel

SpringCloud集成Sentinel

1、引入起步依赖

2、配置控制台

• spring.cloud.sentinel.transport.dashboard :配置sentinel dashboard的访问地址
• spring.cloud.sentinel.transport.port 应用与Sentinel控制台交互的端口

3、新增控制器

Sentinel加载项目，需要项目访问api发送心跳才能加载

此处先写一个简单的API

执行

4、打开sentinel

流量与过载保护规则

1) 流控规则案例

场景：演示下流控规则比较典型、企业级常用的几个组合

点击 【新增流控规则】

流控规则总体介绍

1、资源名： 唯一名称，默认请求路径，表示对该资源进行流控

2、针对来源 ： Sentinel可以针对调用者进行限流，填写微服务名，默认default（不区分来源）

3、阈值类型/单击阈值 ：

• QPS（每秒钟的请求数量）：当调用该api的QPS达到阈值时，进行限流
• 线程数：当调用该线程数达到阈值的时候，进行限流

4.是否集群 ：不需要集群

5.流控模式：

• 直接： api达到限流条件时，直接限流
• 关联： 当关联的资源达到阈值时，就限流自己

• 链路： 只记录指定链路上的流量（指定资源从入口资源进来的流量，如果达到阈值，就进行限流）【api级别的针对来源】

6.流控效果：

• 快速失败： 直接失败，抛异常
• Warm Up： 根据codeFactor（冷加载因子，默认3）的值，经过预热时长，才达到设置的QPS阈值
• 排队等待： 匀速排队，让请求以匀速的速度通过，阈值类型必须设置为QPS，否则无效

2) 降级规则案例

1、RT（平均响应时间）

平均响应时间 (DEGRADE_GRADE_RT)：当 1s 内持续进入 N 个请求，平均响应时间（秒级）均超过阈值（count，以 ms 为单位），那么在接下的时间窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个方法的调用都会自动地熔断（抛出 DegradeException）。

2、异常比例

异常比例(秒级)： 当资源的请求每秒请求量>=5，并且每秒异常总数占通过的比例超过阈值的时候，开始进入降级状态

在下面的时间窗口内，对这个方法的调用都会被限流中。，异常比例的的阈值范围（0.0-1.0）代表0%---100%

3、异常数

当资源近1分钟的异常数超过阈值之后会进行降级。

3) 热点规则案例

热点 ：即经常访问的数据

很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据，并对其访问进行限制。比如：

• 商品 ID 为参数，统计一段时间内最常购买的商品 ID 并进行限制
• 用户 ID 为参数，针对一段时间内频繁访问的用户 ID 进行限制

编辑热点规则

• 参数索引： 表示对下标第0个参数进行限流
• 单机阈值： 这里限流的qps为1
• 统计窗口时长： 统计的 时间长度（时间窗口内发生了多少qps）

4) 系统规则案例

• Load是负载 ，只有在linux机器上才会生效。根据当前系统的负载来决定是不是触发保护。
• RT ：这个应用上所有的流量的平均的响应时间，也就是平均响应时间超过一个值，那么停止接收新的请求，
• 线程数 ：所有服务访问的线程数加起来
• 入口qps ：所有服务的qps加起来达到一个值
• cpu使用率 ：cpu的使用率超过一个百分比，

5) 授权规则案例

黑白名单规则（AuthorityRule）非常简单，主要有以下配置项：

• resource：资源名，即限流规则的作用对象
• 流控应用 ：对应的黑名单/白名单，不同 origin 用 , 分隔，如 appA,appB，default，代表不区分调用来源
• 流控应用 这个位置要填写的是来源标识，Sentinel提供了 RequestOriginParser 接口来处理来源。只要Sentinel保护的接口资源被访问，Sentinel就会调用 RequestOriginParser 的实现类去解析访问来源
• 授权类型 ：黑白名单

Sentinel规则持久化

Sentinel持久化到Nacos

Sentinel Dashboard中添加的规则是存储在内存中的，只要项目一重启规则就丢失了

此处将规则持久化到nacos中，在nacos中添加规则，然后同步到dashboard中；

1、导入起步依赖

2.在application.properties中配置sentinel-nacos信息

• spring.cloud.sentinel.datasource.ds1.nacos.server-addr ：nacos的访问地址，，根据上面准备工作中启动的实例配置
• spring.cloud.sentinel.datasource.ds1.nacos.groupId ：nacos中存储规则的groupId
• spring.cloud.sentinel.datasource.ds1.nacos.data-Id ：nacos中存储规则的dataId
• spring.cloud.sentinel.datasource.ds1.nacos.rule-type ：该参数是spring cloud alibaba升级到0.2.2之后增加的配置，用来定义存储的规则类型。所有的规则类型可查看枚举类：
• org.springframework.cloud.alibaba.sentinel.datasource.RuleType ，每种规则的定义格式可以通过各枚举值中定义的规则对象来查看，比如限流规则可查看：com.alibaba.csp.sentinel.slots.block.flow.FlowRul

com.alibaba.cloud.sentinel.datasource.RuleType

3、nacos增加配置

sentinel-nacos-config-stream

4、重启后访问Sentinel

访问几次接口之后，就可以在Sentinel Dashboard 中看到在nacos中配置的规则信息了，并且项目服务重启依然存在