Sentinel 微服务保护

目录

1 雪崩问题

2 认识Sentinel 

3 安装Sentinel控制台 

4 引入cloud-demo 

5 簇点链路

 6 快速入门

7 流控模式 

 7.1 流控模式-关联

7.2 流控模式-链路

 8 流控效果

8.1 流控效果-warm up 

8.2 流控效果-排队等待 

---

1 雪崩问题

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

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

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

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

 

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

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

什么是雪崩问题？

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

如何避免因瞬间高并发流量而导致服务故障？

• 流量控制

如何避免因服务故障引起的雪崩问题？

• 超时处理

• 线程隔离

• 降级熔断

服务保护技术对比

2 认识Sentinel 

Sentinel是阿里巴巴开源的一款微服务流量控制组件。官网地址：home

Sentinel 具有以下特征:

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

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

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

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

3 安装Sentinel控制台 

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

1. 将其拷贝到一个你能记住的非中文目录，然后运行命令：

2. 然后访问： localhost:8080 即可看到控制台页面，默认的账户和密码都是 sentinel

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

4 引入cloud-demo 

要使用Sentinel肯定要结合微服务，这里我们使用SpringCloud实用篇中的cloud-demo工程。没有的小伙伴可以在课前资料中找到：

项目结构如下：

 

我们在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.访问微服务的任意端点，触发sentinel监控 

5 簇点链路

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

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

 6 快速入门

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

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

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

1. 设置流控规则：

 

2. jemeter 测试：

7 流控模式 

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

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

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

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

 7.1 流控模式-关联

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

使用场景：比如用户支付时需要修改订单状态，同时用户要查询订单。查询和修改操作会争抢数据库锁，产生竞争。

业务需求是有限支付和更新订单的业务，因此当修改订单业务触发阈值时，需要对查询订单业务限流。

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

需求：

• 在 OrderController 新建两个端点： /order/query 和 /order/update ，无需实现业务

• 配置流控规则，当 /order/ update 资源被访问的 QPS 超过 5 时，对 /order/query 请求限流

7.2 流控模式-链路

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

步骤：

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

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

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

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

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

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

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

 8 流控效果

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

• 快速失败：达到阈值后，新的请求会被立即拒绝并抛出 FlowException 异常。是默认的处理方式。

• warm up ：预热模式，对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化，从一个较小值逐渐增加到最大阈值。

• 排队等待：让所有的请求按照先后次序排队执行，两个请求的间隔不能小于指定时长

8.1 流控效果-warm up 

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

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

8.2 流控效果-排队等待 

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

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