从零开始 Spring Cloud 12:Sentinel

news2024/11/13 9:47:03

从零开始 Spring Cloud 12:Sentinel

1.初识 Sentinel

1.1雪崩问题

1.1.1什么是雪崩问题

微服务中,服务间调用关系错综复杂,一个微服务往往依赖于多个其它微服务。

1533829099748

如图,如果服务提供者I发生了故障,当前的应用的部分业务因为依赖于服务I,因此也会被阻塞。此时,其它不依赖于服务I的业务似乎不受影响。

1533829198240

但是,依赖服务I的业务请求被阻塞,用户不会得到响应,则tomcat的这个线程不会释放,于是越来越多的用户请求到来,越来越多的线程会阻塞:

1533829307389

服务器支持的线程和并发数有限,请求一直阻塞,会导致服务器资源耗尽,从而导致所有其它服务都不可用,那么当前服务也就不可用了。

那么,依赖于当前服务的其它服务随着时间的推移,最终也都会变的不可用,形成级联失败,雪崩就发生了:

image-20210715172710340

简单来说,雪崩就是当调用链上的某个微服务出现故障,导致整个调用链上的微服务不可访问

1.1.2.超时处理

可以在访问服务时设置请求的响应超时时长,超过响应时长的请求中断并返回错误信息,这样可以缓解雪崩发生的概率。

如果请求产生的速度快于响应等待超时并关闭连接的速度,依然会可能发生雪崩。

image-20210715172820438

1.1.3.舱壁模式

仓壁模式来源于船舱的设计:

image-20210715172946352

船舱都会被隔板分离为多个独立空间,当船体破损时,只会导致部分空间进入,将故障控制在一定范围内,避免整个船体都被淹没。

于此类似,我们可以限定每个业务能使用的线程数,避免耗尽整个tomcat的资源,因此也叫线程隔离

image-20210715173215243

1.1.4.降级熔断

断路器模式:由断路器统计业务执行的异常比例,如果超出阈值则会熔断该业务,拦截访问该业务的一切请求。

断路器会统计访问某个服务的请求数量,异常比例:

image-20210715173327075

当发现访问服务D的请求异常比例过高时,认为服务D有导致雪崩的风险,会拦截访问服务D的一切请求,形成熔断:

image-20210715173428073

1.1.5.限流

流量控制:限制业务访问的QPS,避免服务因流量的突增而故障。

image-20210715173555158

限流只能避免因请求过多导致的服务故障以及因此产生的雪崩,但现实中服务产生故障的原因是多种多样的。

1.1.6.总结

限流是对服务的保护,避免因瞬间高并发流量而导致服务故障,进而避免雪崩。是一种预防措施。

超时处理、线程隔离、降级熔断是在部分服务故障时,将故障控制在一定范围,避免雪崩。是一种补救措施。

关于以上内容的详细说明,可以观看这个视频。

1.2.服务保护技术对比

在SpringCloud当中支持多种服务保护技术:

  • Netfix Hystrix
  • Sentinel
  • Resilience4J

早期比较流行的是Hystrix框架,但目前国内实用最广泛的还是阿里巴巴的Sentinel框架,这里我们做下对比:

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

1.3.Sentinel 介绍和安装

1.3.1.初识 Sentinel

Sentinel是阿里巴巴开源的一款微服务流量控制组件。

Sentinel 具有以下特征:

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

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

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

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

1.3.2.安装

可以从 Github 的 Release 页面下载。

这里提供一个百度云的下载。

程序本体是一个基于 Spring Boot 开发的 jar 包,通过相关 java 命令即可运行:

java -jar sentinel-dashboard-1.8.1.jar

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

配置项默认值说明
server.port8080服务端口
sentinel.dashboard.auth.usernamesentinel默认用户名
sentinel.dashboard.auth.passwordsentinel默认密码

例如,修改端口:

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

