高级篇days01——微服务保护（基于Sentinel框架）

链接：https://pan.baidu.com/s/1PEjld5JWTwCsxSBW0mcFjQ?pwd=1nnt 
提取码：1nnt

(下面内容较多，用到的资料也不少，如果伙伴们在学习的时候缺少资料，可以留言！)

一 、初识Sentinel

目录

一 、初识Sentinel

        1.1 雪崩问题及解决方案

        1.2 服务保护技术对比

        1.3 Sentinel介绍和安装

安装：

        1.4 微服务整合Sentinel

二 、流量控制

首先了解一下簇点链路：

1. 快速入门

流控规则入门案例：需求：给 /order/{orderId}这个资源设置流控规则，QPS不能超过 5。然后利用jemeter测试。

2. 流控模式

3. 流控效果

4. 热点参数限流

三 、隔离和降级

        3.1 FeignClient整合Sentinel 

总结：

        3.2 线程隔离（船舱模式）

线程隔离（舱壁模式）

        3.3 熔断降级

熔断策略——慢调用

熔断策略-异常比例、异常数

​编辑

 总结：

四 、授权规则

        4.1 授权规则

        4.2 自定义异常结果

总结： 

五 、规则持久化

        5.1 规则管理模式

        5.2 实现push模式

关于Sentinel框架的知识和实践操作，这里就告一段落咯.....  

---

        1.1 雪崩问题及解决方案

微服务调用链路中的某个服务故障，引起整个链路中的所有微服务都不可用，这就是雪崩。

 解决雪崩问题的常见方式有四种：

•  超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待。（缓解雪崩）

        当服务A依赖于服务C时，他最多等待1秒，超过一秒钟就会结束。请求释放，缓解tomcat的压力，并没有解决雪崩问题，因为假如等待时间为一秒钟，也就是说最多等待一秒钟释放一个请求，但是如果进入新的请求一秒两个的话，终有一天也会崩。。

•  舱壁模式（隔离策略）：限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离。（解决雪崩）

        类似一个个隔离的船舱，当某些船舱进水时，也不会影响其他船舱，船在一定的容灾能力之前，船不会下沉，正常行驶。

        划分为一个个独立的线程池，即使某个都堵塞，也最多堵塞十个线程。但是有一定的浪费，加入服务C出现故障，服务A需要堵塞十个，明明知道出现故障。

 

• 熔断降级：由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。 （解决雪崩）

• 流量控制：限制业务访问的QPS（每秒钟处理的请求的数量），避免服务因流量的突增而故障。（预防雪崩） 

 

        1.2 服务保护技术对比

        1.3 Sentinel介绍和安装

Sentinel是阿里巴巴开源的一款微服务流量控制组件。官网地址：https://sentinelguard.io/zh-cn/index.html Sentinel 具有以下特征:

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

安装：

将上面资料中的 sentinel-dashboard-1.8.1jar包 ，导入进自己的全英文目录下。

然后打开cmd 进到该目录以后输入命令：

java -jar sentinel-dashboard-1.8.1.jar

默认端口为8080，可以去浏览器访问localhost:8080 即可看到控制台页面，默认的账户和密码都是sentinel 

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

 举个例子：

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

        1.4 微服务整合Sentinel

1. 打开资料中的cloud-demo项目，首先先打开nacos，然后启动网关和order以及user三个启动类：

项目结构如下：

打开nacos流程：首先解压（任意非中文目录）压缩包(资料有)，然后打开终端进入到该文件的bin目录下，输入

startup.cmd -m standalone

在浏览器输入地址：http://127.0.0.1:8848/nacos即可，默认的账号和密码都是nacos

2. 在order-service中整合sentinel，并且连接Sentinel的控制台，步骤如下：

        2.1 引入sentinel依赖：

        
            com.alibaba.cloud
            spring-cloud-starter-alibaba-sentinel
        

        2.2 配置控制台地址

spring:
    cloud:
      sentinel:
         transport:
            dashboard: localhost:8080 # sentinel 控制台地址

        2.3 访问微服务的任意端点，触发sentinel监控

        比如任意搜索:

