分布式系统的问题

在一个高度服务化的系统中，我们实现的一个业务逻辑通常会依赖多个服务， 如图所示：

如果其中的下单服务不可用， 就会出现线程池里所有线程都因等待响应而被阻塞， 从而造成整个服务链路不可用， 进而导致整个系统的服务雪崩

服务雪崩效应： 因服务提供者的不可用导致服务调用者的不可用，并将不可用逐渐放大的过程，就叫服务雪崩效应

解决方案

超时机制

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

服务限流

隔离

用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，则会进行降级处理，用户的请求不会被阻塞，至少可以看到一个执行结果（例如返回友好的提示信息），而不是无休止的等待或者看到系统崩溃。

服务熔断

远程服务不稳定或网络抖动时暂时关闭，就叫服务熔断。

现实世界的断路器大家肯定都很了解，断路器实时监控电路的情况，如果发现电路电流异常，就会跳闸，从而防止电路被烧毁。

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

服务降级

所谓降级，就是当某个服务熔断之后，服务将不再被调用，此时客户端可以自己准备一个本地的 fallback（回退）回调，返回一个缺省值。 例如：（备用接口/缓存/mock 数据） 。这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强，当然这也要看适合的业务场景。

Sentinal

官方文档：https://github.com/alibaba/Sentinel/wiki

随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 是面向分布式服务架构的流量控制组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统负载保护、热点防护等多个维度来帮助开发者保障微服务的稳定性。

Sentinel 具有以下特征：

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

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

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

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

Sentinel 的使用可以分为两个部分：

• 核心库（Java 客户端）：不依赖任何框架/库，能够运行于 Java 8 及以上的版本的运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持（见 主流框架适配）。

• 控制台（Dashboard）：控制台主要负责管理推送规则、监控、集群限流分配管理、机器发现等。

阿里云提供了 企业级的 Sentinel 服务，应用高可用服务 AHAS

Sentinel 和 Hystrix 对比

Sentinel	Hystrix
隔离策略	信号量隔离
熔断降级策略	基于响应时间或失败比率
实时指标实现	滑动窗口
规则配置	支持多种数据源
扩展性	多个扩展点
基于注解的支持	支持
限流	基于 QPS，支持基于调用关系的限流
流量整形	支持慢启动、匀速器模式
系统负载保护	支持
控制台	开箱即用，可配置规则、查看秒级监控、机器发现等
常见框架的适配	Servlet、Spring Cloud、Dubbo、gRPC 等

https://github.com/alibaba/Sentinel/wiki/Sentinel-%E4%B8%8E-Hystrix-%E7%9A%84%E5%AF%B9%E6%AF%94

快速入门

引入 Sentinel 依赖

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

定义资源：资源是 Sentinel 中的核心概念之一。最常用的资源是我们代码中的 Java 方法。

@RestController
public class HelloController {
    @GetMapping(value = "/demo1")
    public String demo1() {
        // 1.5.0 版本开始可以直接利用 try-with-resources 特性，自动 exit entry
        try (Entry entry = SphU.entry("demo1")) {
            // 被保护的逻辑
            return "Hello Sentinel";
        } catch (BlockException ex) {
            // 处理被流控的逻辑
            return "被流控了。。。。";
        }

    }
}

定义规则

@RestController
public class HelloController {
    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 2.
        rule.setCount(2);
        rules.add(rule);
        FlowRuleManager.loadRules(rules);
    }
}

检查效果

只要触发流控即可

注解：@SentinelResource

上述代码虽然可以实现流控，但是代码的耦合度太高

官方文档：https://github.com/alibaba/Sentinel/wiki/%E6%B3%A8%E8%A7%A3%E6%94%AF%E6%8C%81

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

引入依赖

<dependencies>
    <!--sentinel-->
    <dependency>
        <groupId>com.alibaba.csp</groupId>
        <artifactId>sentinel-core</artifactId>
        <version>1.8.5</version>
    </dependency>
    <dependency>
        <groupId>com.alibaba.csp</groupId>
        <artifactId>sentinel-annotation-aspectj</artifactId>
        <version>1.8.2</version>
    </dependency>
</dependencies>

改造之前代码

Java配置

@Configuration
public class SentinelAspectConfiguration {

    @Bean
    public SentinelResourceAspect sentinelResourceAspect() {
        return new SentinelResourceAspect();
    }
}

代码实现

@RestController
public class HelloSentinelResourceController {

