开发自救手册
  • 八股文
  • 微服务
ethandu
2024-04-27
目录

Sentinel微服务保护

# 微服务保护

# 初识Sentinel

# 雪崩问题

# 什么是雪崩问题

微服务之间互相调用，因为调用链中的一个服务故障，引起整个链路都无法访问的情况。

image-20220831193107550

# 解决雪崩问题

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

  • 超时处理：设定超时时间，请求超过一定时间美誉相应就返回错误信息，不会无休止等待。

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

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

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

    image-20220831194047046

流量控制是预防雪崩，前面三种是已经出现问题了。

# 服务保护技术对比

image-20220831195551526

Hystrix现在不维护了

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

Sentinel具有以下特征：

image-20220831200039551

# 安装Sentinel控制台

去下载最新的jar包。

https://github.com/alibaba/Sentinel

image-20220831201309612

执行命令：

java -jar sentinel-dashboard-1.8.5.jar

然后访问：localhost:8080 即可看到控制台界面，默认账户密码都是sentinel。

image-20220831201507442

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

image-20220831201625154

举例：

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

# 整合Sentinel和微服务

引入cloud-demo，项目结构如下：

image-20220913124023376

微服务整合Sentinel

我们在order-service中整合Sentinel，并且链接Sentinel的控制台，步骤如下：

  1. 引入sentinel依赖：

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

  2. 配置控制台地址：

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

  3. 访问微服务的任意端点（endpoint，我们Spring MVC的任意一个Controller的接口都是一个端点），触发sentinel监控

访问过一次接口之后再看我们的控制台，就出现结果了。

image-20220913125146196

# 限流规则

首先我们需要知道一个概念：

簇点链路

簇点链路:就是项目内的调用链路，链路中被监控的每个接口就是一个资源。默认情况下sentinel会监控Spring MVC的每一个端点(Endpoint) ，因此Spring MVC的每一 个端 点(Endpoint)就是调用链路中的一个资源。

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

image-20220913125604325

如果我们点击资源/order/{orderId}后面的流控按钮，就可以弹出表单。表单中可以添加流控规则。

image-20220913125738241

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

  • 案例

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

    image-20220913125936782

    创建完成规则后我们使用Jemeter进行测试

    image-20220913130206387

    接着看结果，限流的控制生效了！

    image-20220913130113975

    image-20220913130122352

# 流控模式

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

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

image-20220913130312814

  • 流控模式 - 关联

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

    image-20220913130533784

    当/write资源访问量触发阈值时，就会对/read资源限流，避免影响/write资源。

    • 案例

      需求:

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

      image-20220913130848482

      我们对用Jemeter对/order/update进行QPS大于5的请求，查看结果：

      image-20220913130923292

    • 什么时候使用关联模式？

      • 两个有竞争关系的资源
      • 一个优先级高，一个优先级低

  • 流控模式 - 链路

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

    • /test1→/common
    • /test2 →/common

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

    image-20220913131332366

    • 案例

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

      1. 在OrderService中添加一个queryGoods方法,不用实现业务
      2. 在OrderController中 ，改造/order/query端点，调用OrderService中的queryGoods方法
      3. 在OrderController中 添加一个/order/save的端 点，调用OrderService的queryGoods方法
      4. 给queryGoods设 置限流规则，从/order/query进 入queryGoods的方法限制QPS必须小于2

      设定规则

      image-20220913140417661

      用Jemeter请求，我们的save不受任何影响。

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

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

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

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

      这样之后即便是Service层也可以被监控了。

# 流控效果

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

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

image-20220913151326814

  • 流控效果 - warm up

    在服务刚启动的时候不能就把QPS给打满了

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

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

    image-20220913151601401

    • 案例

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

      image-20220913151650293

      QPS是波动变化的

      image-20220913151708766

      image-20220913151724359

  • 流控效果 - 排队等待

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

    image-20220913151917628

    image-20220913151943807

    • 案例

      流控效果 - 排队等待

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

      image-20220913152048294

      image-20220913152437202

      我们的发送QPS是15，然后多出来的都进入到队列里面去了。

      image-20220913152453176

      最终呈现出来的是非常平稳的QPS，形成了对微服务的保护。