需要注意的是，我之前的order页面端口号与sentinel都是8080 所以需要修改order的端口号，切记端口号发生冲突。 

二 、流量控制

首先了解一下簇点链路：

簇点链路：就是项目内的调用链路，链路中被监控的每个接口就是一个资源。默认情况下sentinel会监控SpringMVC的每一个端点（Endpoint，好比controller中的接口），因此SpringMVC的每一个端点（Endpoint）就是调用链路中的一个资源。 流控、熔断等都是针对簇点链路中的资源来设置的，因此我们可以点击对应资源后面的按钮来设置规则：

1. 快速入门

点击资源/order/{orderId}后面的流控按钮，就可以弹出表单。表单中可以添加流控规则，如下图所示：

        含义是限制 /order/{orderId}这个资源的单机QPS为1，即每秒只允许1次请求，超出的请求会被拦截并报错。 

流控规则入门案例：需求：给 /order/{orderId}这个资源设置流控规则，QPS不能超过 5。然后利用jemeter测试。

 1. 设置流控规则：

 2. jemeter测试：

         2.1 提前将资料里面的JMeter的压缩包解压，然后双击bin目录下的JMeter.bat  (前提电脑已安装JDK)，

        2.2 然后将资料中的 sentinel测试.jmx 导入

         ✍ ✍ 注意：记得将HTTP请求中的端口号改成自己的。

2. 流控模式

在添加限流规则时，点击高级选项，可以选择三种流控模式：

• 直接：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式
• 关联：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流。（A、B两个资源，A出发了阈值，却给B限流）
• 链路：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流（A、B、C三个资源，前两个同时访问C，而C如果只允许A访问，则B限流）
• 

 流控模式-关联

• 关联模式：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流
• 使用场景：比如用户支付时需要修改订单状态，同时用户要查询订单。查询和修改操作会争抢数据库锁，产生竞争。业务需求是有限支付和更新订单的业务，因此当修改订单业务触发阈值时，需要对查询订单业务限流。

需求： 在OrderController新建两个端点：/order/query和/order/update，无需实现业务 配置流控规则，当/order/ update资源被访问的QPS超过5时，对/order/query请求限流

• 

 运行JMeter中的关联请求，是对update发送10秒1000次请求，然后在浏览器输入localhost:8086/order/query,发现当前资源query关联update  然后对update发送多次请求，当前资源query被限流

 流控模式——链路

 需求：有查询订单和创建订单业务，两者都需要查询商品。针对从查询订单进入到查询商品的请求统计，并设置限流。

 步骤：

        1. 在OrderService中添加一个queryGoods方法，不用实现业务

public void queryGoods(){
        System.err.println("查询商品");
    }

        2. 在OrderController中，改造/order/query端点，调用OrderService中的queryGoods方法

        3. 在OrderController中添加一个/order/save的端点，调用OrderService的queryGoods方法

@GetMapping("/query")
    public String queryOrder(){

        //查询商品
        orderService.queryGoods();
        //查询订单
        System.out.println("查询订单");
        return "查询订单成功！！";
    }

    @GetMapping("/save")
    public String saveOrder(){

        //查询商品
        orderService.queryGoods();
        //查询订单
        System.out.println("新增订单");
        return "新增订单成功！！";
    }

        4. 给queryGoods设置限流规则，从/order/query进入queryGoods的方法限制QPS必须小于2

✍ ✍ Sentinel默认只标记Controller中的方法为资源，如果要标记其它方法，需要利用@SentinelResource注解，示

@SentinelResource("goods")
    public void queryGoods(){
        System.err.println("查询商品");
    }

 Sentinel默认会将Controller方法做context整合，导致链路模式的流控失效，需要修改application.yml，添加配置：

 继续运行JMeter，然后在浏览器输入localhost：8086/order/query被限流 因为JMeter设置的是每秒四个请求。超过了2 

3. 流控效果

流控效果是指请求达到流控阈值时应该采取的措施，包括三种：

• 快速失败：达到阈值后，新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。
• warm up：预热模式，对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化，从一个较小值逐渐增加到最大阈值。
• 排队等待：让所有的请求按照先后次序排队执行，两个请求的间隔不能小于指定时长
• 

 流控效果——warm up