    @GetMapping(value = "/demo2")
    @SentinelResource(value = "HelloWorld", blockHandler = "demo1BlockHandler")
    public String demo1() {
        // 被保护的逻辑
        return "Hello Sentinel demo2";
    }

    
    public String demo1BlockHandler(BlockException be){

        return "服务器忙。。。。。";
    }
}

Sentinel 控制台

官方文档：https://github.com/alibaba/Sentinel/wiki/%E6%8E%A7%E5%88%B6%E5%8F%B0

Sentinel 控制台提供一个轻量级的控制台，它提供机器发现、单机资源实时监控、集群资源汇总，以及规则管理的功能。您只需要对应用进行简单的配置，就可以使用这些功能。

注意: 集群资源汇总仅支持 500 台以下的应用集群，有大概 1 - 2 秒的延时。

获取控制台

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

也可以从最新版本的源码自行构建 Sentinel 控制台：https://github.com/alibaba/Sentinel/tree/master/sentinel-dashboard

启动控制台

Sentinel 控制台是一个标准的 Spring Boot 应用，以 Spring Boot 的方式运行 jar 包即可。

java -Dserver.port=8080 -Dcsp.sentinel.dashboard.server=localhost:8080 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard.jar

客户端接入控制台

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

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

配置启动参数

启动时加入 JVM 参数 -Dcsp.sentinel.dashboard.server=consoleIp:port 指定控制台地址和端口。若启动多个应用，则需要通过 -Dcsp.sentinel.api.port=xxxx 指定客户端监控 API 的端口（默认是 8719）。

Spring Cloud Alibaba整合Sentinel

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

server.port=9001
#当前项目在注册中心的名称
spring.application.name=sentinel-app
#注册中心的地址
spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848
# 指定sentinel控制台地址
spring.cloud.sentinel.transport.dashboard=127.0.0.1:8080

Sentinel整合openfeign

Sentinel 适配了 Feign 组件。如果想使用，除了引入 spring-cloud-starter-alibaba-sentinel 的依赖外还需要 2 个步骤

配置文件打开 Sentinel 对 Feign 的支持：feign.sentinel.enabled=true

加入 spring-cloud-starter-openfeign 依赖使 Sentinel starter 中的自动化配置类生效：

<dependencies>
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-openfeign</artifactId>
        </dependency>

        <!--注册中心-->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
        </dependency>
        <!--负载均衡器-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-loadbalancer</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

@FeignClient(name = "service-provider", fallback = EchoServiceFallback.class, configuration = FeignConfiguration.class)
public interface EchoService {
    @RequestMapping(value = "/echo/{str}", method = RequestMethod.GET)
    String echo(@PathVariable("str") String str);
}

class FeignConfiguration {
    @Bean
    public EchoServiceFallback echoServiceFallback() {
        return new EchoServiceFallback();
    }
}

class EchoServiceFallback implements EchoService {
    @Override
    public String echo(@PathVariable("str") String str) {
        return "echo fallback";
    }
}

流控规则

流量控制（flow control），其原理是监控应用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。

说明文档：https://github.com/alibaba/Sentinel/wiki/%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6

同一个资源可以创建多条限流规则。FlowSlot 会对该资源的所有限流规则依次遍历，直到有规则触发限流或者所有规则遍历完毕。一条限流规则主要由下面几个因素组成，我们可以组合这些元素来实现不同的限流效果。

Field	说明	默认值
resource	资源名，资源名是限流规则的作用对象
count	限流阈值
grade	限流阈值类型，QPS 模式（1）或并发线程数模式（0）	QPS 模式
limitApp	流控针对的调用来源	default，代表不区分调用来源
strategy	调用关系限流策略：直接、链路、关联	根据资源本身（直接）
controlBehavior	流控效果（直接拒绝/WarmUp/匀速+排队等待），不支持按调用关系限流	直接拒绝
clusterMode	是否集群限流	否

限流阈值类型

• QPS（Query Per Second）：每秒请求数，就是说服务器在一秒的时间内处理了多少个请求。

• 并发线程数:Sentinel 并发控制不负责创建和管理线程池，而是简单统计当前请求上下文的线程数目（正在执行的调用数目），如果超出阈值，新的请求会被立即拒绝，效果类似于信号量隔离。并发数控制通常在调用端进行配置。

BlockException异常统一处理

springwebmvc接口资源限流入口在HandlerInterceptor的实现类AbstractSentinelInterceptor的preHandle方法中，对异常的处理是BlockExceptionHandler的实现类

