微服务保护

1.Sentinel概述

1.1.雪崩问题及解决方案

雪崩问题：微服务中，服务间调用关系错综复杂，一个微服务往往依赖于多个其它微服务。当微服务调用链路中的某个服务故障，很可能引起整个链路中的所有微服务都不可用，这就是雪崩问题。

比如某个微服务的服务器支持的线程和并发数有限，大量请求过来会导致服务器资源耗尽，导致当前微服务不可用，那么，依赖于当前服务的其它服务随着时间的推移，最终也都会变的不可用，雪崩就发生了。解决雪崩问题的常见方式有四种，分别是：

1.请求限流：限制业务访问的QPS，避免服务因流量的突增而故障。

2.线程隔离：是用来限定微服务中每个业务能够使用的线程数，避免耗尽tomcat的资源。 

3.服务熔断：服务熔断是一种用于处理分布式系统中服务间调用故障的机制。当一个微服务发生故障或超时时，服务熔断可以帮助我们避免连锁故障，提高整个系统的稳定性。什么情况下会服务熔断：

• 服务调用超时：当一个服务调用的响应时间超过了预设的阈值，熔断器会打开，后续的请求将被快速失败，避免长时间等待导致系统资源被耗尽。

• 服务错误率超过阈值：如果服务调用发生错误的比例超过了预设的阈值，熔断器会打开。错误可能包括异常、超时、连接错误等。熔断器会快速失败，避免继续调用发生故障的服务。

• 服务调用失败：当服务调用失败的次数超过了预设的阈值，熔断器会打开。这种情况可能是由于服务不可用、网络故障、资源不足等原因导致的。熔断器会快速失败，避免继续调用失败的服务。

• 网络故障或不稳定：当网络发生故障或不稳定时，服务调用可能会出现延迟或失败。熔断器可以捕获这些异常情况，并快速失败，避免等待超时或连锁故障。

服务熔断的原理是通过在服务调用的过程中设置一个熔断器，并监控服务的调用情况。当服务的错误率或失败次数超过设定的阈值时，熔断器会打开，将后续的请求快速失败，而不是继续调用具有高延迟或已经失效的服务。当熔断器打开后，可以选择返回一个预设的默认值或者执行降级逻辑，以保证系统的相应性能。

4.超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待。

1.2.服务保护技术对比

在 SpringCloud 当中支持 Netfix Hystrix、Sentinel、Resilience4J 等多种微服务保护技术。早期比较流行的是 Hystrix 框架，但目前国内实用最广泛的还是阿里巴巴的 Sentinel 框架，这里我们做下对比：

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

1.3.Sentinel是什么

Sentinel是阿里巴巴开源的一款微服务流量控制组件。官网地址：home | Sentinel。具有以下特征：

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

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

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

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

1.4.Sentinel的安装

第一步：下载

Sentinel官方提供了UI控制台，方便我们对系统做限流设置。大家可以在GitHub下载。课前资料也提供了下载好的jar包：

第二步：运行

将 jar 包放到任意非中文目录，执行命令：

java -jar sentinel-dashboard-1.8.1.jar

如果要修改Sentinel的默认端口、账户、密码，可以通过下列配置：

配置项	默认值	说明
server.port	8080	服务端口
sentinel.dashboard.auth.username	sentinel	默认用户名
sentinel.dashboard.auth.password	sentinel	默认密码

例如，修改端口：

java -Dserver.port=8090 -jar sentinel-dashboard-1.8.1.jar

3）访问

访问 http://localhost:8080 页面，就可以看到 Sentinel 的控制台。

需要输入账号和密码，默认都是：Sentinel，登录后，发现一片空白，什么都没有，这是因为我们还没有与微服务整合。

1.5.微服务整合Sentinel

我们在微服务中整合Sentinel，并连接Sentinel的控制台，步骤如下：

第一步：引入Sentinel依赖

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

第二步：配置控制台

修改application.yaml文件，添加下面内容：

server:
  port: 8088
spring:
  cloud: 
    sentinel:
      transport:
        dashboard: localhost:8080
      # 开启请求方式前缀。不开启的话Sentinal会把请求方式+请求路径作为簇点资源名称，而Restful风格的API请求路径一般都相同，会导致粗点资源名称重复。如果不是Restful风格可以不用开启。
      http-method-specify: true 

第三步：访问微服务的任意端点

打开浏览器，访问http://localhost:8088/order/101，这样才能触发Sentinel的监控。然后再访问Sentinel的控制台，查看效果：

2.请求限流

雪崩问题四种解决方案中的限流是避免服务因突发的流量而发生故障，是对微服务雪崩问题的预防。可以先学习这种模式。

2.1.簇点链路

