Sentinel学习圣经：从入门到精通 Sentinel，最全详解 (40+图文全面总结)

尼恩说在前面

在40岁老架构师 尼恩的读者交流群(50+)中，最近有小伙伴拿到了一线互联网企业如得物、阿里、滴滴、极兔、有赞、希音、百度、网易、美团的面试资格，并且拿了很多大厂offer。

面试过程中，其中 SpringCloud 工业级底座 相关的题目，是大家的面试核心，面试重点。

比如小伙伴在面试蚂蚁的时候，就遇到以下面试题：

Sentinel熔断降级，是如何实现的？

Sentinel底层滑动时间窗限流算法怎么实现的？

小伙伴由于之前没有系统的去梳理和总结，所以支支吾吾的说了几句，面试官不满意，面试挂了。

所以，尼恩给大家做一下系统化、体系化的梳理，联合社群小伙伴，来一个Sentinel学习圣经：从入门到精通Sentinel。

特别说明， 本文属于 穿透 SpringCloud 工业级 底座工程(一共包括 15大学习圣经 )的 其中之一，并且，此系列15大学习圣经底座正在录制视频， 帮助大家一举成为技术高手。

15大圣经 ，使得大家内力猛增，可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”，然后实现”offer直提”。

尼恩团队 从0到1 大实战 SpringCloud 工业级底座 的 知识体系的轮廓如下，详情请点击：15大圣经的介绍：

其中，专题1 权限设计以及 安全认证相关的两个圣经，具体如下：

• SpringSecurity& Auth2.0 学习圣经：从入门到精通 SpringSecurity& Auth2.0
• 史上最牛的 权限系统，如何设计？来了一个 Sa-Token学习圣经

其中，专题3为：注册发现治理架构： Nacos 学习圣经，具体如下：

• Nacos学习圣经：从入门到精通 Nacos，最全详解 (30+图文全面总结)

其中，专题 5为RPC治理架构 Dubb3.0，具体如下：

• Dubbo学习圣经：从入门到精通 Dubbo3.0 + SpringCloud

本文，就是 Sentinel 学习圣经。稍后会录制视频。录完之后，Sentinel 学习圣经 正式版本会有更新， 最新版本找尼恩获取。

本学习圣经开始之前，先看两个相关的Sentinel大厂面试题：

阿里面试真题：Sentinel熔断降级，是如何实现的？

在40岁老架构师 尼恩的读者交流群(50+)中，最近有小伙伴拿到了一线互联网企业如阿里、滴滴、极兔、有赞、希音、百度、网易、美团的面试资格，遇到很多很重要的面试题：

问题1：Sentinel高可用熔断降级，是如何实现的？

问题2：Sentinel底层滑动时间窗限流算法怎么实现的？

最近又有小伙伴在面试阿里，遇到了相关的面试题。

在这里，借助《Sentinel 学习圣经》尼恩给大家做一下系统化、体系化的Sentinel 梳理，使得大家内力猛增，展示一下雄厚的 “技术肌肉、技术实力”，让面试官爱到 “不能自已、口水直流”，然后实现”offer直提，offer自由”。

首先给面试官来一个 总体的介绍：

在微服务架构中，Sentinel 作为一种流量控制、熔断降级和服务降级的解决方案，得到了广泛的应用。

Sentinel是一个开源的流量控制和熔断降级库，用于保护分布式系统免受大量请求的影响。

然后，尼恩建议大家，从以下的几个维度去全面介绍Sentinel ：

第一个维度，Sentinel主要功能：

一：熔断机制

1. Sentinel使用滑动窗口统计请求的成功和失败情况。这些统计信息包括成功的请求数、失败的请求数等。
2. 当某个资源（例如一个API接口）的错误率超过阈值或其他指标达到预设的条件，Sentinel将触发熔断机制。
3. 一旦熔断触发，Sentinel将暂时阻止对该资源的请求，防止继续失败的请求对系统造成更大的影响。

二：降级机制

1. Sentinel还提供了降级机制，可以在资源负载过重或其他异常情况下，限制资源的访问速率，以保护系统免受过多的请求冲击。
2. 降级策略可以根据需要定制，可以是慢调用降级、异常比例降级等。

三：高可用性机制

Sentinel的高可用性主要通过以下方式来实现：

a. 多节点部署：将Sentinel配置为多节点部署，确保即使一个节点发生故障，其他节点仍然能够继续工作。

b. 持久化配置：Sentinel支持将配置信息持久化到外部存储，如Nacos、Redis等。这样，即使Sentinel节点重启，它可以加载之前的配置信息。

c. 集群流控规则：Sentinel支持集群流控规则，多个节点可以共享流量控制规则，以协同工作来保护系统。

d. 实时监控：Sentinel提供了实时监控和仪表板，可以查看系统的流量控制和熔断降级情况，帮助及时发现问题并采取措施。

四：自适应控制

Sentinel具有自适应控制的功能，它可以根据系统的实际情况自动调整流量控制和熔断降级策略，以适应不同的负载和流量模式。

总的来说，Sentinel的高可用性熔断降级机制是通过多节点部署、持久化配置、实时监控、自适应控制等多种手段来实现的。

这使得Sentinel能够在分布式系统中保护关键资源免受异常流量的影响，并保持系统的稳定性和可用性。

那么，Sentinel是如何实现这些功能的呢？在说说 Sentinel 的基本组件。

第二个维度， Sentinel 的基本组件：

Sentinel 主要包括以下几个部分：资源（Resource）、规则（Rule）、上下文（Context）和插槽（Slot）。

• 资源是我们想要保护的对象，比如一个远程服务、一个数据库连接等。
• 规则是定义如何保护资源的，比如我们可以通过设置阈值、时间窗口等方式来决定何时进行限流、熔断等操作。
• 上下文是一个临时的存储空间，用于存储资源的状态信息，比如当前的 QPS 等。
• 插槽属于责任链模式中的处理器/过滤器， 完成资源规则的计算和验证。

第三个维度， Sentinel 的流量治理几个核心步骤：

在 Sentinel 的运行过程中，主要分为以下几个核心步骤：

1. 资源注册：当一个资源被创建时，需要将其注册到 Sentinel。在注册过程中，会为资源创建一个对应的上下文，并将资源的规则存储到插槽中。
2. 流量控制：当有请求访问资源时，Sentinel 会根据资源的规则进行流量控制。如果当前 QPS 超过了规则设定的阈值，Sentinel 就会拒绝请求，以防止系统过载。
3. 熔断降级：当资源出现异常时，Sentinel 会根据规则进行熔断或降级处理。熔断是指暂时切断对资源的访问，以防止异常扩散。降级则是提供一种备用策略，当主策略无法正常工作时，可以切换到备用策略。
4. 规则更新：在某些情况下，我们可能需要动态调整资源的规则。Sentinel 提供了 API 接口，可以方便地更新资源的规则。

通过以上分析，我们可以看出，Sentinel 的核心思想是通过规则来管理和控制资源。这种设计使得 Sentinel 具有很强的可扩展性和灵活性。我们可以根据业务需求，定制各种复杂的规则。