自定义BlockExceptionHandler 的实现类统一处理BlockException

@Slf4j
@Component
public  class  MyBlockExceptionHandler  implements  BlockExceptionHandler  {
        @Override
        public  void  handle(HttpServletRequest  request,  HttpServletResponse  response,  BlockException  e)  throws  Exception  {
                log.info("BlockExceptionHandler  BlockException================"+e.getRule());

                R  r  =  null;

                if  (e  instanceof  FlowException)  {
                        r  =  R.error(100,"接口限流了");

                }  else  if  (e  instanceof  DegradeException)  {
                        r  =  R.error(101,"服务降级了");

                }  else  if  (e  instanceof  ParamFlowException)  {
                        r  =  R.error(102,"热点参数限流了");

                }  else  if  (e  instanceof  SystemBlockException)  {
                        r  =  R.error(103,"触发系统保护规则了");

                }  else  if  (e  instanceof  AuthorityException)  {
                        r  =  R.error(104,"授权规则不通过");
                }

                //返回json数据
                response.setStatus(500);
                response.setCharacterEncoding("utf-8");
                response.setContentType(MediaType.APPLICATION_JSON_VALUE);
                new  ObjectMapper().writeValue(response.getWriter(),  r);

        }
}

流控模式

基于调用关系的流量控制。调用关系包括调用方、被调用方；一个方法可能会调用其它方法，形成一个调用链路的层次关系。

• 直接

资源调用达到设置的阈值后直接被流控抛出异常

• 关联

当两个资源之间具有资源争抢或者依赖关系的时候，这两个资源便具有了关联。比如对数据库同一个字段的读操作和写操作存在争抢，读的速度过高会影响写得速度，写的速度过高会影响读的速度。如果放任读写操作争抢资源，则争抢本身带来的开销会降低整体的吞吐量。可使用关联限流来避免具有关联关系的资源之间过度的争抢，举例来说，read_db 和 write_db 这两个资源分别代表数据库读写，我们可以给 read_db 设置限流规则来达到写优先的目的：设置 strategy 为 RuleConstant.STRATEGY_RELATE 同时设置 refResource 为 write_db。这样当写库操作过于频繁时，读数据的请求会被限流。

• 链路

根据调用链路入口限流。

资源通过调用关系，相互之间构成一棵调用树。这棵树的根节点是一个名字为 getUser 的虚拟节点，调用链的入口都是这个虚节点的子节点。

        getUser
    /              \
  /                  \
/order/test1      /order/test2

自入口 /order/test1 和 /order/test2的请求都调用到了资源 getUser，Sentinel 允许只根据某个入口的统计信息对资源限流。

• 快速失败

此方式是默认的流量控制方式，当QPS超过任意规则的阈值后，新的请求就会被立即拒绝，拒绝方式为抛出FlowException

• Warm Up（激增流量）

即预热/冷启动方式。当系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮。

• 匀速排队（脉冲流量）

此方式会严格控制请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。

注意：匀速排队模式暂时不支持 QPS > 1000 的场景。

降级规则

除了流量控制以外，对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。我们需要对不稳定的弱依赖服务调用进行熔断降级，暂时切断不稳定调用，避免局部不稳定因素导致整体的雪崩。熔断降级作为保护自身的手段，通常在客户端（调用端）进行配置。

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

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 引入）

熔断策略

慢调用：当服务A访问服务B时,当访问B时,在设置指定的时间内没有响应

• 慢调用比例

选择以慢调用比例作为阈值，需要设置允许的慢调用 RT（即最大的响应时间），请求的响应时间大于该值则统计为慢调用。当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目，并且慢调用的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断，若大于设置的慢调用 RT 则会再次被熔断。

• 异常比例

当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目，并且异常的比例大于阈值，则接下来的熔断时长内请求会自动被熔断

• 异常数

当单位统计时长内的异常数目超过阈值之后会自动进行熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。

热点参数限流

热点就是经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的数据，并对其访问进行限制

热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制，仅对包含热点参数的资源调用生效。

注意：

• 热点规则需要使用@SentinelResource("resourceName")注解，否则不生效

• 参数必须是7种基本数据类型才会生效

单机阈值： 针对所有参数的值进行设置的一个公共的阈值

• 假设当前参数大部分的值都是热点流量，单机阈值就是针对热点流量进行设置，额外针对普通流量进行参数值流控