warm up也叫预热模式，是应对服务冷启动的一种方案。请求阈值初始值是 threshold / coldFactor，持续指定时长后，逐渐提高到threshold值。而coldFactor的默认值是3.

例如，我设置QPS的threshold为10，预热时间为5秒，那么初始阈值就是 10 / 3 ，也就是3，然后在5秒后逐渐增长到10.

 需求：给/order/{orderId}这个资源设置限流，最大QPS为10，利用warm up效果，预热时长为5秒

 然后运行JMeter中的warm up  ，通过实时监控也能看出来 预热模式的输出状态。

 流控效果——排队等待

当请求超过QPS阈值时，快速失败和warm up 会拒绝新的请求并抛出异常。而排队等待则是让所有请求进入一个队列中，然后按照阈值允许的时间间隔依次执行。后来的请求必须等待前面执行完成，如果请求预期的等待时间超出最大时长，则会被拒绝。

例如：QPS = 5，意味着每200ms处理一个队列中的请求；timeout = 2000，意味着预期等待超过2000ms的请求会被拒绝并抛出异常

需求：给/order/{orderId}这个资源设置限流，最大QPS为10，利用排队的流控效果，超时时长设置为5s  

 

运行JMeter 发现我们所设置的QPS等于300/20 >10 所以说先限流。

总结：

 流控效果有哪些？

• 快速失败：QPS超过阈值时，拒绝新的请求
• warm up： QPS超过阈值时，拒绝新的请求；QPS阈值是逐渐提升的，可以避免冷启动时高并发导致服务宕机。
• 排队等待：请求会进入队列，按照阈值允许的时间间隔依次执行请求；如果请求预期等待时长大于超时时间，直接拒绝

4. 热点参数限流

之前的限流是统计访问某个资源的所有请求，判断是否超过QPS阈值。而热点参数限流是分别统计参数值相同的请求，判断是否超过QPS阈值。

配置示例： 

 

代表的含义是：对hot这个资源的0号参数（第一个参数）做统计，每1秒相同参数值的请求数不能超过5 。

比如在淘宝搜索时，有些商品很火爆 请求次数较多，而有些就比较冷门，查询次数较少，那这种情况该怎么把控呢，上面的情况属于一竿子打死了 设定的阈值都一样。

在热点参数限流的高级选项中，可以对部分参数设置例外配置：

结合上一个配置，这里的含义是对0号的long类型参数限流，每1秒相同参数的QPS不能超过5，有两个例外：

• 如果参数值是100，则每1秒允许的QPS为10
• 如果参数值是101，则每1秒允许的QPS为15 

给/order/{orderId}这个资源添加热点参数限流，规则如下：

• 默认的热点参数规则是每1秒请求量不超过2
• 给102这个参数设置例外：每1秒请求量不超过4
• 给103这个参数设置例外：每1秒请求量不超过10

 注意：热点参数限流对默认的spring MVC资源无效

对orderController中的orderId请求加上注解:

   @SentinelResource("hot")
    @GetMapping("{orderId}")
    public Order queryOrderByUserId(@PathVariable("orderId") Long orderId) {
        // 根据id查询订单并返回
        return orderService.queryOrderById(orderId);
    }

三 、隔离和降级

虽然限流可以尽量避免因高并发而引起的服务故障，但服务还会因为其它原因而故障。而要将这些故障控制在一定范围，避免雪崩，就要靠线程隔离（舱壁模式）和熔断降级手段了。 不管是线程隔离还是熔断降级，都是对客户端（调用方）的保护。

        3.1 FeignClient整合Sentinel 

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

1. 修改OrderService的application.yml文件，开启Feign的Sentinel功能

2. 给FeignClient编写失败后的降级逻辑 

• 方式一：FallbackClass，无法对远程调用的异常做处理
• 方式二：FallbackFactory，可以对远程调用的异常做处理，我们选择这种

步骤一：在feing-api项目中定义类，实现FallbackFactory：