第四个维度， Sentinel 的源码层面的两个核心架构：

回到源码层面，在 Sentinel 源码，包括以下二大架构：

• 责任链模式架构
• 滑动窗口数据统计架构

尼恩说明： 两大架构的源码，简单说说就可以了，具体可以参见《Sentinel 学习圣经》 最新版本。

总指挥，Sentinel 是一种非常强大的流量控制、熔断降级和服务降级的解决方案。 已经成为了替代Hystrix的主要高可用组件。

说在最后： “offer自由” 很容易的

Java Agent、Instrumentation、arthas 相关的面试题，是非常常见的面试题。

以上的内容，如果大家能对答如流，如数家珍，基本上 面试官会被你 震惊到、吸引到。

最终，让面试官爱到 “不能自已、口水直流”。offer， 也就来了。

在面试之前，建议大家系统化的刷一波 5000页《尼恩Java面试宝典PDF》，里边有大量的大厂真题、面试难题、架构难题。很多小伙伴刷完后， 吊打面试官， 大厂横着走。

在刷题过程中，如果有啥问题，大家可以来 找 40岁老架构师尼恩交流。

另外，如果没有面试机会，可以找尼恩来改简历、做帮扶。

尼恩指导了大量的小伙伴上岸，前段时间，刚指导一个40岁+被裁小伙伴，拿到了一个年薪100W的offer。

狠狠卷，实现 “offer自由” 很容易的， 前段时间一个武汉的跟着尼恩卷了2年的小伙伴， 在极度严寒/痛苦被裁的环境下， offer拿到手软， 实现真正的 “offer自由”

美团面试：Sentinel底层滑动时间窗限流算法怎么实现的？

Sentinel是一个系统性的高可用保障工具，提供了限流、降级、熔断等一系列的能力，基于这些能力做了语意化概念抽象，这些概念对于理解实现机制特别有帮助，所以这里也复述一下。

对于流量控制，有个一个模型：

流量控制有以下几个角度:

• 资源的调用关系，例如资源的调用链路，资源和资源之间的关系；
• 运行指标，例如 QPS、线程池、系统负载等；
• 控制的效果，例如直接限流、冷启动、排队等。

Sentinel 的设计理念是让您自由选择控制的角度，并进行灵活组合，从而达到想要的效果。

Sentinel使用滑动时间窗口算法来实现流量控制，流量统计。

滑动时间窗算法的核心思想是将一段时间划分为多个时间窗口，并在每个时间窗口内对请求进行计数，以确定是否允许继续请求。

以下是Sentinel底层滑动时间窗口限流算法的简要实现步骤：

• 时间窗口划分：将整个时间范围划分为多个固定大小的时间窗口（例如1秒一个窗口）。这些时间窗口会随着时间的流逝依次滑动。
• 计数器：为每个时间窗口维护一个计数器，用于记录在该时间窗口内的请求数。
• 请求计数：当有请求到来时，将其计入当前时间窗口的计数器中。
• 滑动时间窗口：定期滑动时间窗口，将过期的时间窗口删除，并创建新的时间窗口。这样可以保持时间窗口的滚动。
• 限流判断：当有请求到来时，Sentinel会检查当前时间窗口内的请求数是否超过了预设的限制阈值。如果超过了限制阈值，请求将被拒绝或执行降级策略。
• 计数重置：定期重置过期时间窗口的计数器，以确保计数器不会无限增长。

这种滑动时间窗口算法允许在一段时间内平滑控制请求的流量，而不是仅基于瞬时请求速率进行限流。

它考虑了请求的历史分布，更适用于应对突发流量和周期性负载的情况。

我们知道，Sentinel可以用来帮助我们实现流量控制、服务降级、服务熔断，而这些功能的实现都离不开接口被调用的实时指标数据，本文便是关于 Sentinel 是如何实现指标数据统计的。

上图中的右上角就是滑动窗口的示意图，是 StatisticSlot 的具体实现。

StatisticSlot 是 Sentinel 的核心功能插槽之一，用于统计实时的调用数据。

Sentinel 是基于滑动窗口实现的实时指标数据收集统计，底层采用高性能的滑动窗口数据结构 LeapArray 来统计实时的秒级指标数据，可以很好地支撑写多于读的高并发场景。

滑动窗口的核心数据结构

• ArrayMetric：滑动窗口核心实现类。
• LeapArray：滑动窗口顶层数据结构，包含一个一个的窗口数据。
• WindowWrap：每一个滑动窗口的包装类，其内部的数据结构用 MetricBucket 表示。
• MetricBucket：指标桶，例如通过数量、阻塞数量、异常数量、成功数量、响应时间，已通过未来配额（抢占下一个滑动窗口的数量）。
• MetricEvent：指标类型，例如通过数量、阻塞数量、异常数量、成功数量、响应时间等。

ArrayMetric 源码

滑动窗口的入口类为 ArrayMetric，实现了 Metric 指标收集核心接口，该接口主要定义一个滑动窗口中成功的数量、异常数量、阻塞数量，TPS、响应时间等数据。

public class ArrayMetric implements Metric {
   
   

    private final LeapArray<MetricBucket> data;

    public ArrayMetric(int sampleCount, int intervalInMs, boolean enableOccupy) {
   
   
        if (enableOccupy) {
   
   
            this.data = new OccupiableBucketLeapArray(sampleCount, intervalInMs);
        } else {
   
   
            this.data = new BucketLeapArray(sampleCount, intervalInMs);
        }
    }

• int intervalInMs：表示一个采集的时间间隔，即滑动窗口的总时间，例如 1 分钟。
• int sampleCount：在一个采集间隔中抽样的个数，默认为 2，即一个采集间隔中会包含两个相等的区间，一个区间就是一个窗口。
• boolean enableOccupy：是否允许抢占，即当前时间戳已经达到限制后，是否可以占用下一个时间窗口的容量。

LeapArray 源码

LeapArray 用来承载滑动窗口，即成员变量 array，

array 类型为 AtomicReferenceArray<WindowWrap<T>>，保证创建窗口的原子性（CAS）。

public abstract class LeapArray<T> {
   
   

    //每一个窗口的时间间隔，单位为毫秒
    protected int windowLengthInMs;
    //抽样个数，就一个统计时间间隔中包含的滑动窗口个数
    protected int sampleCount;
    //一个统计的时间间隔
    protected int intervalInMs;
    //滑动窗口的数组，滑动窗口类型为 WindowWrap<MetricBucket>
    protected final AtomicReferenceArray<WindowWrap<T>> array;
    private final ReentrantLock updateLock = new ReentrantLock();
    