当请求进入微服务时，首先会访问DispatcherServlet，然后进入Controller、Service、Mapper，这样的一个调用链就叫做簇点链路。簇点链路中被监控的每一个接口就是一个资源。

默认情况下Sentinel会监控SpringMVC的每一个端点(Endpoint)也就是Controller中的方法，因此SpringMVC的每一个端点就是调用链路中的一个资源。例如，刚才访问的微服务(order-service)中的OrderController中的端点：/order/{orderId}。

流控、熔断等都是针对簇点链路中的资源来设置的，因此我们可以点击对应资源后面的按钮来设置规则：

• 流控：流量控制

• 降级：降级熔断

• 热点：热点参数限流，是限流的一种

• 授权：请求的权限控制

2.3.请求限流的步骤

点击资源/order/{orderId}后面的流控按钮，就可以弹出表单。

表单中可以填写限流规则，如下：

其含义是限制 /order/{orderId}这个资源的单机QPS为1，即每秒只允许1次请求，超出的请求会被拦截并报错。并且，在添加限流规则时，点击高级选项，可以选择三种流控模式：

• 直接：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式

• 关联：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流

• 链路：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流

1.关联模式

统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流。如果希望/write资源访问量触发阈值时，对/read资源限流，从而避免影响/write资源，则配置规则如下：

2.链路模式

只针对从指定链路访问到本资源的请求做统计，判断是否超过阈值。例如有两条请求链路：

• /test1 --> /common

• /test2 --> /common

如果只希望统计从/test2进入到/common的请求，则可以这样配置：

3.隔离和降级

限流是一种预防措施，虽然限流可以尽量避免因高并发而引起的服务故障，但服务还会因为其它原因而故障。而要将这些故障控制在一定范围，避免雪崩，就要靠线程隔离和熔断降级手段了。

线程隔离还是熔断降级都是对调用方的保护。需要在调用方发起远程调用时做线程隔离、或者服务熔断。而我们的远程调用都是基于OpenFeign来完成的，因此我们需要将 OpenFeign 与 Sentinel 整合，在Feign里面实现线程隔离和服务熔断。

3.1.整合OpenFeign

SpringCloud中，微服务调用都是通过OpenFeign来实现的，因此做客户端保护必须整合Sentinel和OpenFeign。

第一步：修改配置，开启Sentinel功能

修改微服务的application.yml文件，开启OpenFeign的Sentinel功能：

feign:
  sentinel:
    enabled: true # 开启feign对sentinel的支持

第二步：编写失败降级逻辑

业务失败后，不能直接报错，而应该返回用户一个友好提示或者默认结果，这个就是失败降级逻辑。给FeignClient编写失败后的降级逻辑有二种。这里我们演示方式二的失败降级处理。

• FallbackClass，无法对远程调用的异常做处理。

• FallbackFactory，可以对远程调用的异常做处理，我们选择这种。

首先，在feing-api项目中定义类，实现FallbackFactory：

UserClientFallbackFactory 中的代码：

@Slf4j
public class UserClientFallbackFactory implements FallbackFactory<UserClient> {
    @Override
    public UserClient create(Throwable throwable) {
        return new UserClient() {
            @Override
            public User findById(Long id) {
                log.error("查询用户异常", throwable);
                return new User();
            }
        };
    }
}

其次，在feing-api项目中的DefaultFeignConfiguration类中将UserClientFallbackFactory注册为一个Bean：

@Bean
public UserClientFallbackFactory userClientFallbackFactory(){
    return new UserClientFallbackFactory();
}

然后，在feing-api项目中的UserClient接口中使用UserClientFallbackFactory：

import cn.itcast.feign.clients.fallback.UserClientFallbackFactory;
import cn.itcast.feign.pojo.User;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
​
@FeignClient(value = "userservice", fallbackFactory = UserClientFallbackFactory.class)
public interface UserClient {
​
    @GetMapping("/user/{id}")
    User findById(@PathVariable("id") Long id);
}

最后，重启后访问一次订单查询业务，然后查看Sentinel控制台，可以看到新的簇点链路：

3.2.线程隔离

1.线程隔离的实现

Sentinel的线程隔离有如下两种方式实现，信号量隔离是默认方式。

• 线程池隔离：给每个服务调用业务分配一个线程池，利用线程池本身实现隔离效果

• 信号量隔离：不创建线程池，而是计数器模式，记录业务使用的线程数量，达到信号量上限时，禁止新的请求。

两者的优缺点：

2.Sentinel的线程隔离

在添加限流规则时，可以选择如下两种阈值类型。需要注意的是，下面线程规则的窗口是点击流控按钮出现的，因为Sentinel认为线程隔离是流控的一种。

