在微服务架构里，我们经常把“熔断、限流、降级”这三兄弟放在一起讨论。而熔断，作为保障系统可用性的关键一环，是每个后端工程师都必须掌握的核心技能。你不仅要懂它是什么，更要能说清楚，在实战中你是如何利用它来拯救你的系统的。

熔断的本质：一种“舍车保帅”的智慧

首先，什么是熔断？在微服务世界里，当一个下游服务因为自身问题（比如负载过高、程序Bug）变得不稳定时，熔断机制会介入，在一段时间内主动切断对这个服务的调用，直接返回一个错误，直到该服务恢复正常。

常见的负载均衡算法

轮询法(Round Robin)

将请求按顺序轮流地分配到后端服务器上，它均衡地对待后端的每一台服务器，而不关心服务器实际的连接数和当前的系统负载。

加权轮询法(Weight Round Robin)

不同的后端服务器可能机器的配置和当前系统的负载并不相同，因此它们的抗压能力也不相同。给配置高、负载低的机器配置更高的权重，让其处理更多的请；而配置低、负载高的机器，给其分配较低的权重，降低其系统负载，加权轮询能很好地处理这一问题，并将请求顺序且按照权重分配到后端。

随机法(Random)

固定窗口限流算法

固定窗口限流算法（Fixed Window Rate Limiting Algorithm）是一种最简单的限流算法，其原理是在固定时间窗口(单位时间)内限制请求的数量。该算法将时间分成固定的窗口，并在每个窗口内限制请求的数量。具体来说，算法将请求按照时间顺序放入时间窗口中，并计算该时间窗口内的请求数量，如果请求数量超出了限制，则拒绝该请求。

假设单位时间(固定时间窗口)是1秒，限流阀值为3。在单位时间1秒内，每来一个请求,计数器就加1，如果计数器累加的次数超过限流阀值3，后续的请求全部拒绝。等到1s结束后，计数器清0，重新开始计数。如下图：

请求限流

滑动窗口的实现

实现

LeapArray

Sentinel 中滑动窗口算法的核心类，先了解一下他的核心成员变量

public abstract class LeapArray<T> {
 //毫秒时间周期，默认60*1000，例如计算QPS时，为1000
    protected int intervalInMs;
 //窗口数量，默认60
    protected int sampleCount;
//窗口时间长度，毫秒数，默认1000ms 该值 = intervalInMs / sampleCount
    protected int windowLengthInMs;
 
 // 存储时间窗口的数组
    protected final AtomicReferenceArray<WindowWrap<T>> array;
 
    public LeapArray(int sampleCount, int intervalInMs) {
        AssertUtil.isTrue(sampleCount > 0, "bucket count is invalid: " + sampleCount);
        AssertUtil.isTrue(intervalInMs > 0, "total time interval of the sliding window should be positive");
        AssertUtil.isTrue(intervalInMs % sampleCount == 0, "time span needs to be evenly divided");

        this.windowLengthInMs = intervalInMs / sampleCount;
        this.intervalInMs = intervalInMs;
        this.sampleCount = sampleCount;
  
        this.array = new AtomicReferenceArray<>(sampleCount);
    } 

}

在微服务架构中，服务与服务之间通过远程调用的方式进行通信，一旦某个被调用的服务发生了故障，其依赖服务也会发生故障，此时就会发生故障的蔓延，最终导致灾难性雪崩效应。服务保护就是为了保证服务的稳定性而出生的一套保护方案

雪崩问题

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