    public LeapArray(int sampleCount, int intervalInMs) {
   
   
        this.windowLengthInMs = intervalInMs / sampleCount;
        this.intervalInMs = intervalInMs;
        this.sampleCount = sampleCount;
        this.array = new AtomicReferenceArray<>(sampleCount);
    }

MetricBucket 源码

Sentinel 使用 MetricBucket 统计一个窗口时间内的各项指标数据，

这些指标数据包括请求总数、成功总数、异常总数、总耗时、最小耗时、最大耗时等，

一个 Bucket 可以是记录一秒内的数据，也可以是 10 毫秒内的数据，这个时间长度称为窗口时间。

public class MetricBucket {
   
   
    /**
     * 存储各事件的计数，比如异常总数、请求总数等
     */
    private final LongAdder[] counters;
    /**
     * 这段事件内的最小耗时
     */
    private volatile long minRt;
}

Bucket 记录一段时间内的各项指标数据用的是一个 LongAdder 数组counters，

counters 数组的每个元素分别记录一个时间窗口内的各种 度量指标 数据：如，请求总数、异常数、总耗时。

也就是说：MetricBucket 包含一个 LongAdder 数组，数组的每个元素对应到一类 MetricEvent 度量事件（指标事件）。MetricEvent：指标类型，例如通过数量、阻塞数量、异常数量、成功数量、响应时间等。

这里没有用AtomicLong，而是用LongAdder 统计， LongAdder 保证了数据修改的原子性，又采用分段模式，性能比 AtomicLong 表现更好。

public enum MetricEvent {
   
   
    PASS,
    BLOCK,
    EXCEPTION,
    SUCCESS,
    RT,
    OCCUPIED_PASS
}

当需要获取 Bucket 记录总的成功请求数或者异常总数、总的请求处理耗时，可根据事件类型 (MetricEvent) 从 Bucket 的 LongAdder 数组中获取对应的 LongAdder，并调用 sum 方法获取总数。

public long get(MetricEvent event) {
   
   
    return counters[event.ordinal()].sum();
}

当需要 Bucket 记录一个成功请求或者一个异常请求、处理请求的耗时，可根据事件类型（MetricEvent）从 LongAdder 数组中获取对应的 LongAdder，并调用其 add 方法。

public void add(MetricEvent event, long n) {
   
   
     counters[event.ordinal()].add(n);
}

WindowWrap 源码

因为 Bucket 自身并不保存时间窗口信息，所以 Sentinel 给 Bucket 加了一个包装类 WindowWrap。
Bucket 用于统计各项指标数据，WindowWrap（理论上就叫做 Bucket Wrap ） 用于记录 Bucket 的时间窗口信息（窗口的开始时间、窗口的大小），WindowWrap 数组就是一个滑动窗口。

public class WindowWrap<T> {
   
   
    /**
     * 单个窗口的时间长度（毫秒）
     */
    private final long windowLengthInMs;
    /**
     * 窗口的开始时间戳（毫秒）
     */
    private long windowStart;
    /**
     * 统计数据
     */
    private T value;
}

总的来说：

• WindowWrap 用于包装 Bucket，随着 Bucket 一起创建。
• WindowWrap 数组 实现滑动窗口，Bucket 只负责统计各项指标数据，WindowWrap 用于记录 Bucket 的时间窗口信息。
• 定位 Bucket 实际上是定位 WindowWrap，拿到 WindowWrap 就能拿到 Bucket。

滑动窗口 统计 源码实现

如果我们希望能够知道某个接口的统计数据：如每秒处理成功请求数（成功 QPS）、每秒处理失败请求数（失败 QPS），以及处理每个成功请求的平均耗时（avg RT），

注意这里我们只需要控制 Bucket 统计一秒钟的指标数据即可，但如何才能确保 Bucket 存储的就是精确到 1 秒内的数据呢？

Sentinel 是这样实现的：定义一个 Bucket 数组，根据时间戳来定位到数组的下标。

由于只需要保存最近一分钟的数据。

那么 Bucket 数组的大小就可以设置为 60，每个 Bucket 的 windowLengthInMs（窗口时间）大小就是 1 秒。

内存资源是有限的，而这个数组可以循环使用，并且永远只保存最近 1 分钟的数据，这样可以避免频繁的创建 Bucket，减少内存资源的占用。

那如何定位 Bucket 呢？

我们只需要将当前时间戳减去毫秒部分，得到当前的秒数，再将得到的秒数与数组长度 取余数，就能得到当前时间窗口的 Bucket 在数组中的位置（索引）。

calculateTimeIdx 方法中，取余数就是实现循环利用数组。

如果想要获取连续的一分钟的 Bucket 数据，就不能简单的从头开始遍历数组，而是指定一个开始时间和结束时间，从开始时间戳开始计算 Bucket 存放在数组中的下标，然后循环每次将开始时间戳加上 1 秒，直到开始时间等于结束时间。

private int calculateTimeIdx(long timeMillis) {
   
   
    long timeId = timeMillis / windowLengthInMs;
    return (int)(timeId % array.length());
}

由于循环使用的问题，当前时间戳与一分钟之前的时间戳和一分钟之后的时间戳都会映射到数组中的同一个 Bucket，

因此，必须要能够判断取得的 Bucket 是否是统计当前时间窗口内的指标数据，这便要数组每个元素都存储 Bucket 时间窗口的开始时间戳。

比如当前时间戳是 1577017626812，Bucket 统计一秒的数据，将时间戳的毫秒部分全部替换为 0，就能得到 Bucket 时间窗口的开始时间戳为 1577017626000。

//计算时间窗口开始时间戳
protected long calculateWindowStart(long timeMillis) {
   
   
    return timeMillis - timeMillis % windowLengthInMs;
}

//判断时间戳是否在当前时间窗口内
public boolean isTimeInWindow(long timeMillis) {
   
   
    return windowStart <= timeMillis && timeMillis < windowStart + windowLengthInMs;
}

如何 定位 Bucket?

通过时间戳 定位 Bucket的。

当接收到一个请求时，可根据接收到请求的时间戳计算出一个数组索引，从滑动窗口（WindowWrap 数组）中获取一个 WindowWrap，从而获取 WindowWrap 包装的 Bucket，调用 Bucket 的 add 方法记录相应的事件。

/**
 * 根据时间戳获取 bucket
 * @param timeMillis 时间戳（毫秒）
 * @return 如果时间有效，则在提供的时间戳处显示当前存储桶项；如果时间无效，则为空
 */
public WindowWrap<T> currentWindow(long timeMillis) {
   
   
    if (timeMillis < 0) {
   
   
        return null;
    }
    // 获取时间戳映射到的数组索引
    int idx = calculateTimeIdx(timeMillis);
    // 计算 bucket 时间窗口的开始时间
    long windowStart = calculateWindowStart(timeMillis);

    // 从数组中死循环查找当前的时间窗口，因为可能多个线程都在获取当前时间窗口
    while (true) {
   
   
        WindowWrap<T> old = array.get(idx);
        // 一般是项目启动时，时间未到达一个周期，数组还没有存储满，没有到复用阶段，所以数组元素可能为空
        if (old == null) {
   
   
            // 创建新的 bucket，并创建一个 bucket 包装器
            WindowWrap<T> window = new WindowWrap<T>(windowLengthInMs, windowStart, newEmptyBucket(timeMillis));
            // cas 写入，确保线程安全，期望数组下标的元素是空的，否则就不写入，而是复用
            if (array.compareAndSet(idx, null, window)) {
   
   
                return window;
            } else {
   
   
                Thread.yield();
            }
        }
        // 如果 WindowWrap 的 windowStart 正好是当前时间戳计算出的时间窗口的开始时间，则就是我们想要的 bucket
        else if (windowStart == old.windowStart()) {
   
   
            return old;
        }
        // 复用旧的 bucket
        else if (windowStart > old.windowStart()) {
   
   
            if (updateLock.tryLock()) {
   
   
                try {
   
   
                    // 重置 bucket，并指定 bucket 的新时间窗口的开始时间
                    return resetWindowTo(old, windowStart);
                } finally {
   
   
                    updateLock.unlock();
                }
            } else {
   
   
                Thread.yield();
            }
        }
        // 计算出来的当前 bucket 时间窗口的开始时间比数组当前存储的 bucket 的时间窗口开始时间还小，
        // 直接返回一个空的 bucket 就行
        else if (windowStart < old.windowStart()) {
   
   
            return new WindowWrap<T>(windowLengthInMs, windowStart, newEmptyBucket(timeMillis));
        }
    }
}

上面代码的实现是：通过当前时间戳计算出当前时间窗口的 (new) Bucket 在数组中的索引，通过索引从数组中取得 (old) Bucket；并计算 (new) Bucket 时间窗口的开始时间，与 (old) Bucket 时间窗口的开始时间作对比。

1. 如果旧的 bucket 不存在，那么我们在 windowStart 处创建一个新的 bucket，然后尝试通过 CAS 操作更新环形数组。只有一个线程可以成功更新，保证原子性。
2. 如果当前 windowStart 等于旧桶的开始时间戳，表示时间在桶内，所以直接返回桶。
3. 如果旧桶的开始时间戳落后于所提供的时间，这意味着桶已弃用，我们可以复用该桶，并将桶重置为当前的 windowStart。注意重置和清理操作很难是原子的，所以我们需要一个更新锁来保证桶更新的正确性。只有当 bucket 已弃用才会上锁，所以在大多数情况下它不会导致性能损失。
4. 不应该通过这里，因为提供的时间已经落后了，一般是时钟回拨导致的。

MetricBucket 的LongAdder

MetricBucket 定义一个LongAdder [] 类型的成员变量counter数组来进行窗口内数据的统计。

JDK1.8时，java.util.concurrent.atomic包中提供了一个新的原子类：LongAdder。

根据Oracle官方文档的介绍，LongAdder在高并发的场景下会比它的前辈————AtomicLong 具有更好的性能，代价是消耗更多的内存空间：

我们知道，AtomicLong中有个内部变量value保存着实际的long值，所有的操作都是针对该变量进行。也就是说，高并发环境下，value变量其实是一个热点，也就是N个线程竞争一个热点。

LongAdder的基本思路就是分散热点，将value值分散到一个数组中，不同线程会命中到数组的不同槽中，各个线程只对自己槽中的那个值进行CAS操作，这样热点就被分散了，冲突的概率就小很多。如果要获取真正的long值，只要将各个槽中的变量值累加返回。

这种做法有没有似曾相识的感觉？没错，ConcurrentHashMap中的“分段锁”其实就是类似的思路。

参考文章

Sentinel1.8.5源码github地址（注释）

Sentinel官网

《sentinel 学习圣经 V4》版本说明：

尼恩强烈建议：Sentinel最好是和Hystrix对比学习

先看看老牌的 hystrix

老牌hystrix 服务保护

hystrix 作为老牌 SpringCloud 微服务保护的组件，很多项目仍然在使用，

另外，底层原理都是想通的，大家可以和 sentinel 对比学习

hystrix 的详细介绍，请阅读 《 Java 高并发核心编程 卷3 加强版 》

新贵 Sentinel 服务保护

sentinel 是SpringCloud 阿里巴巴 的 微服务保护组件，

所以，在学习的时候，sentinel 最好与 hystrix 对比学习，

开始《sentinel 学习圣经》：一组核心基本概念

开发的原因，需要对吞吐量（TPS）、QPS、并发数、响应时间（RT）几个概念做下了解，查自百度百科，记录如下：

1. 响应时间(RT)

响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。

对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。

2. 吞吐量(Throughput)

吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。

对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多不走难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。

3. 并发用户数

并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。以网站系统为例，假设用户只有注册后才能使用，但注册用户并不是每时每刻都在使用该网站，因此具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花很多时间阅读网站上的信息，因而具体一个时刻只有部分在线用户同时向系统发出请求。这样，对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同时发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。

4. QPS每秒查询率(Query Per Second)

每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。 （看来是类似于TPS，只是应用于特定场景的吞吐量）

什么是服务雪崩效应？

在微服务架构系统中通常会有多个服务，在服务调用中如果出现基础服务故障，可能会导致级联故障，即一个服务不可用，可能导致所有调用它或间接调用它的服务都不可用，进而造成整个系统不可用的情况，这种现象也被称为服务雪崩效应。

服务雪崩效应是一种因“服务提供者不可用”（原因）导致“服务调用者不可用”（结果），并将不可用逐渐放大的现象。

服务雪崩效应示意如图所示，A为服务提供者，B为A的服务调用者，C为B的服务调用者。

当服务A因为某些原因导致不可用时，会引起服务B的不可用，并将不可用放大到服务C进而导致整个系统瘫痪，这样就形成了服务雪崩效应。

出现服务雪崩效应的原因如下：

• 硬件故障：如服务器宕机、机房断电、光纤被挖断等。

• 流量激增：如异常流量、重试加大流量等。

• 缓存穿透：一般发生在应用重启，所有缓存失效时，以及短时间内大量缓存失效时，因大量的缓存不命中，使请求直击后端服务，造成服务提供者超负荷运行，引起服务不可用。

• 程序bug：如程序逻辑导致死循环或者内存泄漏等。

如何解决服务器雪崩的方法有以下这些：

• 超时机制：在上游服务调用下游服务的时候，设置一个最大响应时间，如果超过这个时间，下游未作出反应，就断开请求，释放掉线程。
• 限流机制：限流就是限制系统的输入和输出流量已达到保护系统的目的。为了保证系统的稳固运行，一旦达到的需要限制的阈值，就需要限制流量并采取少量措施以完成限制流量的目的。
• 熔断机制：在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。这种牺牲局部，保全整体的措施就叫做熔断。
• 降级机制：降级是从系统功能优先级的角度考虑如何应对系统故障。 服务降级指的是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。降级其实就是为服务提供一个兜底方案，一旦服务无法正常调用，就使用兜底方案。

Sentinel 为我们提供了多种的解决服务雪崩的方法：如超时机制、限流机制、熔断机制、降级机制等等，后面会为大家进行介绍

1、什么是Sentinel:

Sentinel是阿里开源的项目，提供了流量控制、熔断降级、系统负载保护等多个维度来保障服务之间的稳定性。
官网：https://github.com/alibaba/Sentinel/wiki

2012年，Sentinel诞生于阿里巴巴，其主要目标是流量控制。2013-2017年，Sentinel迅速发展，并成为阿里巴巴所有微服务的基本组成部分。 它已在6000多个应用程序中使用，涵盖了几乎所有核心电子商务场景。2018年，Sentinel演变为一个开源项目。2020年，Sentinel Golang发布。

Sentinel的官方使用手册

https://sentinelguard.io/zh-cn/docs/quick-start.html

对于sentinel的介绍，我们这里先引入官方的说法

分布式系统的流量防卫兵
随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

然后来看看它的特性

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

Sentinel 具有以下特征:

丰富的应用场景 ：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即
突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。

完备的实时监控 ：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机
器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。

广泛的开源生态 ：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring
Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入Sentinel。

完善的 SPI 扩展点：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快
速地定制逻辑。例如定制规则管理、适配动态数据源等。

Sentinel的生态圈

Sentinel主要特性：

关于Sentinel与Hystrix的区别见：https://yq.aliyun.com/articles/633786/

Sentinel很多的特性和Hystrix有很多类似的功能。以下是Sentinel和Hystrix的对比。

Sentinel与Hystrix的区别

Sentinel	Hystrix
隔离策略	基于并发数	线程池隔离/信号量隔离
熔断降级策略	基于响应时间或失败比率	基于失败比率
实时指标实现	滑动窗口	滑动窗口（基于 RxJava）
规则配置	支持多种数据源	支持多种数据源
扩展性	多个扩展点	插件的形式
基于注解的支持	即将发布	支持
调用链路信息	支持同步调用	不支持
限流	基于 QPS / 并发数，支持基于调用关系的限流	不支持
流量整形	支持慢启动、匀速器模式	不支持
系统负载保护	支持	不支持
实时监控 API	各式各样	较为简单
控制台	开箱即用，可配置规则、查看秒级监控、机器发现等	不完善
常见框架的适配	Servlet、Spring Cloud、Dubbo、gRPC 等	Servlet、Spring Cloud Netflix

Hystrix 迁移Sentinel 方案

Sentinel 官方提供了详细的由Hystrix 迁移到Sentinel 的方法

sentinel组件介绍

Sentinel两个部分:

• 控制台（Dashboard）：Sentinel 提供的一个轻量级的开源控制台，它为用户提供了机器自发现、簇点链路自发现、监控、规则配置等功能。控制台主要负责管理推送规则、监控、集群限流分配管理、机器发现等。
• 核心库（Java 客户端）：不依赖任何框架/库，能够运行于 Java 7 及以上的版本的运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。

sentinel 核心概念

① 资源：

资源是 Sentinel 的关键概念。它可以是 Java 应用程序中的任何内容，例如由应用程序提供的服务或者是服务里的方法，甚至可以是一段代码。
Sentinel 定义资源的方式有下面几种：适配主流框架自动定义资源、通过 SphU 手动定义资源、通过 SphO 手动定义资源、注解方式定义资源。这个稍后会有使用方法教程。

其中注解方式定义资源@SentinelResource参数介绍如下：

参数	解释
value	Sentinel资源的名称，我们不仅可以通过url进行限流，也可以把此值作为资源名配置，一样可以限流。
entryType	条目类型（入站或出站），默认为出站（EntryType.OUT）
resourceType	资源的分类（类型）
blockHandler	块异常函数的名称，默认为空
blockHandlerClass	指定块处理方法所在的类。默认情况下， blockHandler与原始方法位于同一类中。 但是，如果某些方法共享相同的签名并打算设置相同的块处理程序，则用户可以设置存在块处理程序的类。 请注意，块处理程序方法必须是静态的。
fallback	后备函数的名称，默认为空
defaultFallback	默认后备方法的名称，默认为空
defaultFallback用作默认的通用后备方法。 它不应接受任何参数，并且返回类型应与原始方法兼容
fallbackClass	fallback方法所在的类（仅单个类）。默认情况下， fallback与原始方法位于同一类中。 但是，如果某些方法共享相同的签名并打算设置相同的后备，则用户可以设置存在后备功能的类。 请注意，共享的后备方法必须是静态的。
exceptionsToTrace	异常类的列表追查，默认 Throwable
exceptionsToIgnore	要忽略的异常类列表，默认情况下为空

②规则：围绕资源而设定的规则。

Sentinel 支持流量控制、熔断降级、系统保护、来源访问控制和热点参数等多种规则，所有这些规则都可以动态实时调整。

Sentinel 的使用

Sentinel中的管理控制台

1）获取 Sentinel 控制台

您可以从 https://github.com/alibaba/Sentinel/releases 下载最新版本的控制台 jar 包。

您可以从官方 网站中 下载最新版本的控制台 jar 包，下载地址如下：

https://github.com/alibaba/Sentinel/releases/download/1.6.3/sentinel-dashboard-1.7.1.jar

您也可以从最新版本的源码自行构建 Sentinel 控制台：

• 下载 控制台 工程
• 使用以下命令将代码打包成一个 fat jar: mvn clean package

2）sentinel服务启动

启动 sentinel

普通进程

java  -server -Xms64m -Xmx256m  -Dserver.port=8849 -Dcsp.sentinel.dashboard.server=localhost:8849 -Dproject.name=sentinel-dashboard -jar /work/sentinel-dashboard-1.8.6.jar 

java  -server -Xms64m -Xmx256m  -Dserver.port=8849 -Dcsp.sentinel.dashboard.server=localhost:8849 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard-1.8.6.jar 

守护进程

nohup java  -server -Xms64m -Xmx256m  -Dserver.port=8849 -Dcsp.sentinel.dashboard.server=localhost:8849 -Dproject.name=sentinel-dashboard -jar /work/sentinel-dashboard-1.8.6.jar  2>&1 &

或者

/usr/bin/su  - root  -c   "nohup java  -server -Xms64m -Xmx256m  -Dserver.port=8849 -Dcsp.sentinel.dashboard.server=localhost:8849 -Dproject.name=sentinel-dashboard -jar /work/sentinel-dashboard-1.8.6.jar  2>&1 &"

开机启动：启动命令可以加入到启动的 rc.local 配置文件， 之后做到开机启动

控制台端口：

启动 Sentinel 控制台需要 JDK 版本为 1.8 及以上版本，

-Dserver.port=8849 用于指定 Sentinel 控制台端口为 8849 

控制台登录

从 Sentinel 1.6.0 起，Sentinel 控制台引入基本的登录功能，默认用户名和密码都是 sentinel。

可以参考 鉴权模块文档 配置用户名和密码。

注：若您的应用为 Spring Boot 或 Spring Cloud 应用，您可以通过 Spring 配置文件来指定配置，详情请参考 Spring Cloud Alibaba Sentinel 文档。

启动日志

使用如下命令启动控制台：

其中 - Dserver.port=8849用于指定 Sentinel 控制台端口为 8849。

从 Sentinel 1.6.0 起，Sentinel 控制台引入基本的登录功能，默认用户名和密码都是 sentinel 。可以参考 鉴权模块文档 配置用户名和密码。

启动日志如下

[root@192 ~]# java -Dserver.port=8888 -Dcsp.sentinel.dashboard.server=localhost:8888 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard-1.8.6.jar
INFO: log base dir is: /root/logs/csp/
INFO: log name use pid is: false

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::        (v2.0.5.RELEASE)

2020-02-08 13:07:29.316  INFO 114031 --- [           main] c.a.c.s.dashboard.DashboardApplication   : Starting DashboardApplication on 192.168.180.137 with PID 114031 (/root/sentinel-dashboard-1.6.3.jar started by root in /root)
2020-02-08 13:07:29.319  INFO 114031 --- [           main] c.a.c.s.dashboard.DashboardApplication   : No active profile set, falling back to default profiles: default
2020-02-08 13:07:29.456  INFO 114031 --- [           main] ConfigServletWebServerApplicationContext : Refreshing org.springframework.boot.web.servlet.context.AnnotationConfigServletWebServerApplicationContext@59690aa4: startup date [Sat Feb 08 13:07:29 CST 2020]; root of context hierarchy
2020-02-08 13:07:33.783  INFO 114031 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8888 (http)

启动 Sentinel 控制台需要 JDK 版本为 1.8 及以上版本。

Sentinel 控制台使用

打开浏览器即可展示Sentinel的管理控制台

登录地址 http://cdh1:8849/#/login

默认用户名和密码都是 sentinel

查看机器列表以及健康情况

默认情况下Sentinel 会在客户端首次调用的时候进行初始化，开始向控制台发送心跳包。

也可以配置 sentinel.eager=true ,取消Sentinel控制台懒加载。

SpringCloud客户端能接入控制台

控制台启动后，客户端需要按照以下步骤接入到控制台。

父工程引入 alibaba实现的SpringCloud

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>Greenwich.RELEASE</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-alibaba-dependencies</artifactId>
            <version>2.1.0.RELEASE</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

子工程中引入 sentinel

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

配置启动参数
在工程的application.yml中添加Sentinel 控制台配置信息

spring:
  cloud:
    sentinel:
      transport:
        dashboard: 192.168.180.137:8849   #sentinel控制台的请求地址

这里的 spring.cloud.sentinel.transport.dashboard 配置控制台的请求路径。

2、使用 Sentinel 来进行熔断与限流

Sentinel 可以简单的分为 Sentinel 核心库和 Dashboard。核心库不依赖 Dashboard，但是结合
Dashboard 可以取得最好的效果。
使用 Sentinel 来进行熔断保护，主要分为几个步骤:

1. 定义资源

