微服务保护--Sentinel

淡淡的烟草味﹌ 2024-03-23 10:05 88阅读 0赞

#### 文章目录 ####

*   *  一、雪崩问题
     *   *  1.1 解决办法
     *  二、服务保护技术的对比
     *  三、安装并整合Sentinel控制台
     *  四、限流规则
     *   *  4.1 簇点链路
         *  4.2 流控模式
         *  4.3 流控效果
         *  4.4 热点参数限流
     *  五、隔离和降级
     *   *  5.1 Feign整合Sentinel
         *  5.2 线程隔离
         *  5.3 熔断降级
     *  六、授权规则
     *  七、自定义异常结果
     *  八、规则持久化
     *   *  8.1 规则管理模式

本篇博客主要是个人总结，有大致的思路逻辑，想要更加清晰的了解，下方有黑马的视频，自行观看，通俗易懂。

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

**特征**：丰富的应用场景、完备的实时监控、广泛的开源生态、完善的 SPI 扩展点。

### 一、雪崩问题 ###

**解释**：微服务调用链路中的某个服务故障，引起整个链路中的所有微服务都不可用，这就是雪崩。（一个服务器的Tomcat资源耗尽，导致依赖的服务全部故障）

#### 1.1 解决办法 ####

解决雪崩问题有**四种办法**如下：

*  **超时处理**：设定**超时时间**，请求超过一定时间没有响应就返回错误信息，不会无休止等待。 – 因服务故障引起的雪崩问题
 *  **舱壁模式**：限定每个业务能使用的**线程数**，避免耗尽整个tomcat的资源，因此也叫线程隔离。 – 因服务故障
 *  **熔断降级**：由**断路器**统计业务执行的异常比例，如果超出阈值则会**熔断**该业务，拦截访问该业务的一切请求。 – 因服务故障
 *  **流量控制**：限制业务访问的**QPS**，避免服务因流量的突增而故障。（QPS:每秒钟处理请求的数量） – 因高并发流量导致服务故障

### 二、服务保护技术的对比 ###

Sentinel的对比，Hystrix已经不维护了。具体对比如下：

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

### 三、安装并整合Sentinel控制台 ###

*  sentinel官方提供了UI控制台，方便我们对系统做限流设置。下载好的jar包，将其拷贝到一个你能记住的非中文目录，然后运行命令：`java -jar sentinel-dashboard-1.8.1.jar`，然后访问：localhost:8080 即可看到控制台页面，默认的账户和密码都是sentinel。
 *  打开在命令行的nacos的bin目录下输入`startup.cmd -m standalone`启动nacos。接着打开实用篇的代码，将yaml文件的信息做出相应的修改，这是本人的，MySQL有5和8两个版本，由于前面是匹配虚拟机里的数据库，换回MySQL5，端口3305。还有将前面的nacos地址换回localhost，还需要修改order-service的端口号，不然与sentinel的控制台端口冲突。
 *  在order-service中整合Sentinel，并且连接Sentinel的控制台。引入sentinel依赖；配置控制台地址；访问微服务的任意端点，触发sentinel监控。

### 四、限流规则 ###

#### 4.1 簇点链路 ####

*  项目内的调用链路，链路中被监控的每个接口就是一个资源。默认情况下sentinel会监控SpringMVC的每一个端点（Endpoint），因此SpringMVC的每一个端点（Endpoint）就是调用链路中的一个资源。  
    流控、熔断等都是针对簇点链路中的资源来设置的。
 *  流控规则入门案例：给 /order/\{orderId\}这个资源设置流控规则，QPS不能超过 5。然后利用jemeter测试。

#### 4.2 流控模式 ####

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

*  **直接**：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式。
 *  **关联**：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流。（满足下面条件：两个有竞争关系的资源；一个优先级较高，一个优先级较低\[限流\]）
 *  **链路**：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流。（有查询订单和创建订单业务，两者都需要查询商品。针对从查询订单进入到查询商品的请求统计，并设置限流。）

#### 4.3 流控效果 ####

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

*  快速失败：达到阈值后，新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。
 *  warm up：预热模式，对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化，从一个较小值逐渐增加到最大阈值。（给/order/\{orderId\}这个资源设置限流，最大QPS为10，利用warm up效果，预热时长为5秒）
 *  排队等待：让所有的请求按照先后次序排队执行，两个请求的间隔不能小于指定时长（给/order/\{orderId\}这个资源设置限流，最大QPS为10，利用排队的流控效果，超时时长设置为5s）

#### 4.4 热点参数限流 ####

*  之前的限流是统计访问某个资源的所有请求，判断是否超过QPS阈值。而热点参数限流是分别统计参数值相同的请求，判断是否超过QPS阈值。
 *  案例：给/order/\{orderId\}这个资源添加热点参数限流，规则如下：默认的热点参数规则是每1秒请求量不超过2；给102这个参数设置例外：每1秒请求量不超过4；给103这个参数设置例外：每1秒请求量不超过10。
 *  热点参数限流对默认的SpringMVC资源无效。

