一.雪崩问题及解决方案
1.雪崩问题--一个服务阻塞引起其他服务阻塞，造成越来越多的服务阻塞不可用
微服务中，服务间调用关系错综复杂，一个微服务往往依赖于多个其它微服务。
如图，如果服务提供者I发生了故障阻塞，当前的应用的部分业务因为依赖于服务I，因此也会被阻塞。此时，其它不依赖于服务I的业务似乎不受影响。
业务请求发生阻塞的原因有很多：
1.网络延迟：当客户端与服务端之间的网络延迟过高时，会导致请求阻塞。例如，当客户端等待从服务端获取响应时，如果网络延迟很高，则客户端将一直等待，直到超时或收到响应为止。
2.数据库操作：当业务请求需要对数据库进行读写操作时，如果数据库连接池中的连接被占满，就会导致请求阻塞，因为没有可用的连接来执行请求。
3.锁：当多个业务请求需要同时访问同一个资源时，例如同一个文件、同一个缓存或同一个数据库表，可能会出现锁竞争，导致请求阻塞。
4.过度消耗资源：当业务请求需要大量的计算或者消耗大量的内存或CPU资源时，系统可能无法及时响应其他请求，导致请求阻塞。
5.队列溢出：当业务请求的处理速度低于请求的到达速度时，请求队列可能会积累过多的请求，导致队列溢出，从而导致请求阻塞。
6.外部依赖：当业务请求依赖于其他服务或第三方库时，如果这些服务或库出现故障或响应缓慢，就会导致请求阻塞，直到这些服务或库返回响应为止。
但是，依赖服务I的业务请求被阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：
服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，那么当前服务也就不可用了。那么，依赖于当前服务的其它服务随着时间的推移，最终也都会变的不可用，形成级联失败，雪崩就发生了：
2.解决方法
解决雪崩问题的常见方式有四种：
【1】超时处理--超出时间返回错误信息
设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待
【2】线程隔离/仓壁模式--限制服务中每个业务能拥有的线程数
仓壁模式来源于船舱的设计：
船舱都会被隔板分离为多个独立空间，当船体破损时，只会导致部分空间进入，将故障控制在一定范围内，避免整个船体都被淹没。
调用者在调用服务提供者时，给每个调用的请求分配独立线程池，出现故障时，最多消耗这个线程池内资源，避免把调用者的所有资源耗尽 ，避免耗尽整个tomcat的资源，因此也叫线程隔离。
【3】熔断降级 /断路器--请求的数量超过异常的比例过高就熔断该服务【即拦击访问服务D的一切请求，直接报错】
断路器模式：由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。
断路器会统计访问某个服务的请求数量，当发现访问服务D的请求异常比例过高时，认为服务D有导致雪崩的风险，会拦截访问服务D的一切请求，形成熔断。
统计异常比例：
比例过高：
【4】限流--限制服务访问的每秒访问量
流量控制：限制业务访问的QPS，避免服务因流量的突增而故障。
3.总结
限流 是对服务的保护，避免因瞬间高并发流量而导致服务故障，进而避免雪崩。是一种预防措施。
超时处理、线程隔离、降级熔断 是在部分服务故障时，将故障控制在一定范围，避免雪崩。是一种补救措施。
二.服务保护技术对比
在SpringCloud当中支持多种服务保护技术。早期比较流行的是Hystrix框架，但目前国内实用最广泛的还是阿里巴巴的Sentinel框架，这里我们做下对比：
| Sentinel | Hystrix | |
|---|---|---|
| 隔离策略 | 信号量隔离 | 线程池隔离/信号量隔离 |
| 熔断降级策略 | 基于慢调用比例或异常比例 | 基于失败比率 |
| 实时指标实现 | 滑动窗口 | 滑动窗口（基于 RxJava） |
| 规则配置 | 支持多种数据源 | 支持多种数据源 |
| 扩展性 | 多个扩展点 | 插件的形式 |
| 基于注解的支持 | 支持 | 支持 |
| 限流 | 基于 QPS，支持基于调用关系的限流 | 有限的支持 |
| 流量整形 | 支持慢启动、匀速排队模式 | 不支持 |
| 系统自适应保护 | 支持 | 不支持 |
| 控制台 | 开箱即用，可配置规则、查看秒级监控、机器发现等 | 不完善 |
| 常见框架的适配 | Servlet、Spring Cloud、Dubbo、gRPC 等 | Servlet、Spring Cloud Netflix |
三.Sentinel的功能
1.簇点链路
当请求进入微服务时，首先会访问DispatcherServlet，然后进入Controller、Service、Mapper，这样的一个调用链就叫做簇点链路 。簇点链路中被监控的每一个接口就是一个资源。
默认情况下sentinel会监控SpringMVC的每一个端点（Endpoint，也就是controller中的方法），因此SpringMVC的每一个端点（Endpoint）就是调用链路中的一个资源。
Restful风格的API请求路径一般都相同，这会导致簇点资源名称重复。因此我们要修改配置，把请求方式+请求路径作为簇点资源名称：
流控、熔断等都是针对簇点链路中的资源来设置的，因此我们可以点击对应资源后面的按钮来设置规则：
(1)流控：接口流量控制，根据接口控制每秒的访问量；
还可以进行线程隔离，控制每个服务的最大线程数量
(2)降级：降级熔断
(3)热点：热点参数限流，根据接口参数值出现频率控制每秒的访问量
(4)授权：请求的权限控制
2.流控
点击流控，进行设置，介绍一下里面提供的功能。
1.流控模式 ：在添加限流规则时，点击高级选项，可以选择三种流控模式 ：
【1】直接：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式
【2】关联：统计与当前资源相关的另一个资源，当另一个资源触发阈值时，对当前资源限流
两个资源又竞争关系，对高优先级资源触发阈值，对低优先级资源限流。
比如用户支付时需要修改订单状态，同时用户要查询订单。查询和修改操作会争抢数据库锁，产生竞争。业务需求是优先支付和更新订单的业务，因此当修改订单业务触发阈值时，需要对查询订单业务限流。
【3】链路：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流
2.流控效果 是指请求达到流控阈值时应该采取的措施，包括三种：
【1】快速失败：QPS超过阈值时，拒绝新的请求
【2】warm up： QPS超过阈值时，拒绝新的请求；QPS阈值是逐渐提升的，可以避免冷启动时高并发导致服务宕机。
阈值一般是一个微服务能承担的最大QPS，但是一个服务刚刚启动时，一切资源尚未初始化（冷启动 ），如果直接将QPS跑到接近最大阈值，也可能导致服务瞬间宕机。
warm up也叫预热模式 ，是应对服务冷启动的一种方案。请求阈值初始值是 maxThreshold / coldFactor，持续指定时长后，逐渐提高到maxThreshold值。而coldFactor的默认值是3.
例如，设置QPS的maxThreshold为10，预热时间为5秒，那么初始阈值就是 10 / 3 ，也就是3，然后在5秒后逐渐增长到10.
【3】排队等待：请求会进入队列，按照阈值允许的时间间隔依次执行请求；如果请求预期等待时长大于超时时间，直接拒绝。
例如：QPS = 5，意味着每200ms处理一个队列中的请求；timeout = 2000，意味着预期等待时长 超过2000ms的请求会被拒绝并抛出异常。
那什么叫做预期等待时长呢？
比如现在一下子来了12 个请求，因为每200ms执行一个请求，那么：
第6个请求的预期等待时长 = 200 * （6 - 1） = 1000ms
第12个请求的预期等待时长 = 200 * （12-1） = 2200ms
现在，第1秒同时接收到10个请求，但第2秒只有1个请求，此时QPS的曲线这样的：
如果使用队列模式做流控，所有进入的请求都要排队，以固定的200ms的间隔执行，QPS会变的很平滑：
平滑的QPS曲线，对于服务器来说是更友好的。
3.热点参数限流
之前的限流是统计访问某个资源的所有请求，判断是否超过QPS阈值。而热点参数限流是分别统计参数值相同的请求，判断是否超过QPS阈值。
1.全局参数限流
例如，一个根据id查询商品的接口：
访问/goods/{id}的请求中，id参数值会有变化，热点参数限流会根据参数值分别统计QPS，统计结果：
当id=1的请求触发阈值被限流时，id值不为1的请求不受影响。
配置示例：
代表的含义是：对hot这个资源的0号参数（第一个参数）做统计，每1秒相同参数值的请求数不能超过5
2.热点参数限流
刚才的配置中，对查询商品这个接口的所有商品一视同仁，QPS都限定为5.
而在实际开发中，可能部分商品是热点商品，例如秒杀商品，我们希望这部分商品的QPS限制与其它商品不一样，高一些。那就需要配置热点参数限流的高级选项了：
结合上一个配置，这里的含义是对0号的long类型参数限流，每1秒相同参数的QPS不能超过5，有两个例外：
如果参数值是100，则每1秒允许的QPS为10
如果参数值是101，则每1秒允许的QPS为15
3.注意事项
热点参数限流对默认的SpringMVC资源无效，需要利用@SentinelResource注解标记资源
再对该资源进行热点参数限流.
4.隔离和降级
限流是一种预防措施，虽然限流可以尽量避免因高并发而引起的服务故障，但服务还会因为其它原因而故障。
而要将这些故障控制在一定范围，避免雪崩，就要靠线程隔离 （舱壁模式）和熔断降级手段了。
可以看到，不管是线程隔离还是熔断降级，都是对客户端 （调用方）的操作。需要在调用方 发起远程调用时做线程隔离、或者服务熔断。
而我们的微服务远程调用都是基于Feign来完成的，因此我们需要将Feign与Sentinel整合，在Feign里面实现线程隔离和服务熔断。
1.Feign整合Sentinel的步骤
在application.yml中配置：feign.sentienl.enable=true
补充 ：Feign异常处理
业务失败后，一般不会直接报错，而是对报错进行处理，返回用户一个友好提示或者默认结果，这个就是失败降级逻辑。
给FeignClient编写失败后的降级逻辑
①方式一：FallbackClass，无法对远程调用的异常做处理
②方式二：FallbackFactory，可以对远程调用的异常做处理
具体讲讲第二种：
给FeignClient编写FallbackFactory并注册为Bean
将FallbackFactory配置到FeignClient
2.线程隔离
线程隔离有两种方式实现：
【1】线程池隔离：给每个服务调用业务分配一个线程池，利用线程池本身实现隔离效果
【2】信号量隔离（Sentinel默认采用）：不创建线程池，而是计数器模式，记录业务使用的线程数量，达到信号量上限时，禁止新的请求。
信号量隔离的特点是？
基于计数器模式，简单，开销小
线程池隔离的特点是？
基于线程池模式，有额外开销，但隔离控制更强
实现方式：在feign接口的资源点击流控，设置线程数。
3.熔断降级
熔断降级是解决雪崩问题的重要手段。其思路是由断路器 统计服务调用的异常比例、慢请求比例，如果超出阈值则会熔断该服务。即拦截访问该服务的一切请求；而当服务恢复时，断路器会放行访问该服务的请求。
1.断路器控制熔断和放行是通过状态机来完成的。
状态机包括三个状态：
【1】closed：关闭状态，断路器放行所有请求，并开始统计异常比例、慢请求比例。超过阈值则切换到open状态
【2】open：打开状态，服务调用被熔断 ，访问被熔断服务的请求会被拒绝，快速失败，直接走降级逻辑。Open状态5秒后会进入half-open状态
【3】half-open：半开状态，放行一次请求，根据执行结果来判断接下来的操作。
如果请求成功，则切换到closed状态。如果请求失败：则切换到open状态
2.断路器熔断策略有三种：慢调用、异常比例、异常数
慢调用 ：业务的响应时长（RT）大于指定时长的请求认定为慢调用请求。在指定时间内，如果请求数量超过设定的最小数量，慢调用比例大于设定的阈值，则触发熔断。
异常比例或异常数：统计指定时间内的调用，如果调用次数超过指定请求数，并且出现异常的比例达到设定的比例阈值（或超过指定异常数），则触发熔断。
5.授权规则
授权规则可以对请求方来源做判断和控制。
授权规则可以对调用方的来源做控制，有白名单和黑名单两种方式。
白名单：来源（origin）在白名单内的调用者允许访问
黑名单：来源（origin）在黑名单内的调用者不允许访问
点击左侧菜单的授权，可以看到授权规则：
资源名：就是受保护的资源，例如/order/{orderId}
流控应用：是来源者的名单，如果是勾选白名单，则名单中的来源被许可访问；如果是勾选黑名单，则名单中的来源被禁止访问。
比如：
我们允许请求从gateway到order-service，不允许其他请求不通过网关直接访问order-service，那么白名单中就要填写网关的来源名称（origin）。
步骤：在网关中添加过滤器对每个请求添加名为origin，值为gateway的请求头；sentinel获取请求头判断是否值为gateway【重写RequestOriginParser接口】。
四.其他
1.sentinel异常处理
java
@Component
public class SentinelExceptionHandler implements BlockExceptionHandler {
@Override
public void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception {
String msg = "未知异常";
int status = 429;
if (e instanceof FlowException) {
msg = "请求被限流了";
} else if (e instanceof ParamFlowException) {
msg = "请求被热点参数限流";
} else if (e instanceof DegradeException) {
msg = "请求被降级了";
} else if (e instanceof AuthorityException) {
msg = "没有权限访问";
status = 401;
}
response.setContentType("application/json;charset=utf-8");
response.setStatus(status);
response.getWriter().println("{\"msg\": " + msg + ", \"status\": " + status + "}");
}
}2.规则持久化
现在，sentinel的所有规则都是内存存储，重启后所有规则都会丢失。在生产环境下，我们必须确保这些规则的持久化，避免丢失。
规则是否能持久化，取决于规则管理模式，sentinel支持三种规则管理模式：
1.原始模式：Sentinel的默认模式，将规则保存在内存，重启服务会丢失。
2.pull模式：控制台将配置的规则推送到Sentinel客户端，而客户端会将配置规则保存在本地文件或数据库中。以后会定时去本地文件或数据库中查询，更新本地规则
3.push模式：控制台将配置规则推送到远程配置中心，例如Nacos。Sentinel客户端监听Nacos，获取配置变更的推送消息，完成本地配置更新