@Slf4j
public class UserClientFallbackFactory implements FallbackFactory {
    @Override
    public UserClient create(Throwable throwable) {
        //创建UserClient接口实现类，实现其中的方法，编写失败降级的处理逻辑
        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：

@FeignClient(value = "userservice",fallbackFactory = UserClientFallbackFactory.class)

然后运行启动类，浏览器输入端口号，如果出现数据 ，则成功。

 

总结：

Sentinel支持的雪崩解决方案：

• 线程隔离（仓壁模式）
• 降级熔断

Feign整合Sentinel的步骤：

• 在application.yml中配置：feign.sentienl.enable=true
• 给FeignClient编写FallbackFactory并注册为Bean
• 将FallbackFactory配置到FeignClient

        3.2 线程隔离（船舱模式）

线程隔离有两种实现方式：

• 线程池隔离
• 信号量隔离（sentinel默认采用）

线程隔离（舱壁模式）

在添加限流规则时，可以选择两种阈值类型： 

QPS：就是每秒的请求数，在快速入门中已经演示过

线程数：是该资源能使用用的tomcat线程数的最大值。也就是通过限制线程数量，实现舱壁模式。 

        3.3 熔断降级

        熔断降级是解决雪崩问题的重要手段。其思路是由断路器统计服务调用的异常比例、慢请求比例，如果超出阈值则会熔断该服务。即拦截访问该服务的一切请求；而当服务恢复时，断路器会放行访问该服务的请求。

熔断策略——慢调用

断路器熔断策略有三种：慢调用、异常比例、异常数

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

解读：RT超过500ms的调用是慢调用，统计最近10000ms内的请求，如果请求量超过10次，并且慢调用比例高于0.5，则触发熔断，熔断时长为5秒。然后进入half-open状态，放行一次请求做测试。 

需求：给 UserClient的查询用户接口设置降级规则，慢调用的RT阈值为50ms，统计时间为1秒，最小请求数量为5，失败阈值比例为0.4，熔断时长为5

提示：为了触发慢调用规则，我们需要修改UserService中的业务，增加业务耗时：

 然后再浏览器查询id=1的用户订单，一秒内访问五次，会发现id=1的用户信息为null。

 

过了熔断时长5秒以后 数据又有了 

熔断策略-异常比例、异常数

断路器熔断策略有三种：慢调用、异常比例或异常数

• 异常比例或异常数：统计指定时间内的调用，如果调用次数超过指定请求数，并且出现异常的比例达到设定的比例阈值（或超过指定异常数），则触发熔断。例如：

 

解读：统计最近1000ms内的请求，如果请求量超过10次，并且异常比例不低于0.5，则触发熔断，熔断时长为5秒。然后进入half-open状态，放行一次请求做测试。 

 需求：给 UserClient的查询用户接口设置降级规则，统计时间为1秒，最小请求数量为5，失败阈值比例为0.4，熔断时长为5s 提示：为了触发异常统计，我们需要修改UserService中的业务，抛出异常：

慢调用比例和异常比例、异常数等：会发现当102一秒触发异常超过5次时 就会熔断，其余接口都被熔断，时长为5秒 

 总结：

 Sentinel熔断降级的策略有哪些？

• 慢调用比例：超过指定时长的调用为慢调用，统计单位时长内慢调用的比例，超过阈值则熔断
• 异常比例：统计单位时长内异常调用的比例，超过阈值则熔断
• 异常数：统计单位时长内异常调用的次数，超过阈值则熔断

四 、授权规则

        4.1 授权规则

授权规则可以对调用方的来源做控制，有白名单和黑名单两种方式。

• 白名单：来源（origin）在白名单内的调用者允许访问
• 黑名单：来源（origin）在黑名单内的调用者不允许访问
• 

 例如，我们限定只允许从网关来的请求访问order-service，那么流控应用中就填写网关的名称

 Sentinel是通过RequestOriginParser这个接口的parseOrigin来获取请求的来源的。也就是想办法获取origin的值。但是默认的获取值的结果永远是default。

 所以说无论是从网关来的还是浏览器来的都是默认值，现在需要区别出哪个是从网关来的。

例如，我们尝试从request中获取一个名为origin的请求头，作为origin的值：

一定注意不要丢了这个@Component注解。

@Component
public class HeaderOriginParse implements RequestOriginParser {
    @Override
    public String parseOrigin(HttpServletRequest httpServletRequest) {
        //1. 获取请求头
        String origin = httpServletRequest.getHeader("origin");
        //2. 非空判断
        if (StringUtils.isEmpty(origin)){
           origin="blank";
        }

        return origin;
    }
}

        这样的话画 可以获取请求的头 名为origin，如果为空则加入黑名单，但是发现网关和浏览器来的请求都没有这样的一个请求头，所以手动给网关gateway添加一个这样的请求头。 

         我们还需要在gateway服务中，利用网关的过滤器添加名为gateway的origin头：

写完以后 我们在sentinel对这个请求进行授权。如果没有这个请求。可以现在浏览器查询一下，然后刷新sentinel页面即可。

 现在我们再次查询订单信息，会发现查询不到了。

因为我们对订单查询加入了一个请求头的授权，只有在网关中进来的请求才会查询到，即白名单的请求。现在我们在网关的网址中进入，会发现成功查询。（过滤校验在项目的AuthorFilter类中）

        4.2 自定义异常结果

到此会发现只要是出现异常，都是限流（flow limiting）的信息。对用户不是很友好，所以接下来对异常进行一个自定义处理。

 

✍✍笔记：instanceof用法：判断前面的对象是否属于后面的类，或者属于其子类，是一个布尔

@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 + "}");
    }
}