启动后访问对应的端口就能看到 Sentinel 的控制台(我这里是 http://localhost:8080/),默认账户和密码都是sentinel

1.4.微服务整合 Sentinel

这里我们使用之前学习创建的示例项目 cloud-demo 进行学习和演示。

加载项目并运行。

  • 可能需要修改项目关联的 MySQL 信息以及 Nacos 信息。
  • 该项目使用 Nacos 用于服务发现,需要提前运行 Nacos。

启动项目中的两个微服务 order-serviceuser-service,成功启动后访问接口 http://localhost:8088/order/101,会看到返回内容。

为需要整合 Sentinel 的微服务(这里是 order-service)添加依赖:

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

在微服务的配置文件中添加 Sentinel 控制台的相关配置信息:

spring:
  cloud:
    sentinel:
      transport:
        dashboard: localhost:8080

添加好后重启微服务。

再次请求微服务的接口(这里是 http://localhost:8088/order/101),然后观察 Sentinel 的控制台:

image-20230815170518533

可以看到微服务接口的访问状况。

2.流量控制

可以通过控制对微服务的访问流量来预防雪崩的发生。

2.1.簇点链路

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

默认情况下sentinel会监控SpringMVC的每一个端点(Endpoint,也就是controller中的方法),因此SpringMVC的每一个端点(Endpoint)就是调用链路中的一个资源。

如果要对簇点链路上的其它节点进行监控,就需要使用 Sentinel 的注解。

例如,我们刚才访问的order-service中的OrderController中的端点:/order/{orderId}

image-20210715191757319

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

  • 流控:流量控制
  • 降级:降级熔断
  • 热点:热点参数限流,是限流的一种
  • 授权:请求的权限控制

2.2.1.示例

这里通过示例说明如何用 Sentinel 对微服务接口实现限流。

首先对要限流的接口对应的资源设置流控规则

image-20230817153412825

针对来源default说明对任意来源施加限制,阈值设置为QPS=5说明对接口施加的限制是每秒访问次数不能超过5次

可以使用测试工具 Jmeter 模拟对接口的访问。

打开 Jmeter,加载测试样例:

image-20210715200537171

选择流控入门,这个方案在2秒内会请求接口20次,即QPS=10。右键启动以执行该测试方案。

可以在结果中看到对接口请求5次成功后出现5次失败。

对示例步骤有疑惑的可以查看这个视频

2.2.流控模式

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

  • 直接:统计当前资源的请求,触发阈值时对当前资源直接限流,也是默认的模式
  • 关联:统计与当前资源相关的另一个资源,触发阈值时,对当前资源限流
  • 链路:统计从指定链路访问到本资源的请求,触发阈值时,对指定链路限流

image-20210715201827886

之前演示的就是直接模式。

2.2.1.关联模式

关联模式:统计与当前资源相关的另一个资源,触发阈值时,对当前资源限流

关联模式的应用场景是,如果有2个资源存在竞争关系,其中一个存在大量请求时会影响另一个的性能,且这两个资源有优先级区别,我们需要在某一个高优先级的资源存在大量访问时确保其不会请求失败,此时就可以创建一个关联模式,在高优先级资源的 QPS 超过某个阈值时通过限制另一个关联资源的访问来确保高优先级资源的可用性。

下面用具体案例来说明。

假设项目中存在两个接口,一个用于更新订单,另一个用于查询订单。显然这两个接口都会访问数据库中的订单表,如果访问的是同一个订单数据,就会触发表级锁,对数据的修改会影响到数据的读取,反之亦然。

显然这两个接口存在优先级关系,相比之下我们要尽可能让更新订单的接口不要失败。因此在这里可以使用关联模式对读取订单的接口进行限制。

先创建两个用于模拟的接口:

// ...
@RestController
@RequestMapping("order")
public class OrderController {
	// ...
    @GetMapping("/query")
    public String getOrderInfo(){
        return "订单内容";
    }

    @GetMapping("/update")
    public String updateOrder(){
        return "订单已修改";
    }
}

重启微服务 order-service

访问新添加的两个接口以使 Sentinel 有相应的资源信息:

image-20230817164136268

为资源/order/query添加流控规则:

image-20230817164227046

这里添加的规则,意味着如果每秒内访问/order/update接口的次数超过5,/order/query接口就无法被访问。

可以用导入的测试案例中的 流控模式-关联 进行测试,该测试会在100秒内请求/order/update接口1000次,即每秒10次。理论上因为关联模式的限制,在这10秒内/order/query接口会不可用。

实际执行后和理论结果相符,在执行测试案例的过程中,请求/order/query接口会返回Blocked by Sentinel (flow limiting)

2.2.2.链路模式

链路模式:只针对从指定链路访问到本资源的请求做统计,判断是否超过阈值。如果超过,对请求来源限制访问。

下面用实际案例进行说明。

假设有两个接口,查询订单和创建订单,它们都需要调用查询商品的 Service 方法。

// ...
public class OrderService {
	// ...
    @SentinelResource("/service/order/query-goods")
    public String queryGoods(){
        return "商品信息";
    }
}
// ...
public class OrderController {
	// ...
    @GetMapping("/query")
    public String getOrderInfo(){
        orderService.queryGoods();
        return "订单内容";
    }
	// ...
    @GetMapping("/save")
    public String saveOrder(){
        orderService.queryGoods();
        return "订单已保存";
    }
}

注意,默认情况下 Sentinel 只会监控 Controller 中的资源,所以 Service 中的方法是不会出现在簇点链路中的资源列表里的。要将 Service 中的方法注册为资源,需要使用@SentinelResource注解。

只这样做还不够,默认情况下 Sentinel 会自动将资源整合到sentinel_spring_web_context这个默认链路下,在这里我们需要创建两个链路,并对其中的一个进行限制,所以必须关闭这种默认行为。

修改配置:

spring:
  cloud:
    sentinel:
      web-context-unify: false # 关闭context整合

重启子模块并访问两个接口。

Sentinel 控制台已经可以看到两个链路:

  • /order/save -> /service/order/query-goods
  • /order/query -> /service/order/query-goods

选择任意一个/service/order/query-goods资源添加规则:

image-20230817171324192

现在 Sentinel 会统计从 /order/query/service/order/query-goods 的这条链路,如果其 QPS 大于2,就会限制对/order/query的请求。

执行测试案例中的 流控模式-链路 进行验证,这个案例会分别对两个接口请求,QPS 都是 4,可以看到其中对/order/query的请求在每秒中只有2次成功,另外2次会失败,说明链路模式生效。而对/order/save的请求则都成功。

2.3.流控效果

在流控的高级选项中,还有一个流控效果选项:

image-20210716110225104

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

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

2.3.1.warm up

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

下面用实际案例说明。

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

流控规则设置如下:

image-20230817174327634

运行测试案例 流控效果,warm up,该测试的 QPS 是10,执行时长是20秒。可以看到一开始每秒只有3条请求成功,随着时间推移成功的请求会主逐渐增多。

查看 Sentinel 的实时监控,会看到类似下面的图形:

image-20210716111658541

可以看到通过的 QPS 主键增多,直到最大值(10),而被拒绝的 QPS 逐渐减少。

使用 warm up 这种流控效果,可以让服务器的负载逐渐上升,起到一个“预热"的效果,以避免突然的高负载导致服务器宕机。

2.3.2.排队等待

当请求超过QPS阈值时,快速失败和warm up 会拒绝新的请求并抛出异常。

而排队等待则是让所有请求进入一个队列中,然后按照阈值允许的时间间隔依次执行。后来的请求必须等待前面执行完成,如果请求预期的等待时间超出最大时长,则会被拒绝。

工作原理

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

那什么叫做预期等待时长呢?

比如现在一下子来了12 个请求,因为每200ms执行一个请求,那么:

  • 第6个请求的预期等待时长 = 200 * (6 - 1) = 1000ms
  • 第12个请求的预期等待时长 = 200 * (12-1) = 2200ms

现在,第1秒同时接收到10个请求,但第2秒只有1个请求,此时QPS的曲线这样的:

image-20210716113147176

如果使用队列模式做流控,所有进入的请求都要排队,以固定的200ms的间隔执行,QPS会变的很平滑:

image-20210716113426524

这种流控效果可以起到”流量整形“的效果,即将一个波动的 QPS 曲线整形成平滑的 QPS 曲线。而平滑的QPS曲线,对于服务器来说是更友好的。

下面用实际案例说明。

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

编辑流控规则:

image-20230817180108096

启动测试案例 流控效果,队列 进行测试,这个测试的 QPS 是15,持续20秒,可以看到实时监控图形如下:

image-20230817180303440

可以看到,一开始的几秒内是没有请求失败的 QPS 的,因为接口会处理 QPS=10 的请求,并将多余的请求放入队列,只有队列被填满(预期处理时长超过5秒),新的请求才会被丢弃(即出现请求失败的 QPS)。

2.4.热点参数限流

如果需要对同一个资源的不同参数进行限流,就需要使用热点参数限流。

比如对/goods/{id}接口的请求按照不同的参数进行 QPS 统计:

image-20210716115131463

我们就可以根据不同 id 值的 QPS 进行分别统计和限流。

下面用实际案例说明。

案例需求:给/order/{orderId}这个资源添加热点参数限流,规则如下:

•默认的热点参数规则是每1秒请求量不超过2

•给102这个参数设置例外:每1秒请求量不超过4

•给103这个参数设置例外:每1秒请求量不超过10

需要注意的是,Sentinel 的热点参数限流对默认添加的 SpringMVC 资源无效,所以这里需要先对资源使用@SentinelResource注解,以添加 Sentinel 资源:

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

重启微服务。

请求接口(http://localhost:8088/order/101)让资源注册。

热点规则 菜单页面中新增 热点规则限流

image-20230817182455417

这里的参数索引指所要添加限制的参数位于接口路径上的参数位置(从0开始)。单机阈值设置为2,统计窗口时长设置为1,实际上就是 QPS=2。

这里为资源 hot 设置的默认参数限流的 QPS 是2,另外添加了2个参数例外,其中参数值是 102 时 QPS 上限是4,参数值是 103 时 QPS 上限是10。

从簇点链路菜单页面添加热点规则无法使用高级选项(参数例外)。

执行测试案例中的 热点参数限流 QPS1 进行测试。该案例的 QPS=5,且使用不同的参数值分别请求接口:

  • /order/101
  • /order/102
  • /order/103

参数值是101时,受热点规则中的默认设置限制,即最大QPS 是2,所以每秒只有2个请求成功。参数值是102时,受例外规则限制,最大QPS是4,所以每秒有4个请求成功。参数值是103时,最大 QPS 是10,所以所有请求都成功。

3.隔离和降级

可以用 Sentinel 对分布式架构中接口的调用方进行保护,具体包含两种方式:

线程隔离之前讲到过:调用者在调用服务提供者时,给每个调用的请求分配独立线程池,出现故障时,最多消耗这个线程池内资源,避免把调用者的所有资源耗尽。

image-20210715173215243

熔断降级:是在调用方这边加入断路器,统计对服务提供者的调用,如果调用的失败比例过高,则熔断该业务,不允许访问该服务的提供者了。

image-20210715173428073

3.1.FeignClient 整合 Sentinel

因为目前我们 Spring Cloud 中微服务之间的远程调用都是用 Feign 实现的,所以要想实现上边的功能,就必须在服务调用方的 Feign 客户端中整合 Sentinel。

下面具体说明如何实现 Feign 客户端和 Sentinel 的整合。

3.1.1.开启 Sentinel 功能

首先需要修改配置,以启用 Feign 对 Sentinel 的支持:

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

这里的示例中我们需要保护的是微服务 order-service,它的订单信息接口会远程调用 user-service,所以对 order-service 中的 Feign 客户端整合 Sentinel,也就是要修改 order-service 的配置文件。

实际上完成上边的步骤后 Sentinel 已经会将通过 Feign 进行的远程调用纳入资源监控,可以在 Sentinel 控制台看到相应的资源:

image-20230818103124871

但如果直接设置降级熔断或者隔离,触发限制后远程调用会直接报错,这样对调用方的感知不会太好,因此一般我们需要添加失败降级后的处理逻辑。

3.1.2.添加失败降级逻辑

可以利用两个接口实现 Feign 客户端调用失败后的降级逻辑:

  1. FallbackClass,无法对远程调用的异常做处理

  2. FallbackFactory,可以对远程调用的异常做处理,我们选择这种

一般使用 FallbackFactory

package cn.itcast.feign.clients.fallbackfactory;
// ...
@Log4j2
public class UserClientFallbackFactory implements FallbackFactory<UserClient> {

    @Override
    public UserClient create(Throwable throwable) {
        return new UserClient() {
            @Override
            public User findById(Long id) {
                //将错误信息打印到日志
                log.error("Feign 远程调用出错", throwable);
                //远程调用失败时返回一个空的用户对象
                return new User();
            }
        };
    }
}

FallbackFactory要写在 FeignClient 定义的地方,在这个示例项目中,就是子模块 feign-api

FallbackFactory是一个泛型接口,在实现时,泛型参数应当指定为要定义错误处理的 FeignClient

FallbackFactory的实现类必须定义为 Spring Bean:

package cn.itcast.feign.config;
// ...
public class DefaultFeignConfiguration {
	// ...
    @Bean
    public UserClientFallbackFactory userClientFallbackFactory(){
        return new UserClientFallbackFactory();
    }
}

feign-api 只是一个用于定义 Feign 客户端的子模块,并不会真正运行。所以要让配置类DefaultFeignConfiguration生效,还需要在使用 feign-api 的微服务中添加:

package cn.itcast.order;
// ...
@SpringBootApplication
@EnableFeignClients(clients = UserClient.class,defaultConfiguration = DefaultFeignConfiguration.class)
public class OrderApplication {
	// ...
}

要让定义的FallbackFactory生效,还需要在@FeignClient注解中添加fallbackFactory属性:

@FeignClient(value = "userservice", fallbackFactory = UserClientFallbackFactory.class)
public interface UserClient {
	// ...
}

在实际使用中,失败降级逻辑通常可以用两种思路实现以保证用户友好:

  • 返回特定的错误信息。
  • 返回特定的业务数据,比如一些特定的商品信息等。

3.2.线程隔离

3.2.1.线程隔离的实现方式

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

  • 线程池隔离
  • 信号量隔离(Sentinel默认采用)

image-20210716123036937

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

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

两者的优缺点:

image-20210716123240518

3.2.2.Sentinel 的线程隔离

这里用示例进行说明如何用 Sentinel 实现线程隔离。

为资源GET:http://userservice/user/{id}添加线程隔离:

image-20230818115211175

现在/order/{orderId} -> /userservice/user/{id} 这个调用链被设置了信号量隔离,阈值为2。也就是说同时只能有2个并发的线程被允许访问接口/userservice/user/{id},其它的并发线程会被拒绝(执行定义好的失败降级逻辑,如果有的话)。

可以执行 JMeter 中的 阈值类型-线程数<2 来进行测试。该测试会模拟同时请求10次接口。

可以观察到虽然10次请求都成功了,但有8次返回的结果中用户信息是null,这符合我们实现的失败处理逻辑。

3.3.熔断降级

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

断路器控制熔断和放行是通过状态机来完成的:

image-20210716130958518

状态机包括三个状态:

  • closed:关闭状态,断路器放行所有请求,并开始统计异常比例、慢请求比例。超过阈值则切换到open状态
  • open:打开状态,服务调用被熔断,访问被熔断服务的请求会被拒绝,快速失败,直接走降级逻辑。Open状态5秒后会进入half-open状态
  • half-open:半开状态,放行一次请求,根据执行结果来判断接下来的操作。
    • 请求成功:则切换到closed状态
    • 请求失败:则切换到open状态

关于断路器状态的详细讲解,可以观看这个视频(相关内容位于 24:00)

3.3.1.慢调用

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

例如:

image-20210716145934347

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

下面用实际示例进行说明。

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

为了模拟接口调用超过 50ms,在接口中添加休眠代码:

package cn.itcast.user.web;
// ...
public class UserController {
	// ...
    @GetMapping("/{id}")
    public User queryById(@PathVariable("id") Long id,
                          @RequestHeader(value = "Truth", required = false) String truth) throws InterruptedException {
        if (id.equals(1L)) {
            Thread.sleep(60);
        }
        return userService.queryById(id);
    }
}

给资源GET:http://userservice/user/{id}添加降级规则:

image-20230818173538521

也就是说,上面配置的规则只要在1秒内有至少5次请求发生,且其中2次以上调用时长超过50ms,就会熔断5s。

请求接口 http://localhost:8088/order/101 5次后,发生熔断:

{
    "id": 101,
    "price": 699900,
    "name": "Apple 苹果 iPhone 12 ",
    "num": 1,
    "userId": 1,
    "user": {
        "id": null,
        "username": null,
        "address": null
    }
}

此时请求接口 http://localhost:8088/order/102 同样无法获取正确的用户信息:

{
    "id": 102,
    "price": 209900,
    "name": "雅迪 yadea 新国标电动车",
    "num": 1,
    "userId": 2,
    "user": {
        "id": null,
        "username": null,
        "address": null
    }
}

等待5秒后两个接口都恢复为正常访问。

  • 如果熔断降级规则配置后进行测试发现没有生效,可以等一会,实际测试发现规则没有立即生效。
  • 可以手动刷新浏览器进行测试,也可以选择使用 JMeter。

3.3.2.异常比例、异常数

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

例如,一个异常比例设置:

image-20210716131430682

解读:统计最近1000ms内的请求,如果请求量超过10次,并且异常比例不低于0.4,则触发熔断。

一个异常数设置:

image-20210716131522912

解读:统计最近1000ms内的请求,如果请求量超过10次,并且异常比例不低于2次,则触发熔断。

这里同样用实际示例进行说明。

目标:给 UserClient的查询用户接口设置降级规则,统计时间为1秒,最小请求数量为5,失败阈值比例为0.4,熔断时长为5s。

为了模拟接口调用出现异常,在接口中抛出一个异常:

@GetMapping("/{id}")
public User queryById(@PathVariable("id") Long id,
                      @RequestHeader(value = "Truth", required = false) String truth) throws InterruptedException {
    if (id.equals(1L)) {
        System.out.println("程序休眠,以满足降级要求");
        Thread.sleep(60);
    }
    else if (id.equals(2L)){
        throw new RuntimeException("模拟调用出现异常");
    }
    return userService.queryById(id);
}

重启微服务。

修改之前添加的降级熔断规则:

image-20230818185243688

和之前类似,只要在1s内至少请求5次,且其中有2个异常请求出现异常,就会触发熔断。

测试过程与之前类似,不再赘述。

除了按照异常比例熔断以外,还可以按照异常数进行统计和熔断,比如:

image-20230818191010181

这个设置和上边的设置效果是类似的。

4.授权规则

授权规则可以对请求方来源做判断和控制。

4.1.授权规则

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

  • 白名单:来源(origin)在白名单内的调用者允许访问

  • 黑名单:来源(origin)在黑名单内的调用者不允许访问

点击左侧菜单的授权,可以看到授权规则:

image-20210716152010750

  • 资源名:就是受保护的资源,例如/order/{orderId}

  • 流控应用:是来源者的名单,

    • 如果是勾选白名单,则名单中的来源被许可访问。
    • 如果是勾选黑名单,则名单中的来源被禁止访问。

比如:

image-20210716152349191

我们允许请求从gateway到order-service,不允许浏览器访问order-service,那么白名单中就要填写网关的来源名称(origin)

Sentinel是通过RequestOriginParser这个接口的parseOrigin来获取请求的来源的。

public interface RequestOriginParser {
    /**
     * 从请求request对象中获取origin,获取方式自定义
     */
    String parseOrigin(HttpServletRequest request);
}

这个方法的作用就是从request对象中,获取请求者的origin值并返回。

默认情况下,sentinel不管请求者从哪里来,返回值永远是default,也就是说一切请求的来源都被认为是一样的值default。

换言之,我们需要添加一个自定义 bean 并实现该接口,来定义一个我们自己的区分 origin 的规则。

作为示例,我们这里定义一个 HTTP 请求头 origin 来进行区分:

package cn.itcast.order.sentinel;
// ...
@Component
public class HeaderOriginParser implements RequestOriginParser {
    @Override
    public String parseOrigin(HttpServletRequest httpServletRequest) {
        String origin = httpServletRequest.getHeader("origin");
        if (StringUtils.isEmpty(origin)) {
            origin = "blank";
        }
        return origin;
    }
}

修改 gateway 中的配置,让所有经过 gateway 过来的 HTTP 请求都添加一个 origin 请求头:

spring:
  cloud:
    gateway:
      default-filters:
        - AddRequestHeader=origin,gateway

重启 gatewayorder-service

新增一个授权规则:

image-20230818194230984

现在直接请求接口 http://localhost:8088/order/101 会返回:

Blocked by Sentinel (flow limiting)

但经过 gateway 进行请求:http://localhost:10010/order/101?authorization=admin,可以成功返回:

{
    "id": 101,
    "price": 699900,
    "name": "Apple 苹果 iPhone 12 ",
    "num": 1,
    "userId": 1,
    "user": {
        "id": 1,
        "username": "柳岩",
        "address": "湖南省衡阳市"
    }
}

4.2.自定义异常结果

上面的示例存在一个问题,虽然触发的是授权规则进行的熔断,但实际上返回的错误信息却是限流(Flow Limiting)。实际上默认情况下,Sentinel 发生限流、降级、授权拦截时,都会抛出异常(BlockException)到调用方。异常结果都是flow limmiting(限流)。

可以实现一个接口BlockExceptionHandler来改变这种默认行为:

public interface BlockExceptionHandler {
    /**
     * 处理请求被限流、降级、授权拦截时抛出的异常:BlockException
     */
    void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception;
}

这个方法有三个参数:

  • HttpServletRequest request:request对象
  • HttpServletResponse response:response对象
  • BlockException e:被sentinel拦截时抛出的异常

可以在实现方法中根据 Sentinel 抛出异常的具体类型来分别处理(通常是在 Response 中返回不同的错误提示)。

BlockException的子类有:

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

下面是一个 BlockExceptionHandler 的实现示例:

package cn.itcast.order.sentinel;
// ...
@Component
public class MyBlockExceptionHandler implements BlockExceptionHandler {
    @Override
    public void handle(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, 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;
        }

        httpServletResponse.setContentType("application/json;charset=utf-8");
        httpServletResponse.setStatus(status);
        httpServletResponse.getWriter().println("{\"msg\": " + msg + ", \"status\": " + status + "}");

    }
}

重启微服务后添加限流规则并访问接口(比如 http://localhost:8088/order/101),将会显示自定义的错误信息:

{"msg": 请求被限流了, "status": 429}

5.规则持久化

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

5.1.规则管理模式

规则是否能持久化,取决于规则管理模式,sentinel支持三种规则管理模式:

  • 原始模式:Sentinel的默认模式,将规则保存在内存,重启服务会丢失。
  • pull模式
  • push模式

5.1.1.pull模式

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

image-20210716154155238

5.1.2.push模式

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

image-20210716154215456

5.2.实现push模式

Sentinel 可以借助 Nacos 的远程配置功能实现规则的持久化,但阿里开源的 Sentinel 不支持该功能,只有收费版本支持。要让开源的免费版本支持,需要修改 Sentinel-dashboard 的源码后重新打包运行。

具体方式可以参考这篇文章。

源码的修改过程倒不是很复杂,但是该项目引用的依赖非常多,下载依赖要花费很长时间(大概一天左右),所以这里提供一个我修改好的 jar 包。

运行的时候只要指定 Nacos 服务的地址就行:

java -jar -Dnacos.addr=192.168.0.88:8848 sentinel-dashboard.jar

The End,谢谢阅读。

参考资料

  • https://www.bilibili.com/video/BV1LQ4y127n4?p=143

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/902866.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

YOLOv5改进系列(22)——替换主干网络之MobileViTv1(一种轻量级的、通用的移动设备 ViT)

【YOLOv5改进系列】前期回顾: YOLOv5改进系列(0)——重要性能指标与训练结果评价及分析 YOLOv5改进系列(1)——添加SE注意力机制

Linux 一个简单的多线程程序

一个简单的多线程程序 编写一个简单的多线程程序 代码如下&#xff1a; 运行结果&#xff1a; 出现这样的运行结果是因为主函数直接就运行完了&#xff0c;直接5次循环就结束了&#xff0c;线程函数还没有来得及执行&#xff0c;整个进程就已经结束了。因为主函数退出之后系统…

MySQL卸载-Linux版

MySQL卸载-Linux版 停止MySQL服务 systemctl stop mysqld 查询MySQL的安装文件 rpm -qa | grep -i mysql 卸载上述查询出来的所有的MySQL安装包 rpm -e mysql-community-client-plugins-8.0.26-1.el7.x86_64 --nodeps ​ rpm -e mysql-community-server-8.0.26-1.el7.x86_64 -…

磁盘满了怎么办?实用小技巧,做不做测试都非常好用!

♥ 前 言 工作了多年的测试&#xff0c;应该多少都会遇到磁盘空间不够的情况&#xff0c;比方你现在正在用的测试环境&#xff0c;因为要测试&#xff0c;所以&#xff0c;项目一直启动&#xff0c;那么就会一直在写日志&#xff0c;如果不定期清理日志&#xff0c;随着时间…

第一百三十三天学习记录:数据结构与算法基础:串、数组和广义表(串Ⅱ)(王卓教学视频)

注&#xff1a;在之前学习C语言的时候&#xff0c;了解过这一块。其中对KMP算法进行了自学&#xff0c;前面的学习记录也有提到过。这一次根据视频教学再系统性的学习学习一次。 串的模式匹配算法 KMP算法

漏洞指北-VulFocus靶场专栏-初级01

漏洞指北-VulFocus靶场专栏-初级 初级001 &#x1f338;海洋CMS代码执行&#xff08;CNVD-2020-22721&#x1f338;step1&#xff1a;进入后台页面 账号密码&#xff1a;admin amdinstep2&#xff1a;点击系统&#xff0c;点击后台IP安全设置,关闭step3 启动burpsuite&#xff…

Yolo算法与ChatGPT互通,这功能是真的强大!

点击蓝字 关注我们 关注并星标 从此不迷路 计算机视觉研究院 公众号ID&#xff5c;计算机视觉研究院 学习群&#xff5c;扫码在主页获取加入方式 参考地址&#xff1a;https://github.com/ultralytics/ultralytics 计算机视觉研究院专栏 Column of Computer Vision Institute 现…

深入浅出解析Stable Diffusion XL完整核心基础知识 | 【算法兵器谱】

Rocky Ding 公众号&#xff1a;WeThinkIn 写在前面 【算法兵器谱】栏目专注分享AI行业中的前沿/经典/必备的模型&论文&#xff0c;并对具备划时代意义的模型&论文进行全方位系统的解析&#xff0c;比如Rocky之前出品的爆款文章Make YOLO Great Again系列。也欢迎大家提…

计网第三章(数据链路层)(三)

一、点对点协议PPP 在第一篇里有提到数据链路层的信道分为两种&#xff1a;点对点信道和广播信道。 PPP协议就属于点对点信道上的协议。 如果对前面数据链路层的三个基本问题了解的比较透彻&#xff0c;那么这一块很多东西都很好理解。 从考试的角度来讲&#xff0c;PPP协议…

回归预测 | MATLAB实现BO-SVM贝叶斯优化支持向量机多输入单输出回归预测(多指标,多图)

回归预测 | MATLAB实现BO-SVM贝叶斯优化支持向量机多输入单输出回归预测&#xff08;多指标&#xff0c;多图&#xff09; 目录 回归预测 | MATLAB实现BO-SVM贝叶斯优化支持向量机多输入单输出回归预测&#xff08;多指标&#xff0c;多图&#xff09;效果一览基本介绍程序设计…

RabbitMq-2安装与配置

Rabbitmq的安装 1.上传资源 注意&#xff1a;rabbitmq的版本必须与erlang编译器的版本适配 2.安装依赖环境 //打开虚拟机 yum install build-essential openssl openssl-devel unixODBC unixODBC-devel make gcc gcc-c kernel-devel m4 ncurses-devel tk tc xz3.安装erlan…

OpenCV笔记之solvePnP函数和calibrateCamera函数对比

OpenCV笔记之solvePnP函数和calibrateCamera函数对比 文章目录 OpenCV笔记之solvePnP函数和calibrateCamera函数对比1.cv::solvePnP2.cv::solvePnP函数的用途和工作原理3.cv::solvePnP背后的数学方程式4.cv::SOLVEPNP_ITERATIVE、cv::SOLVEPNP_EPNP、cv::SOLVEPNP_P3P5.一个固定…

AI项目二:基于mediapipe的虚拟绘画

若该文为原创文章&#xff0c;转载请注明原文出处。 一、项目介绍 随着人工智能时代的到来&#xff0c;许多技术得到了空前的发展&#xff0c;让人们更加认识到了线上虚拟技术的强大。 通过mediapipe识别手的关键点&#xff0c;检测中指&#xff0c;实现隔空画画的操作。 通…

Linux/Ubuntu 的日常升级和安全更新,如何操作?

我安装的是Ubuntu 20.04.6 LTS的Windows上Linux子系统版本&#xff0c;启动完成后显示&#xff1a; Welcome to Ubuntu 20.04.6 LTS (GNU/Linux 5.15.90.4-microsoft-standard-WSL2 x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.c…

ros小车实现slam_gmapping建图

ros小车2d建图&#xff0c;如果有雷达&#xff0c;那么使用gmapping方式建图&#xff0c;其实就一个命令&#xff0c;启动建图程序&#xff0c;它默认会启动小车&#xff0c;之后&#xff0c;我们通过手柄或者键盘控制小车就可以有地图产生&#xff0c;然后就需要保存地图&…

【高级IO】- 五种 IO 模型 | 多路转接 - select

IO的基本概念 I/O&#xff08;Input / output&#xff09;就是输入和输出&#xff0c;在冯诺依曼体系中&#xff0c;将数据从输入设备拷贝到内存叫做输入&#xff0c;将数据从内存拷贝到输出设备叫做输出。 对文件进行的读写操作本质就是一种IO&#xff0c;文件IO对应的外设就…

【2023最新爬虫】爬取知乎任意问题下的全部回答

老规矩&#xff0c;先上结果&#xff1a; 爬取了前200多页&#xff0c;每页5条数据&#xff0c;共1000多条回答。&#xff08;程序设置的自动判断结束页&#xff0c;我是手动break的&#xff09; 共爬到13个字段&#xff0c;包含&#xff1a; 问题id,页码,答主昵称,答主性别,…

【Python】json文件的读取

文章目录 1. json简介2.json的使用规范3.json文件的书写4.json文件的读取 1. json简介 JSON&#xff08;JavaScript Object Notation&#xff09;是一种轻量级的数据交换格式&#xff0c;常用于将结构化数据进行传输和存储。它基于JavaScript语法&#xff0c;但可以被多种编程…

玩机搞机----面具模块的组成 制作模块

root面具相信很多玩家都不陌生。早期玩友大都使用第三方卡刷补丁来对系统进行各种修复和添加功能。目前面具补丁代替了这些操作。今天的帖子了解下面具各种模块的组成和几种普遍的代码组成。 Magisk中运行的每个单独的shell脚本都将在内部的BusyBox的shell中执行。对于与第三方…

(排序) 剑指 Offer 21. 调整数组顺序使奇数位于偶数前面 ——【Leetcode每日一题】

❓剑指 Offer 21. 调整数组顺序使奇数位于偶数前面 难度&#xff1a;简单 输入一个整数数组&#xff0c;实现一个函数来调整该数组中数字的顺序&#xff0c;使得所有奇数在数组的前半部分&#xff0c;所有偶数在数组的后半部分。 示例&#xff1a; 输入&#xff1a;nums [1…