11-Alibaba微服务流控组件Sentinel实战上

Sentinel是阿里巴巴开源的一款轻量级的流量控制、熔断降级Java库，主要用于防止服务雪崩和系统保护。

限流过程与实现原理

Sentinel的限流主要是通过定义资源和规则来实现的。资源是对业务逻辑的抽象，规则定义了资源的访问限制。当一个请求到来时，Sentinel会检查请求的资源是否超过了预设的规则。如果超过了规则，Sentinel会根据策略进行限流，例如直接拒绝、排队等待或慢启动。

Sentinel的限流规则主要有以下几种：

• QPS（每秒请求数）：限制资源每秒的访问次数。
• 线程数：限制资源的并发访问线程数。
• 响应时间：当资源的平均响应时间超过阈值时，限制资源的访问。
• 示例

以下是一个基于Sentinel的限流示例：

import com.alibaba.csp.sentinel.Entry;
import com.alibaba.csp.sentinel.SphU;
import com.alibaba.csp.sentinel.exception.BlockException;
import com.alibaba.csp.sentinel.slots.block.RuleConstant;
import com.alibaba.csp.sentinel.slots.block.flow.FlowRule;
import com.alibaba.csp.sentinel.slots.block.flow.FlowRuleManager;

import java.util.Collections;

public class SentinelDemo {
    public static void main(String[] args) {
        // 定义限流规则
        FlowRule rule = new FlowRule();
        rule.setResource("HelloWorld");
        rule.setGrade(RuleConstant.FLOW_GRADE_QPS);
        rule.setCount(10);
        FlowRuleManager.loadRules(Collections.singletonList(rule));

        // 模拟请求
        while (true) {
            try (Entry entry = SphU.entry("HelloWorld")) {
                // 被保护的业务逻辑
                System.out.println("Hello World");
            } catch (BlockException e) {
                // 被限流的处理逻辑
                System.out.println("Blocked");
            }
        }
    }
}

在这个示例中，我们定义了一个名为"HelloWorld"的资源，并为它设置了一个QPS限流规则，限制每秒的访问次数为10。然后我们模拟了一个无限循环的请求，每次请求都会尝试进入"HelloWorld"资源。如果资源没有被限流，那么就执行业务逻辑（打印"Hello World"）；如果资源被限流，那么就执行被限流的处理逻辑（打印"Blocked"）。

分布式系统遇到的问题
在一个高度服务化的系统中,我们实现的一个业务逻辑通常会依赖多个服务,比如:商品详情展示服务会依赖商品服务, 价格服务, 商品评论服务. 如图所示:

调用三个依赖服务会共享商品详情服务的线程池. 如果其中的商品评论服务不可用, 就会出现线程池里所有线程都因等待响应而被阻塞, 从而造成服务雪崩. 如图所示:

服务雪崩效应：因服务提供者的不可用导致服务调用者的不可用,并将不可用逐渐放大的过程，就叫服务雪崩效应
导致服务不可用的原因： 程序Bug，大流量请求，硬件故障，缓存击穿
【大流量请求】：在秒杀和大促开始前,如果准备不充分,瞬间大量请求会造成服务提供者的不可用。
【硬件故障】：可能为硬件损坏造成的服务器主机宕机, 网络硬件故障造成的服务提供者的不可访问。
【缓存击穿】：一般发生在缓存应用重启, 缓存失效时高并发，所有缓存被清空时,以及短时间内大量缓存失效时。大量的缓存不命中, 使请求直击后端,造成服务提供者超负荷运行,引起服务不可用。

在服务提供者不可用的时候，会出现大量重试的情况：用户重试、代码逻辑重试，这些重试最终导致：进一步加大请求流量。所以归根结底导致雪崩效应的最根本原因是：大量请求线程同步等待造成的资源耗尽。当服务调用者使用同步调用时, 会产生大量的等待线程占用系统资源。一旦线程资源被耗尽,服务调用者提供的服务也将处于不可用状态, 于是服务雪崩效应产生了。

解决方案
超时机制
在不做任何处理的情况下，服务提供者不可用会导致消费者请求线程强制等待，而造成系统资源耗尽。加入超时机制，
一旦超时，就释放资源。由于释放资源速度较快，一定程度上可以抑制资源耗尽的问题。

服务限流(资源隔离)
限制请求核心服务提供者的流量，使大流量拦截在核心服务之外，这样可以更好的保证核心服务提供者不出问题，对于一些出问题的服务可以限制流量访问，只分配固定线程资源访问，这样能使整体的资源不至于被出问题的服务耗尽，进而整个系统雪崩。那么服务之间怎么限流，怎么资源隔离？例如可以通过线程池+队列的方式，通过信号量的方式。如下图所示, 当商品评论服务不可用时, 即使商品服务独立分配的20个线程全部处于同步等待状态,也不会影响其他依赖服务的调用。

服务熔断
远程服务不稳定或网络抖动时暂时关闭，就叫服务熔断。
现实世界的断路器大家肯定都很了解，断路器实时监控电路的情况，如果发现电路电流异常，就会跳闸，从而防止电路被烧毁。

软件世界的断路器可以这样理解：实时监测应用，如果发现在一定时间内失败次数/失败率达到一定阈值，就“跳闸”，断路器打开——此时，请求直接返回，而不去调用原本调用的逻辑。跳闸一段时间后（例如10秒），断路器会进入半开状态，这是一个瞬间态，此时允许一次请求调用该调的逻辑，如果成功，则断路器关闭，应用正常调用；如果调用依然不成功，断路器继续回到打开状态，过段时间再进入半开状态尝试——通过”跳闸“，应用可以保护自己，而且避免浪费资源；而通过半开的设计，可实现应用的“自我修复“。

所以，同样的道理，当依赖的服务有大量超时时，在让新的请求去访问根本没有意义，只会无畏的消耗现有资源。比如我们设置了超时时间为1s,如果短时间内有大量请求在1s内都得不到响应，就意味着这个服务出现了异常，此时就没有必要再让其他的请求去访问这个依赖了，这个时候就应该使用断路器避免资源浪费。