   资源：可以是任何东西，一个服务，服务里的方法，甚至是一段代码。

2. 定义规则

   规则：Sentinel 支持以下几种规则：流量控制规则、熔断降级规则、系统保护规则、来源访问控制规则
   和 热点参数规则。

3. 检验规则是否生效

Sentinel 的所有规则都可以在内存态中动态地查询及修改，修改之后立即生效. 先把可能需要保护的资源定义好，之后再配置规则。

也可以理解为，只要有了资源，我们就可以在任何时候灵活地定义各种流量控制规则。在编码的时候，只需要考虑这个代码是否需要保护，如果需要保护，就将之定义为一个资源。

2.1 Java普通应用限流

1. 引入 Sentinel 依赖

如果您的应用使用了 Maven，则在 pom.xml 文件中加入以下代码即可：

<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-core</artifactId>
    <version>1.8.6</version>
</dependency>

如果您未使用依赖管理工具，请到 Maven Center Repository 直接下载 JAR 包。

2. 定义资源

资源 是 Sentinel 中的核心概念之一。最常用的资源是我们代码中的 Java 方法。 当然，您也可以更灵活的定义你的资源，例如，把需要控制流量的代码用 Sentinel API SphU.entry("HelloWorld") 和 entry.exit() 包围起来即可。在下面的例子中，我们将 System.out.println("hello world"); 作为资源（被保护的逻辑），用 API 包装起来。参考代码如下:

public static void main(String[] args) {
   
   
    // 配置规则.
    initFlowRules();

    while (true) {
   
   
        // 1.5.0 版本开始可以直接利用 try-with-resources 特性
        try (Entry entry = SphU.entry("HelloWorld")) {
   
   
            // 被保护的逻辑
            System.out.println("hello world");
	} catch (BlockException ex) {
   
   
            // 处理被流控的逻辑
	    System.out.println("blocked!");
	}
    }
}

完成以上两步后，代码端的改造就完成了。

您也可以通过我们提供的 注解支持模块，来定义我们的资源，类似于下面的代码：

@SentinelResource("HelloWorld")
public void helloWorld() {
   
   
    // 资源中的逻辑
    System.out.println("hello world");
}

这样，helloWorld() 方法就成了我们的一个资源。注意注解支持模块需要配合 Spring AOP 或者 AspectJ 一起使用。

3. 定义规则

接下来，通过流控规则来指定允许该资源通过的请求次数，例如下面的代码定义了资源 HelloWorld 每秒最多只能通过 20 个请求。

private static void initFlowRules(){
   
   
    List<FlowRule> rules = new ArrayList<>();
    FlowRule rule = new FlowRule();
    rule.setResource("HelloWorld");
    rule.setGrade(RuleConstant.FLOW_GRADE_QPS);
    // Set limit QPS to 20.
    rule.setCount(20);
    rules.add(rule);
    FlowRuleManager.loadRules(rules);
}

完成上面 3 步，Sentinel 就能够正常工作了。更多的信息可以参考 使用文档。

4. 检查效果

Demo 运行之后，我们可以在日志 ~/logs/csp/${appName}-metrics.log.xxx 里看到下面的输出:

|--timestamp-|------date time----|--resource-|p |block|s |e|rt
1529998904000|2018-06-26 15:41:44|hello world|20|0    |20|0|0
1529998905000|2018-06-26 15:41:45|hello world|20|5579 |20|0|728
1529998906000|2018-06-26 15:41:46|hello world|20|15698|20|0|0
1529998907000|2018-06-26 15:41:47|hello world|20|19262|20|0|0
1529998908000|2018-06-26 15:41:48|hello world|20|19502|20|0|0
1529998909000|2018-06-26 15:41:49|hello world|20|18386|20|0|0

其中 p 代表通过的请求, block 代表被阻止的请求, s 代表成功执行完成的请求个数, e 代表用户自定义的异常, rt 代表平均响应时长。

可以看到，这个程序每秒稳定输出 “hello world” 20 次，和规则中预先设定的阈值是一样的。

更详细的说明可以参考: 如何使用

更多的例子可以参考: Sentinel Demo 集锦

5.接入控制台

客户端需要引入 Transport 模块来与 Sentinel 控制台进行通信。您可以通过 pom.xml 引入 JAR 包:

<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-transport-simple-http</artifactId>
  
</dependency>

启动时加入 JVM 参数 -Dcsp.sentinel.dashboard.server=consoleIp:port 指定控制台地址和端口。

-Dcsp.sentinel.dashboard.server=cdh1:8849  -Dproject.name=api-gateway 

-Dcsp.sentinel.dashboard.server=192.169.56.121:8849 -Dproject.name=api-gateway 

telnet 192.168.56.121 8849

2.1 定义资源

资源是 Sentinel 的关键概念。

它可以是 Java 应用程序中的任何内容，例如，由应用程序提供的服务，或由应用程序调用的其它应用提供的服务，RPC接口方法，甚至可以是一段代码。

只要通过 Sentinel API 定义的代码，就是资源，能够被 Sentinel 保护起来。

大部分情况下，可以使用方法签名，URL，甚至服务名称作为资源名来标示资源。

把需要控制流量的代码用 Sentinel的关键代码 SphU.entry(“资源名”) 和 entry.exit() 包围起来即可。

实例代码：

Entry entry = null;
try {
   
   
    // 定义一个sentinel保护的资源，名称为test-sentinel-api
    entry = SphU.entry(resourceName);
    // 模拟执行被保护的业务逻辑耗时
    Thread.sleep(100);
    return a;
} catch (BlockException e) {
   
   
    // 如果被保护的资源被限流或者降级了，就会抛出BlockException
    log.warn("资源被限流或降级了", e);
    return "资源被限流或降级了";
} catch (InterruptedException e) {
   
   
    return "发生InterruptedException";
} finally {
   
   
    if (entry != null) {
   
   
        entry.exit();
    }

    ContextUtil.exit();
}
}

在下面的例子中， 用 try-with-resources 来定义资源。参考代码如下:

public static void main(String[] args) {
   
   
    // 配置规则.
    initFlowRules();

    while (true) {
   
   
        // 1.5.0 版本开始可以直接利用 try-with-resources 特性
        try (Entry entry = SphU.entry("HelloWorld")) {
   
   
            // 被保护的逻辑
            System.out.println("hello world");
        } catch (BlockException ex) {
   
   
            // 处理被流控的逻辑
            System.out.println("blocked!");
        }
    }
}

资源注解@SentinelResource

也可以使用Sentinel提供的注解@SentinelResource来定义资源，实例如下:

@SentinelResource("HelloWorld")
public void helloWorld() {
   
   
    // 资源中的逻辑
    System.out.println("hello world");
}

@SentinelResource 注解

注意：注解方式埋点不支持 private 方法。

@SentinelResource 用于定义资源，并提供可选的异常处理和 fallback 配置项。

@SentinelResource 注解包含以下属性：

• value：资源名称，必需项（不能为空）
• entryType：entry 类型，可选项（默认为 EntryType.OUT）
• blockHandler / blockHandlerClass:

blockHandler 对应处理 BlockException的函数名称，可选项。blockHandler 函数访问范围需要是 public，返回类型需要与原方法相匹配，参数类型需要和原方法相匹配并且最后加一个额外的参数，类型为 BlockException。blockHandler 函数默认需要和原方法在同一个类中。若希望使用其他类的函数，则可以指定 blockHandlerClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析。

• fallback /fallbackClass

