一、雪崩问题🍉

(一) 什么是雪崩🥝

微服务调用链路中的某个服务故障，引起整个链路中的所有微服务都不可用，这就是雪崩。服务D故障引起服务A故障，服务A引起其他服务故障，渐渐导致所有微服务都不可用。有人说，服务A在向服务D发送请求的时候，设置连接超时不就可以了吗？要知道，在高并发的情况下，设置连接超时是不可取的，所以还是会导致雪崩现象。

微服务调用链路中的某个服务故障，引起整个链路中的所有微服务都不可用，这就是雪崩。

(二)解决雪崩问题🥝

解决雪崩问题的常见方式有四种：

1、超时处理：🍓

设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止地等待。
但是这种解决方案只是缓解了雪崩问题，并不能解决雪崩问题。因为请求的超时时间设置为1s，也就是说每秒释放一个请求，但在高并发的情况下，假设每秒请求是2个，那么在一定的时间内，也会导致服务A不可用，最终导致雪崩问题的出现。所以说这种解决方案只是缓解雪崩问题。

2、舱壁模式：🍓

限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离。它是通过划分tomcat的资源，划分tomcat的线程，让每个业务最多使用n个线程，进而提高tomcat的容灾能力。但是这种模式会导致一定的资源浪费，比如，服务C已经宕机，但每次还是会尝试让服务A去向服务C发送请求。

3、熔断降级：🍓

有断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。
请求失败占比达到阈值后，这个时候会出现熔断，此后服务A向服务D不能发送请求，请求直接在服务A给拦截。

4、流量控制：🍓

限制业务访问的QPS，避免服务因为流量的突增而故障。这种是从预防层面来解决雪崩问题。Sentinel可以根据服务所能接收的访问频率，向服务发送请求，避免服务出现故障，就不会出现故障转移，也就避免了雪崩问题。也就是将大量的请求一点点的发送给服务，从而预防了雪崩问题。

二、服务保护技术对比🍉

三、Sentinel介绍和安装🍉

（一）初始Sentinel🥝

Sentinel是阿里巴巴开源的一款微服务流量控制组件。官网地址：https://sentinelguard.io/zh-cn/index.html

Sentinel 具有以下特征:

• 丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
• 完备的实时监控：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。
• 广泛的开源生态：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。
• 完善的 SPI 扩展点：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。

（二）安装Sentinel控制台🥝

1、下载
sentinel官方提供了UI控制台，方便我们对系统做限流设置。大家可以在GitHub下载。

2、运行
将jar包放到任意非中文目录，执行命令：

java -jar sentinel-dashboard-1.8.1.jar

java -Dserver.port=8090 -jar sentinel-dashboard-1.8.1.jar

3.然后访问：localhost:8080 即可看到控制台页面，默认的账户和密码都是sentinel

四、微服务整合Sentinel🍉

1、在微服务中引入Sentinel依赖：🥝

 <!--sentinel 依赖-->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
        </dependency>
        

2、配置控制台地址：🥝

#配置sentinel微服务保护地址
spring.cloud.sentinel.transport.dashboard=localhost:8090

3、访问微服务的任意端点，触发Sentinel监控🥝