微服务韧性工程：利用Sentinel实施有效服务容错与限流降级

       

目录

一、雪崩效应

二、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博客