  fallback 函数名称，可选项，用于在抛出异常的时候提供 fallback 处理逻辑。fallback 函数可以针对所有类型的异常（除了exceptionsToIgnore里面排除掉的异常类型）进行处理。

• defaultFallback

  （since 1.6.0）：默认的 fallback 函数名称，可选项，通常用于通用的 fallback 逻辑（即可以用于很多服务或方法）。默认 fallback 函数可以针对所有类型的异常（除了exceptionsToIgnore里面排除掉的异常类型）进行处理。若同时配置了 fallback 和 defaultFallback，则只有 fallback 会生效。

fallback 函数签名和位置要求：

• 返回值类型必须与原函数返回值类型一致；
• 方法参数列表需要和原函数一致，或者可以额外多一个 Throwable 类型的参数用于接收对应的异常。
• fallback 函数默认需要和原方法在同一个类中。若希望使用其他类的函数，则可以指定 fallbackClass为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析。

defaultFallback 函数签名要求：

• 返回值类型必须与原函数返回值类型一致；
• 方法参数列表需要为空，或者可以额外多一个 Throwable 类型的参数用于接收对应的异常。
• defaultFallback 函数默认需要和原方法在同一个类中。若希望使用其他类的函数，则可以指定 fallbackClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析。
• exceptionsToIgnore（since 1.6.0）：用于指定哪些异常被排除掉，不会计入异常统计中，也不会进入 fallback 逻辑中，而是会原样抛出。

2.3 定义规则

规则主要有流控规则、 熔断降级规则、系统规则、权限规则、热点参数规则等：

一段硬编码的方式定义流量控制规则如下：

private void initSystemRule() {
   
   
    List<SystemRule> rules = new ArrayList<>();
    SystemRule rule = new SystemRule();
    rule.setHighestSystemLoad(10);
    rules.add(rule);
    SystemRuleManager.loadRules(rules);
}

加载规则：

FlowRuleManager.loadRules(List<FlowRule> rules); // 修改流控规则
DegradeRuleManager.loadRules(List<DegradeRule> rules); // 修改降级规则
SystemRuleManager.loadRules(List<SystemRule> rules); // 修改系统规则
AuthorityRuleManager.loadRules(List<AuthorityRule> rules); // 修改授权规则

3、sentinel 熔断降级

3.1 什么是熔断降级

熔断降级对调用链路中不稳定的资源进行熔断降级是保障高可用的重要措施之一。

由于调用关系的复杂性，如果调用链路中的某个资源不稳定，最终会导致请求发生堆积。

Sentinel 熔断降级会在调用链路中某个资源出现不稳定状态时（例如调用超时或异常比例升高），对这个资源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联错误。当资源被降级后，在接下来的降级时间窗口之内，对该资源的调用都自动熔断（默认行为是抛出 DegradeException）

熔断机模型：

当下游的服务因为某种原因突然变得不可用或响应过慢，上游服务为了保证自己整体服务的可用性，不再继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。熔断器模型

熔断器模型的状态机有3个状态。

• Closed：关闭状态（断路器关闭），所有请求都正常访问。
• Open：打开状态（断路器打开），所有请求都会被降级。熔断器会对请求情况计数，当一定时间内失败请求百分比达到阈值，则触发熔断，断路器会完全打开。
• Half Open：半开状态，不是永久的，断路器打开后会进入休眠时间。随后断路器会自动进入半开状态。此时会释放部分请求通过，若这些请求都是健康的，则会关闭断路器，否则继续保持打开，再次进行休眠计时。

3.2 熔断降级规则

熔断降级规则包含下面几个重要的属性：

Field	说明	默认值
resource	资源名，即规则的作用对象
grade	熔断策略，支持慢调用比例/异常比例/异常数量策略	慢调用比例
count	慢调用比例模式下为慢调用临界 RT（超出该值计为慢调用）；异常比例/异常数模式下为对应的阈值
timeWindow	熔断时长，单位为 s
minRequestAmount	熔断触发的最小请求数，请求数小于该值时即使异常比率超出阈值也不会熔断（1.7.0 引入）	5
statIntervalMs	统计时长（单位为 ms），如 60*1000 代表分钟级（1.8.0 引入）	1000 ms
slowRatioThreshold	慢调用比例阈值，仅慢调用比例模式有效（1.8.0 引入）

3.3 几种降级策略

我们通常用以下几种降级策略：

• 平均响应时间 (DEGRADE_GRADE_RT)：