下面的线程数按钮就是指是该资源能使用用的 tomcat 线程数的最大值。也就是通过限制线程数量，实现线程隔离。

3.3.熔断降级

熔断降级是通过断路器统计服务调用的异常比例、慢请求比例，如果超出阈值则会熔断该服务。即拦截访问该服务的一切请求；而当服务恢复时，断路器会放行访问该服务的请求。断路器控制熔断和放行是通过状态机来完成的：

状态机包括三个状态：

• 关闭状态(closed)：断路器放行所有请求，并开始统计异常比例、慢请求比例。超过阈值则切换到open状态。

• 打开状态(open)：服务调用被熔断，访问被熔断服务的请求会被拒绝，快速失败，直接走降级逻辑。Open状态5秒后会进入half-open状态。

• 半开状态(half-open)：放行一次请求，根据执行结果来判断接下来的操作。请求成功：则切换到closed状态；请求失败：则切换到open状态。

3.3.1.慢调用

慢调用是指业务的响应时长（RT）大于指定时长的请求。在指定时间内，如果请求数量超过设定的最小数量，并且慢调用比例大于设定的阈值，则触发熔断。

下面就是一个在 Sentinel 控制台中慢调用的配置。RT 超过 500ms 的调用是慢调用，统计最近10000ms 内的请求，如果请求量超过 10 次，并且慢调用比例不低于 0.5，则触发熔断，熔断时长为 5 秒。然后进入 half-open 状态，放行一次请求做测试。

3.3.2.异常比例、异常数

异常比例或异常数是指在指定时间内，如果调用次数超过指定请求数，并且出现异常的比例达到设定的比例阈值，则触发熔断。异常数也是同理，只不过由异常比例换为了异常数。

下面是一个异常比例设置：统计最近1000ms内的请求，如果请求量超过10次，并且异常比例不低于0.4，则触发熔断。

下面是一个异常数配置：统计最近1000ms内的请求，如果请求量超过10次，并且异常比例不低于2次，则触发熔断。

4.自定义异常结果

默认情况下，发生限流、降级、授权拦截时，都会抛出异常到调用方。返回的异常结果默认都是相同的。但是这样不够友好，无法得知是限流还是降级还是授权拦截。我们可以自定义异常时的返回结果。

4.1.异常类型

如果要自定义异常时的返回结果，需要实现BlockExceptionHandler接口。

public interface BlockExceptionHandler {
    /**
    * 处理请求限流、线程隔离、熔断降级时抛出的异常
    *
    * HttpServletRequest request：request 对象。
    * HttpServletResponse response：response 对象。
    * BlockException e：被 Sentinel 拦截时抛出的异常。
    */
    void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception;
}

这里的BlockException包含多个不同的子类，这些子类代表了不同的异常类型。

异常	说明
FlowException	限流异常
ParamFlowException	热点参数限流的异常
DegradeException	降级异常
AuthorityException	授权规则异常
SystemBlockException	系统规则异常

4.2.自定义异常处理

我们可以在微服务中定义一个自定义异常处理类，重启微服务进行测试，会发现在不同场景下会返回不同的异常消息。

@Component
public class SentinelExceptionHandler implements BlockExceptionHandler {
    @Override
    public void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception {
        String msg = "未知异常";
        int status = 429;
​
        if (e instanceof FlowException) {
            msg = "请求被限流了";
        } else if (e instanceof ParamFlowException) {
            msg = "请求被热点参数限流";
        } else if (e instanceof DegradeException) {
            msg = "请求被降级了";
        } else if (e instanceof AuthorityException) {
            msg = "没有权限访问";
            status = 401;
        }
​
        response.setContentType("application/json;charset=utf-8");
        response.setStatus(status);
        response.getWriter().println("{\"msg\": " + msg + ", \"status\": " + status + "}");
    }
}

5.规则持久化

Sentinel中的所有规则都是基于内存存储，重启后所有规则都会丢失。在生产环境下，我们必须确保这些规则的持久化，避免丢失。

5.1.规则管理模式

规则是否能持久化，取决于规则管理模式，Sentinel支持三种规则管理模式，分别是原始模式、pull模式、push模式。原始模式是Sentinel的默认模式，将规则保存在内存，重启服务会丢失。

pull模式：控制台将配置的规则推送到Sentinel客户端，而客户端会将配置规则保存在本地文件或数据库中。以后会定时去本地文件或数据库中查询，更新本地规则。

push模式：控制台将配置规则推送到远程配置中心，例如Nacos。Sentinel客户端监听Nacos，获取配置变更的推送消息，完成本地配置更新。

5.2.实现push模式

我们可以用push模式来实现一下Sentinel的规则持久化，详细步骤可以参考资料的《sentinel规则持久化》。