Sentinel微服务限流、熔断、降级介绍（一）

概述

在互联网应用中，会有很多突发性的高并发访问场景，比如双11大促、秒杀等。这些场景最大的特点就是访问量会远远超出系统所能够处理的并发数。
在没有任何保护机制的情况下，如果所有的流量都进入服务器，很可能造成服务器宕机导致整个系统不可用，从而造成巨大的损失。为了保证系统在这些场景中仍能稳定运行、就需要采取一定的系统保护策略，常见的策略有服务降级、限流和熔断等。

服务限流的作用及实现

限流的主要目的是通过限制并发访问数或者限制一个时间窗口内允许处理的请求数量来保护系统，一旦达到限制数量则对新请求采取对应的拒绝策略，比如跳转到错误页面拒绝请求、进入排队系统、降级等。
从本质上讲，限流的主要作用是损失一部分用户的可用性，为大部分用户提供稳定可靠的服务。比如系统当前能够处理的并发数是10万，如果此时来了12万用户，那么限流机制会保证10万用户提供正常的服务。
在实际开发中，限流几乎无处不在：

1. 在Nginx层添加限流模块限制平均访问速度。
2. 通过设置数据库连接池、线程池的大小来限制总的并发数。
3. 通过Guava提供的Ratelimiter限制接口的访问速度。
4. TCP通信协议中的流量整形。

计数器算法

计数器算法是一种比较简单的限流实现算法，在指定周期内累加访问次数，当访问次数达到设定的阈值时，触发限流策略，当进入下一个时间周期时进行访问次数的清零。

如上图所示，限定了每一分钟能够处理的总的请求数为100，在第一个1分钟内，一共请求了60次。接着到第二个一分钟，counter又从0开始计数，在一分半钟时，已经达到了最大限流的阈值，这个时候后续所有请求都会被拒绝。这种算法可以用在短信发送的频次限制上，比如限制同一个用户一分钟之内触发短信发送的次数。

这种算法存在一个临界问题，如上图所示，在第一分钟的0:58和第二分钟的1:02这个时间段内，分别出现了100个请求，整体来看就会出现4秒内总的请求量达到200，超出了设置的阈值，但是没有触发拒绝策略的问题。

滑动窗口算法

为了解决计数器算法带来的临界问题（固定窗口切换时可能产生于两倍于阈值的问题），所有引入了窗口滑动算法。滑动窗口是一种流量控制技术，在TCP网络通信协议中，就采用了窗口算法来解决网络拥塞的情况。
简单的来说，滑动窗口算法的原理是在固定窗口中分割出多个小时间窗口，分别在每个小时间窗口中记录访问次数，然后根据时间将窗口往前滑动并删除过期的小时间窗口。最终只需统计滑动窗口范围内的所有小时间窗口总的计数即可。
如下图：我们将一分钟拆分为4个小时间窗口，每个小时间窗口最多能够处理25个请求。并且通过虚线框表示滑动窗口的大小（当前窗口的大小是2，也就是在这个窗口内最多能处理50个请求）。同时滑动窗口会在滑动窗口的最大时间结束后（30,45,60。。。），将滑动窗口向前移动一个小时间窗口。平移时，将滑动窗口内第一个小窗口的数据丢弃，然后将第二个小窗口设置为第一个小窗口，后面新增一个小窗口。同时要保证整个滑动窗口中的所有小窗口的访问次数不能超过设定的阈值（50）。
下图滑动窗口会在30s、45s、60s等时间结束时分别向前移动一个小时间窗口。

Sentinel就是采用滑动窗口算法来实现限流的。

令牌桶限流算法

令牌桶是网络流量整形（Traffic Shaping）和速率限制（Rate Limiting）中最常用的一种算法。
对于每个请求，都需要从令牌桶中获得一个令牌，如果没有获得令牌，则需要出发限流策略。