  当资源的平均响应时间超过阈值（DegradeRule 中的 count，以 ms 为单位）之后，资源进入准降级状态。接下来如果持续进入 5 个请求，它们的 RT 都持续超过这个阈值，那么在接下的时间窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个方法的调用都会自动地返回（抛出 DegradeException）。在下一个时间窗口到来时, 会接着再放入5个请求, 再重复上面的判断.

      // 初始化降级规则
      DegradeRule degradeRule = new DegradeRule();
      degradeRule.setResource("queryGoodsInfo");
      //响应时间
      degradeRule.setGrade(RuleConstant.DEGRADE_GRADE_RT);
      //超过100ms
      degradeRule.setCount(100); 
      //熔断打开后，经过多少时间进入半打开
      degradeRule.setTimeWindow(10);
  

  注意 Sentinel 默认统计的 RT 上限是 4900 ms，超出此阈值的都会算作 4900 ms，若需要变更此上限可以通过启动配置项 -Dcsp.sentinel.statistic.max.rt=xxx 来配置。

• 异常比例 (DEGRADE_GRADE_EXCEPTION_RATIO)：

  当资源的每秒请求量 >= N（可配置），并且每秒异常总数占通过量的比值超过阈值（DegradeRule 中的 count）之后，资源进入降级状态，即在接下的时间窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个方法的调用都会自动地返回。异常比率的阈值范围是 [0.0, 1.0]，代表 0% - 100%。