# 热点参数限流

前面的都是常见的，这个是特殊的。

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

image-20220913153110310

  • 配置示例：

    image-20220913153130409

    代表的含义是:对hot这个资源的0号参数(第一个参数)做统计,每1秒相同参数值的请求数不能超过5

商品是有热点商品的，所以限流阈值不应该是一样的

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

image-20220913153349541

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

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

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

  • 案例

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

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

    注意：

    热点参数限流对默认的SpringMVC资源无效

    我们将它覆盖成Sentinel资源

    image-20220913153612818

    image-20220913153704090

    image-20220913153753470

    添加完规则，进行Jemeter测试

    image-20220913153846851

    ==不同的参数，限流的上限是不一样的。热点参数限流是一种更细粒度的限流==

# 隔离和降级

image-20220923131555481

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

线程隔离：

image-20220913154252397

熔断：

image-20220913154235612

# Feign整合Sentinel

不管是线程隔离还是熔断降级，都是对客户端（调用方）的保护

而调用方是Feign，于是实际上是对Feign的保护。

  • Feign整合Sentinel

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

    首先的准备：

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

      feign:
  sentinel:
    enable: true # 开启Feign的Sentinel功能

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

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

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

    image-20220923130625293

    create方法返回的就是UserClient对象，实现方法的过程中就是在编写备用的方案。记录日志，返回友好提示啊之类的。这个就是一个失败降级的业务逻辑了。

    步骤二:在feing- api项目中的DefaultFeignConfiguration类中将UserClientFallbackFactory注册为一个Bean:

    image-20220923130939462

    步骤三:在feing-api项目中的UserClient接口中使用UserClientFallbackFactory:

    image-20220923130958536

    最后我们访问一下接口，这下链路就出来了。其中出现了Feign的请求接口，这下，我们就完成了Feign和Sentinel的整合了。

    image-20220923131431070

# 线程隔离

image-20220923143632484

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

  • 线程池隔离

    • 优点

      • 支持主动超时
      • 支持异步调用

    • 缺点

      • 线程的额外开销比较大

    • 场景

      • 低扇出

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

  • 优点

    • 轻量级，无额外开销

  • 缺点

    • 不支持主动超时
    • 不支持异步调用

  • 场景

    • 高频调用
    • 高扇出（网关就是这样的场景）

  • 线程池隔离（左），信号量隔离（右）

image-20220923131759662

  • Sentinel如何实现线程隔离？

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

    image-20220923143225183

    • QPS: 就是每秒的请求数，在快速入门中已经演示过。
    • 线程数：是改资源能够使用的tomcat线程数的最大值。也就是通过限制线程数量，实现舱壁模式。

  • 案例：

    需求:给UserClient的查询用户接口设置流控规则，线程数不能超过2。然后利用jemeter测试。

    image-20220923143420099

    image-20220923143441768

    image-20220923143506668

    前面的请求实际上都是正常的，后面多于2的请求就降级了。这个就实现了信号量的隔离。

# 熔断降级

image-20220923145146063

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

它是使用状态机来实现的。

Sentinel里面断路器的3个状态，以及切换的流程和作用

image-20220923143806040

熔断策略-慢调用

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

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

    image-20220923144006088

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

  • 案例：

    需求:给UserClient的查询用户接口设置降级规则，慢调用的RT阈值为50ms,统计时间为1秒,最小请求数量为5,失败阈值比例为0.4,熔断时长为5 提示:为了触发慢调用规则，我们需要修改UserService中的业务,增加业务耗时:

    image-20220923144208687

    image-20220923144505707

    我们先刷5次/order/1，然后再看/order/2

    image-20220923144614238

    发现已经熔断了。这个就是慢比例熔断了。

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

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

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

    image-20220923144723285image-20220923144759941

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

  • 案例：

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

    提示:为了触发异常统计,我们需要修改UserService中的业务,抛出异常:

    image-20220923144839350

    image-20220923145006379

    我们刷了5次异常的102，再访问103。出发了异常比例降级。

    image-20220923145107080