如上图所示，系统会以一个恒定速度（rate token/sec）往固定容量的令牌桶中放入令牌，如果此时有客户请求过来，则需要先从令牌桶中拿到令牌以获得访问资格。
加上令牌生成速度是每秒10个，也就是等同于QPS=10（每秒请求量），此时在请求获取令牌的时候，会存在三种情况：

1. 请求速度大于令牌生成速度：那么令牌会很快用完，后续再进来的请求会被限流。
2. 请求速度等于令牌生成速度：此时流量处于平稳状态。
3. 请求速度小于令牌生成速度：说明此时系统的并发数并不高，请求能不正常处理。
   由于令牌桶有固定的大小，当请求速度小于令牌生成速度时，令牌桶会被填满。所以令牌桶能够处理突发流量，也就是在短时间内新增的流量系统能够正常处理，这是令牌桶的特性。

漏桶限流算法

服务熔断与降级

在微服务架构中，由于服务拆分粒度较细，会出现请求链路较长的情况。如下图，用户发起一个请求操作，需要调用多个微服务才能完成。

在高并发场景下，这些依赖服务的稳定性对系统的影响非常大，比如某个服务因为网络延迟或者请求超时等原因不可用时，就会导致当前请求阻塞，如下图所示，一旦某个链路上被依赖的服务不可用，很可能出现请求堆积而导致出现雪崩效应（服务不可用）。

所以，服务熔断就是用来解决这个问题的方案。服务熔断是指当某个服务提供者无法正常为服务调用者提供服务时，比如请求超时、服务异常等，为了防止整个系统出现雪崩效应，暂时将出现故障的接口隔离出来，断绝与外部接口的联系，当触发熔断之后，后续一段时间内该服务调用者的请求都会直接失败，直到目标服务器恢复正常。
服务降级需要有一个参考指标，一般来说有以下几种常见的方案：

• 平均响应时间：比如1s内持续进入5个请求，对应的平均响应时间均超过阈值，那么接下来在一个固定的时间窗口内，对这个方法的访问都会自动熔断。
• 异常比例：当某个方法每秒调用所获得的异常总数的比例超过设定的阈值时，该资源会自动进入降级状态，也就是接下来的一个固定时间窗口内，对这个方法的调用都会自动返回。
• 异常数量：和异常比例类似，当某个方法在指定时间窗口内获得的异常数量超过阈值时会触发熔断。

分布式限流框架Sentinel

Sentinel是面向分布式服务架构的轻量级流量控制组件，主要以流量为切入点，从限流、流量整形、服务降级、系统负载保护等多个维度来帮助我们保障微服务的稳定性。
阿里巴巴内部有一句口号：“稳定压倒一切”，稳定性是系统的基础能力，稳定性差的系统会出现服务超时或服务不可用，给用户带来不好的体验，从而对业务造成恶劣影响。所以系统稳定性是一条“红线”，任何业务需求或技术架构升级都不应该越过它。

Sentinel的特性

如图所示，Sentinel的特性非常多。

• 丰富的应用场景：几乎涵盖所用的应用场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制等。
• 实时监控：Sentinel提供了实时监控功能。开发者可以在控制台中看到接入应用的单台机器秒级数据，甚至500台一下规模的集群汇总运行情况。
• 开源生态支持：Sentinel提供开箱即用的与其他开源框架/库的整合，例如与Spring Cloud、Dubbo、gRPC的整合。开发者只需要引入相应的依赖并进行简单的配置即可快速接入Sentinel。
• SPI扩展点支持：Sentinel提供了SPI扩展点支持，开发者可以通过扩展点来定制化限流规则，动作数据源适配等需求。

Sentinel的组成

Sentinel分为两个部分：

• 核心库（Java客户端）：不依赖任何框架/库，能够运行于Java运行时环境，同时对Dubbo、Spring Cloud等框架也有较好的支持。
• 控制台（Dashboard）：基于Spring Boot开发，打包后可以直接运行，不需要额外的Tomcat等应用容器。

服务保护技术对比