• 假设当前参数大部分的值都是普通流量，单机阈值就是针对普通流量进行设置，额外针对热点流量进行参数值流控

配置热点参数规则

注意：资源名必须是@SentinelResource(value="资源名")中配置的资源名，热点规则依赖于注解

系统规则

Sentinel系统自适应限流从整体维度对应用入口流量进行控制，结合应用的 Load、CPU 使用率、总体平均 RT、入口 QPS 和并发线程数等几个维度的监控指标，通过自适应的流控策略，让系统的入口流量和系统的负载达到一个平衡，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。

• Load自适应(仅对 Linux/Unix-like 机器生效)

系统的 load1 作为启发指标，进行自适应系统保护。当系统 load1 超过设定的启发值，且系统当前的并发线程数超过估算的系统容量时才会触发系统保护（BBR 阶段）。系统容量由系统的 maxQps * minRt 估算得出。设定参考值一般是 CPU cores * 2.5。

• CPU usage（1.5.0+ 版本）

当系统CPU使用率超过阈值即触发系统保护（取值范围 0.0-1.0），比较灵敏。

• 平均RT

当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护，单位是毫秒。

• 并发线程数

当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。

• 入口 QPS

当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护。

授权控制规则

很多时候，我们需要根据调用来源来判断该次请求是否允许放行，这时候可以使用 Sentinel的来源访问控制（黑白名单控制）的功能。来源访问控制根据资源的请求来源（origin）限制资源是否通过，若配置白名单则只有请求来源位于白名单内时才可通过；若配置黑名单则请求来源位于黑名单时不通过，其余的请求通过。

来源访问控制规则（AuthorityRule）主要有以下配置项：

• resource：资源名，即限流规则的作用对象。

• limitApp：对应的黑名单/白名单，不同 origin 用 , 分隔，如 appA,appB。

• strategy：限制模式，AUTHORITY_WHITE 为白名单模式，AUTHORITY_BLACK 为黑名单模式，默认为白名单模式。

实现com.alibaba.csp.sentinel.adapter.spring.webmvc.callback.RequestOriginParser接口

@Component
public  class  MyRequestOriginParser  implements  RequestOriginParser  {
        /**
          *  通过request获取来源标识，交给授权规则进行匹配
          *  @param  request
          *  @return
          */
        @Override
        public  String  parseOrigin(HttpServletRequest  request)  {
                //  标识字段名称可以自定义
                String  origin  =  request.getParameter("serviceName");
//                if  (StringUtil.isBlank(origin)){
//                        throw  new  IllegalArgumentException("serviceName参数未指定");
//                }
                return  origin;
        }
}

测试：origin是order的请求不通过。

集群规则

假设我们希望给某个用户限制调用某个 API 的总 QPS 为 50，但机器数可能很多（比如有 100 台）。这时候我们很自然地就想到，找一个 server 来专门来统计总的调用量，其它的实例都与这台 server 通信来判断是否可以调用。这就是最基础的集群流控的方式。

集群流控还可以解决流量不均匀导致总体限流效果不佳的问题。假设集群中有 10 台机器，我们给每台机器设置单机限流阈值为 10 QPS，理想情况下整个集群的限流阈值就为 100 QPS。不过实际情况下流量到每台机器可能会不均匀，会导致总量没有到的情况下某些机器就开始限流。因此仅靠单机维度去限制的话会无法精确地限制总体流量。而集群流控可以精确地控制整个集群的调用总量，结合单机限流兜底，可以更好地发挥流量控制的效果。

集群流控中共有两种身份：

• Token Client：集群流控客户端，用于向所属 Token Server 通信请求 token。集群限流服务端会返回给客户端结果，决定是否限流。

• Token Server：即集群流控服务端，处理来自 Token Client 的请求，根据配置的集群规则判断是否应该发放 token（是否允许通过）

Sentinel 集群流控支持限流规则和热点规则两种规则，并支持两种形式的阈值计算方式：

• 集群总体模式：即限制整个集群内的某个资源的总体 qps 不超过此阈值。

• 单机均摊模式：单机均摊模式下配置的阈值等同于单机能够承受的限额，token server 会根据连接数来计算总的阈值（比如独立模式下有 3 个 client 连接到了 token server，然后配的单机均摊阈值为 10，则计算出的集群总量就为 30），按照计算出的总的阈值来进行限制。这种方式根据当前的连接数实时计算总的阈值，对于机器经常进行变更的环境非常适合。