接下来，自己可以测试一下，比如设置   QPS的阈值为1，然后查询订单信息。每秒超过一次就会出现以下现象。

总结： 

获取请求来源的接口是什么？

• RequestOriginParse

 处理BlockException的接口是什么？

• BlockExceptionHandler

五 、规则持久化

        我们会发现，重启 项目 所有的规则都清零。这样的话 在生产的时候 肯定不行，所以接下来需要对规则进行持久化。

        5.1 规则管理模式

Sentinel的控制台规则管理有三种模式：

         5.1.1 规则管理模式——原始模式

原始模式：控制台配置的规则直接推送到Sentinel客户端，也就是我们的应用。然后保存在内存中，服务重启则丢失。

         5.1.2 规则管理模式——pull模式

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

         5.1.3 规则管理模式——push模式❤️‍❤️‍

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

        5.2 实现push模式

1. 在order的pom中引入依赖：

    com.alibaba.csp
    sentinel-datasource-nacos

2. 在order-service中的application.yml文件配置nacos的地址及监听的配置信息

spring:
  cloud:
    sentinel:
      datasource:
        flow:
          nacos:
            server-addr: localhost:8848 # nacos地址
            dataId: orderservice-flow-rules
            groupId: SENTINEL_GROUP
            rule-type: flow # 还可以是：degrade、authority、param-flow

3. 修改sentinel-dashboard源码 （SentinelDashboard默认不支持nacos的持久化）

3.1 解压资料中的Sentinel-1.8.1，详细步骤在sentinel规则持久化.md文件中，小伙伴们可以自己试着整一下，资料中有已经修改好的也就是Sentinel-dashboard.jar.

然后把之前cmd中的sentinel关了，重新运行这个jar包，这里需要注意的是 因为源码中的yml把nacos的地址修改为了8848，所以如果你的nacos之前不是8848 运行命令如下：

java -jar Dnacos.addr=8848 sentinel-dashboard-1.8.1.jar

# 如果nacos的端口号i就是8848 则运行下面的命令
java -jar sentinel-dashboard-1.8.1.jar

 浏览器重启sentinel  然后在页面重新查询订单信息。然后回到sentinel F12 打开开发者工具,右击有一个清除缓存并硬性加载，就会出现流控规则-NACOS:

 接下来开始测试，我的测试已经建好，进入nacos页面，也会看到自己新建的限流规则。

 

然后回到查询订单的页面会发现成功限流 

接下来为了证明规则的持久化，可以重启项目，会发现规则未消失，说明成功实现限流规则的持久化。。！ ，其他会规则一样，这里就不一一演示了。

关于Sentinel框架的知识和实践操作，这里就告一段落咯.....