  当资源的每秒异常总数占通过量的比值超过阈值（DegradeRule 中的 count）之后，资源进入降级状态，即在接下的时间窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个方法的调用都会自动地返回。

  异常比率的阈值范围是 [0.0, 1.0]，代表 0% - 100%。

• 异常数 (DEGRADE_GRADE_EXCEPTION_COUNT)：

  当资源近 1 分钟的异常数目超过阈值之后会进行熔断。

  当资源近 1 分钟的异常数目超过阈值之后会进行熔断。注意由于统计时间窗口是分钟级别的，若 timeWindow 小于 60s，则结束熔断状态后仍可能再进入熔断状态。

  注意由于统计时间窗口是分钟级别的，若 timeWindow 小于 60s，则结束熔断状态后仍可能再进入熔断状态。

3.4 熔断降级代码实现

可以通过调用 DegradeRuleManager.loadRules() 方法来用硬编码的方式定义流量控制规则。

异常数 (DEGRADE_GRADE_EXCEPTION_COUNT) 熔断：

@PostConstruct
public void initSentinelRule()
{
   
   
    //熔断规则： 5s内调用接口出现异常次数超过5的时候, 进行熔断
    List<DegradeRule> degradeRules = new ArrayList<>();
    DegradeRule rule = new DegradeRule();
     rule.setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_COUNT);//熔断规则
   rule.setResource("queryGoodsInfo");
    rule.setCount(5);

