目录
一、雪崩效应
二、Sentinel 服务容错
2.1 Sentinel容错思路
2.2 内部异常兼容
2.3 外部流量控制
三、Sentinel 项目搭建
四、Sentinel 工作原理
服务容错是微服务设计中一项重要原则和技术手段，主要目标是在服务出现故障、网络波动或其他不可预见的异常情况下，保证系统的稳定性和可靠性，防止局部故障引起雪崩效应，影响整个系统的正常运行。
下面首先看下，如果没有服务容错时，什么是服务雪崩。
一、雪崩效应
假如有一个微服务系统，这个系统由4个微服务组成，分别是 ABCD，这4个服务以集群的方式构成。如下图：
服务 A 会向服务 BC发起调用，而服务 BC 又会去调用服务 D，也就是说服务 ABC 都直接或间接的依赖服务 D。由于服务 D 底层依赖了数据库，有读写请求。如果服务 D 在进行 CRUD 时，执行了一个慢 SQL 语句，那么一次 DB 操作的执行时间会比较长。如果并发量比较小，这当然没什么问题，一旦并发量大了，堆积起来后，性能问题就会被逐渐放大。
这种情况下，数据库的连接资源就会被服务 D 迅速耗尽，进而导致服务D接口响应时间变长，接口超时的情况越来越多。由于上游请求还在源源不断的到达服务 D，所以接口超时情况会迅速传到到服务 B 和服务 C，进而又影响到服务 A，导致整个微服务集群不可用。
来自服务 D 的底层故障，如果不能得到有效处理，那么故障就会想滚雪球一样被迅速放大，进而出现服务雪崩。那么如何来防范服务雪崩呢？这时服务容错限流就登场了。
二、Sentinel 服务容错
Sentinel 是 Spring Cloud Alibaba 的一款服务容错组件，它是阿里巴巴双十一大促核心场景的保护神，内置了丰富的服务容错应用场景。它以流量作为切入点，通过各种内外防控手段达到维持服务稳定性的目的。
2.1 Sentinel 容错思路
就拿服务雪崩的场景来说，这种场景主要有两个主要因素：
- 一个是外部的流量突然增多，超过了集群的吞吐量。
- 另一个是内部各种未知异常导致的接口异常超时。
既然知道了这两个因素，那就分别来解决处理这两个因素。
2.2 内部异常兼容
在 Sentinel 中，我们可以采用降级和熔断的方式来处理内部异常。
所谓降级，当服务调用发生了响应超时、服务异常等情况时，在服务内部可以执行一段降级逻辑。
在降级逻辑中，你可以选择静默处理，即忽略掉异常继续处理后续业务逻辑，或者你可以返回一个让业务能继续进行下去的结果，还可以在降级逻辑中尝试、或者恢复异常服务。这里可以看出，降级针对的是单次服务调用异常而执行的逻辑。
所谓熔断，是指当异常调用量达到一定数量或判定条件，比如达到了一个设置的阈值、窗口时间内降级请求当道设置的阈值情况下，微服务在一段时间内停止对目标服务发起调用，所有来访请求直接执行降级逻辑。所以，熔断是多次服务调用异常累积的结果。
可以看出当服务进入了熔断状态以后，当前服务对下游的调用就停止了，这样一来就大大降低了对下游服务的压力。
关于熔断降级的设置，在主链路的服务商一定要设置，防止出现服务雪崩。关于降级的判定条件，需要结合压测数据来进行判定，以达到最佳的吞吐量。
2.3 外部流量控制
提到流量控制，一定会想到限流。没错，限流是流量整形方案的一种。在 Sentinel 中可以根据集群处理能力，为每个服务设置一个限流规则，从 QPS 维度或者并发线程数维度控制外部流量访问。一旦流量超过阈值，后续请求就会被"fast fail"，这时常用的方案。但 Sentinel 中不只这一种限流方案。
从流量整形整形效果来看，除了限流外，还可以再 Sentinel 中选择预热模型和排队模型。
- 预热模型：在一段时间内预热时间窗口，由低到高逐渐拉高流量阈值，直到达到最高的阈值为止。
- 排队模型：如果访问量超过了设置的阈值，服务请求不会被立即失败，而是放入一个队列中等待处理，如果服务请求在预设的超时时间内仍未被处理，就会被移除队列
限流的效果其实要好于熔断，熔断是请求已经进来了，但是处理不了，所以也会消耗系统资源，如 CPU 等。而限流是将请求挡在了服务的外面，它的投入产出比较高。
三、Sentinel 项目搭建
添加依赖
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>配置 Sentinel，在配置文件中配置 Sentinel 相关属性
spring.cloud.sentinel.transport.dashboard=localhost:8080启动 Sentinel 控制台，通过控制台来配置和管理 Sentinel 规则。
启动服务，此时会自动接入 Sentinel，并在控制台上能能看到应用作为数据源出现。这样请求过来就能根据配置进行限流了。
四、Sentinel 工作原理
先看下官方提供的流程图，可以看出请求流程。
在 Sentinel 世界中，万物都是可以被保护的"资源"，当一个外部请求想要访问 Sentinel 的资源时，便会创建一个 Entry 对象。每一个 Entry 对象都会经历好多环节，经过 Slot 链路的层层考验最终完成自己的业务逻辑，可以把 Slot 理解成一个个的 Filter，这是典型的职责链设计模式。
分布在 SlotChain 中的各个 Slot 各司其职，这些 Slot 通过相互配合的方式执行了各项检查任务。比如有的 Slot 负责数据统计，有的负责做限流降级处理。
在这些 Slot 中，有几个是被专门用来收集数据的。比如，NodeSelectorSlot 被用来构建当前请求的访问路径，它将上下游调用链串联起来，形成了一个服务调用关系的树状结构。而 ClusterBuilderSlot 和 StatisticSlot 这两个 Slot 会从多个维度统计一些运行期信息，比如接口响应时间、服务 QPS、当前线程数等等。
由这几个 Slot 统计出来的结果，会为后续的限流降级等 Sentinel 策略提供数据支持。比如说我想为指定的链路定义 QPS 维度的限流策略，那么这个限流策略在执行阶段就需要获取到这些统计数据，作为决策依据。
除此之外，Sentinel 的 Slot 机制也具备一定的扩展性，如果你想要添加一个自定义的 Slot，我们可以通过实现 ProcessorSlot 接口来完成，而且你还可以通过优先级调整各个 Slot 之间的执行顺序。
总的来说，Sentinel 是保障微服务架构稳定性和高可用性的关键组件，对于构建大型分布式系统来说尤为重要。通过它，可以更好地实现服务治理，降低系统风险，提升服务质量。
往期经典推荐
决胜微服务架构：OpenFeign轻量级REST客户端的魅力解析-CSDN博客
一文看懂Nacos如何实现高效、动态的配置中心管理-CSDN博客
Spring Cloud + Nacos 引领服务治理新航向-CSDN博客
Spring Cloud全方位解读——构建微服务架构的利器-CSDN博客
SpringBoot项目并发处理大揭秘，你知道它到底能应对多少请求洪峰？-CSDN博客