# 授权规则

对请求者身份的判断

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

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

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

image-20220923145322780

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

image-20220923145435568

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

image-20220923145546980

我们需要自己编写这个业务逻辑。

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

image-20220923145655313

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

image-20220923145747672

给/order/{orderId}配置授权规则：

image-20220923145813126

# 自定义异常结果

image-20220923150742983

默认情况下，发生限流、降级、授权拦截时，都会抛出异常到调用方。如果要自定义异常时的返回结果，需要实现BlockExceptionHandler接口：

image-20220923150157974

而BlockException包含很多个子类，分别对应不同的场景:

image-20220923150254983

我们在order-service中定义类，实现BlockExceptionHandler接口：

image-20220923150325418

测试：

image-20220923150650180

可以看到被限流了：

image-20220923150657913

# 规则持久化

image-20220923152156519

这章学习如何让Sentinel的规则持久化

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

  • 原始模式（不支持持久化）

    Sentinel的默认模式，将规则保存在内存，重启服务会丢失

  • pull模式(存在处理一致性问题)

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

    image-20220923151012266

  • push模式（我们最推荐的）

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

    image-20220923151130897

    实现push模式

    push模式实现最为复杂，依赖于nacos, 并且需要修改Sentinel控制台源码。

    image-20220923152333777

    我们需要修改OrderService，让其监听Nacos中的sentinel规则配置。

    具体步骤如下：

    • 一、修改order-service服务

      1. 引入依赖

        在order-service中引入sentinel监听nacos的依赖：

        image-20220923152535486

      2. 配置nacos地址

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

        image-20220923152605140

    • 二、修改sentinel-dashboard源码

      SentinelDashboard默认不支持nacos的持久化，需要修改源码

      1. 解压并打开项目

        image-20220923152912167

      2. 修改nacos依赖

        在sentinel-dashboard源码的pom文件中，nacos的依赖默认的scope是test，只能在测试时使用，这里要去除：

        image-20220923153014419

        将sentinel-datasource-nacos依赖的scope去掉：

        image-20220923153100997

      3. 添加nacos支持

        在sentinel-dashboard的test包下，已经编写了对nacos的支持，我们需要将其拷贝到main下。

        image-20220923153422725

      4. 修改nacos地址

        然后，还需要修改测试代码中的NacosConfig类：

        image-20220923154138371

        修改其中的nacos地址，让其读取application.properties中的配置：

        image-20220923154229866

        在sentinel-dashboard的application.properties中添加nacos地址配置：

        nacos.addr=localhost:8848

      5. 配置nacos数据源

        另外，还需要修改com.alibaba.csp.sentinel.dashboard.controller.v2包下的FlowControllerV2类。

        image-20220923154420808

        让我们添加的Nacos数据源生效：

        image-20220923154443390

      6. 修改前端页面

        接下来，还需要修改前端页面，添加一个支持nacos的菜单

        修改src/amin/webapp/resources/app/scripts/directives/sidebar/目录下的sidebar.html文件：

        image-20220923154504714

        将其中的这部分注释打开：

        image-20220923154650957

        修改其中的文本：

        image-20220923154705033

      7. 重新编译、打包项目

        运行IDEA中的maven插件，编译和打包修改好的Sentinel-Dashboard：

        image-20220923155538464

        在sentinel中新增限流规则：

        image-20220923160353152

      在nacos中寻找一下：

      image-20220923160142097

      重启发现已经实现了持久化。

上次更新: 2024/05/02, 13:47:32
RabbitMQ

←

Theme by Vdoing | Copyright © 2019-2024 Backend Development | MIT License