    rule.setTimeWindow(5);
    degradeRules.add(rule);
    DegradeRuleManager.loadRules(degradeRules);
    
}

具体源码，请参见疯狂创客圈crazy-springcloud 源码工程

平均响应时间 (DEGRADE_GRADE_RT) 熔断

    // 初始化降级规则
    DegradeRule degradeRule = new DegradeRule();
    degradeRule.setResource("queryGoodsInfo");
    //响应时间
    degradeRule.setGrade(RuleConstant.DEGRADE_GRADE_RT);
    //平均响应时间超过100ms
    degradeRule.setCount(100);
    //熔断打开后，经过多少时间进入半打开
    degradeRule.setTimeWindow(10);
    DegradeRuleManager.loadRules(Collections.singletonList(degradeRule));

3.5 控制台降级规则

配置

参数

Field	说明	默认值
resource	资源名，即限流规则的作用对象
count	阈值
grade	降级模式，根据 RT 降级还是根据异常比例降级	RT
timeWindow	降级的时间，单位为 s

3.6 与Hystrix的熔断对比：

Hystrix常用的线程池隔离会造成线程上下切换的overhead比较大；

Hystrix使用的信号量隔离对某个资源调用的并发数进行控制，效果不错，但是无法对慢调用进行自动降级；

Sentinel通过并发线程数的流量控制提供信号量隔离的功能；

此外，Sentinel支持的熔断降级维度更多，可对多种指标进行流控、熔断，且提供了实时监控和控制面板，功能更为强大。

4、Sentinel 流控（限流）

流量控制(Flow Control)，原理是监控应用流量的QPS或并发线程数等指标，当达到指定阈值时对流量进行控制，避免系统被瞬时的流量高峰冲垮，保障应用高可用性。

通过流控规则来指定允许该资源通过的请求次数，例如下面的代码定义了资源 HelloWorld 每秒最多只能通过 20 个请求。

参考的规则定义如下：

private static void initFlowRules(){
   
   
    List<FlowRule> rules = new ArrayList<>();
    FlowRule rule = new FlowRule();
    rule.setResource("HelloWorld");
    rule.setGrade(RuleConstant.FLOW_GRADE_QPS);
    // Set limit QPS to 20.
    rule.setCount(20);
    rules.add(rule);
    FlowRuleManager.loadRules(rules);
}

一条限流规则主要由下面几个因素组成，我们可以组合这些元素来实现不同的限流效果：

• resource：资源名，即限流规则的作用对象
• count: 限流阈值
• grade: 限流阈值类型（QPS 或并发线程数）
• limitApp: 流控针对的调用来源，若为 default 则不区分调用来源
• strategy: 调用关系限流策略
• controlBehavior: 流量控制效果（直接拒绝、Warm Up、匀速排队）

基本的参数

资源名：唯一名称，默认请求路径

针对来源：Sentinel可以针对调用者进行限流，填写微服务名，默认为default(不区分来源)

阈值类型/单机阈值：

1. QPS：每秒请求数，当前调用该api的QPS到达阈值的时候进行限流
2. 线程数：当调用该api的线程数到达阈值的时候，进行限流

是否集群：是否为集群

流控的几种strategy：

1. 直接：当api大达到限流条件时，直接限流
2. 关联：当关联的资源到达阈值，就限流自己
3. 链路：只记录指定路上的流量，指定资源从入口资源进来的流量，如果达到阈值，就进行限流，api级别的限流

4.1 直接失败模式

使用API进行资源定义

/**
 * 限流实现方式一: 抛出异常的方式定义资源
 *
 * @param orderId
 * @return
 */
@ApiOperation(value = "纯代码限流")
@GetMapping("/getOrder")
@ResponseBody
public String getOrder(@RequestParam(value = "orderId", required = false)String orderId)
{
   
   

    Entry entry = null;
    // 资源名
    String resourceName = "getOrder";
    try
    {
   
   
        // entry可以理解成入口登记
        entry = SphU.entry(resourceName);
        // 被保护的逻辑, 这里为订单查询接口
        return "正常的业务逻辑 OrderInfo :" + orderId;
    } catch (BlockException blockException)
    {
   
   
        // 接口被限流的时候, 会进入到这里
        log.warn("---getOrder1接口被限流了---, exception: ", blockException)<