### 五、隔离和降级 ###

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

#### 5.1 Feign整合Sentinel ####

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

Feign整合Sentinel的步骤如下：

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

#### 5.2 线程隔离 ####

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

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th>优点</th> 
   <th>缺点</th> 
   <th>场景</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>信号量隔离-Sentinel默认</td> 
   <td>轻量级，无额外开销</td> 
   <td>不支持主动超时 不支持异步调用</td> 
   <td>高频调用高扇出</td> 
  </tr> 
  <tr> 
   <td>线程池隔离</td> 
   <td>支持主动超时支持异步调用</td> 
   <td>线程的额外开销比较大</td> 
   <td>低扇出</td> 
  </tr> 
 </tbody> 
</table>

*  案例：线程隔离（舱壁模式）-- 给 UserClient的查询用户接口设置流控规则，线程数不能超过 2。然后利用jemeter测试。
 *  信号量隔离的特点：基于计数器模式，简单，开销小。
 *  线程池隔离的特点：基于线程池模式，有额外开销，但隔离控制更强。

#### 5.3 熔断降级 ####

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

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

*  **慢调用**：业务的响应时长（RT）大于指定时长的请求认定为慢调用请求。在指定时间内，如果请求数量超过设定的最小数量，慢调用比例大于设定的阈值，则触发熔断。
 *  案例：给 UserClient的查询用户接口设置降级规则，慢调用的RT阈值为50ms，统计时间为1秒，最小请求数量为5，失败阈值比例为0.4，熔断时长为5。提示：为了触发慢调用规则，我们需要修改UserService中的业务，增加业务耗时。
 *  **异常比例或异常数**：统计指定时间内的调用，如果调用次数超过指定请求数，并且出现异常的比例达到设定的比例阈值（或超过指定异常数），则触发熔断。
 *  案例：给 UserClient的查询用户接口设置降级规则，统计时间为1秒，最小请求数量为5，失败阈值比例为0.4，熔断时长为5s。

### 六、授权规则 ###

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

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

**获取请求来源**的接口–`RequestOriginParser`。

### 七、自定义异常结果 ###

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

<table> 
 <thead> 
  <tr> 
   <th><strong>异常</strong></th> 
   <th><strong>说明</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>FlowException</td> 
   <td>限流异常</td> 
  </tr> 
  <tr> 
   <td>ParamFlowException</td> 
   <td>热点参数限流的异常</td> 
  </tr> 
  <tr> 
   <td>DegradeException</td> 
   <td>降级异常</td> 
  </tr> 
  <tr> 
   <td>AuthorityException</td> 
   <td>授权规则异常</td> 
  </tr> 
  <tr> 
   <td>SystemBlockException</td> 
   <td>系统规则异常</td> 
  </tr> 
 </tbody> 
</table>

### 八、规则持久化 ###

#### 8.1 规则管理模式 ####

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

*  **原始模式**：控制台配置的规则直接推送到Sentinel客户端，也就是我们的应用。然后保存在内存中，服务重启则丢失。
 *  **pull模式**：控制台将配置的规则推送到Sentinel客户端，而客户端会将配置规则保存在本地文件或数据库中。以后会定时去本地文件或数据库中查询，更新本地规则。
 *  **push模式**：控制台将配置规则推送到远程配置中心，例如Nacos。Sentinel客户端监听Nacos，获取配置变更的推送消息，完成本地配置更新。

<table> 
 <thead> 
  <tr> 
   <th><strong>推送模式</strong></th> 
   <th><strong>存储位置</strong></th> 
   <th><strong>优点</strong></th> 
   <th><strong>缺点</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>原始模式</td> 
   <td>保存在内存</td> 
   <td>简单，无任何依赖</td> 
   <td>不保证一致性；规则保存在内存中，重启即消失。严重不建议用于生产环境</td> 
  </tr> 
  <tr> 
   <td>Pull 模式</td> 
   <td>保存在本地文件或数据库，定时去读取</td> 
   <td>简单，无任何依赖；规则持久化</td> 
   <td>不保证一致性；实时性不保证，拉取过于频繁也可能会有性能问题。</td> 
  </tr> 
  <tr> 
   <td><strong>Push</strong> <strong>模式</strong></td> 
   <td>保存在nacos，监听变更实时更新</td> 
   <td>规则持久化；一致性；</td> 
   <td>引入第三方依赖</td> 
  </tr> 
 </tbody> 
</table>

\->微服务技术栈高级篇–微服务保护–Sentinel课程视频\`

[高级篇Day1-01-初识Sentinel\_哔哩哔哩\_bilibili][Day1-01-_Sentinel_bilibili]

`<-`

`记录每一个学习瞬间`

[Day1-01-_Sentinel_bilibili]: https://www.bilibili.com/video/BV1LQ4y127n4/?p=143&vd_source=d3e01a57b1e96968088fe21f334a1693