Sentinel-微服务保护框架

Sentinel-微服务保护框架

1.初始Sentinel

1.1雪崩问题及解决方案

1.1.1雪崩问题

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

• 超时处理：设定超时时间 请求超过一定时间没有响应就返回错误信息 不会无休止等待(缓解问题未解决)

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

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

• 流量控制：限制业务访问的QPS 避免服务因流量的突增而故障(避免出现雪崩问题)

1.1.2总结

雪崩问题

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

可以认为：

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

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

1.2服务保护技术对比

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

1.3Sentinel介绍和安装

1.3.1初始Sentinel

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

Sentinel 具有以下特征:

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

1.3.2安装Sentinel

将资料提供的jar包放到非中文目录下执行：

java -jar sentinel-dashboard-1.8.1.jar

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

配置项	默认值	说明
server.port	8080	服务端口
sentinel.dashboard.auth.username	sentinel	默认用户名
sentinel.dashboard.auth.password	sentinel	默认密码

例如 修改端口：

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

1.4微服务整合Sentinel

使用Sentinel肯定要结合微服务 这边使用实用篇中cloud-demo工程

项目结构如下：

在order-service中整合sentinel，并连接sentinel的控制台

1.4.1引入Sentinel依赖

在order-service中引入Sentinel依赖

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

1.4.2配置控制台

修改application.yaml文件 并添加内容

server:
  port: 8088
spring:
  cloud: 
    sentinel:
      transport:
        dashboard: localhost:8080

1.4.3访问order-service的任意端点 触发Sentinel监控

访问http://localhost:8088/order/101 这样才能触发sentinel的监控 然后再访问sentinel的控制台 查看效果

2.流量控制

2.1簇点链路

当请求进入微服务时 首先会访问DispatcherServlet 然后进入Controller 其调用Service、Service调用Mapper

这样的一个调用链就叫做簇点链路 簇点链路中被监控的每一个接口就是一个资源

默认情况下sentinel会监控SpringMVC的每一个端点(Endpoint 也就是Controller中的方法)

因此SpringMVC的每一个端点(Endpoint)就是调用链路中的一个资源

例如 刚才访问的order-service中的OrderController中的端点：/order/{orderId}

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

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

2.2快速入门

点击资源/order/{orderId}后面的流控按钮 可以弹出表单 表单中可以填写限流规则 具体如下：

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

2.3流控模式

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

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

2.3.1关联模式

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

配置规则：

语法说明：当/write资源访问量触发阈值时 就会对/read资源限流 避免影响/write资源

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

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

2.3.2链路模式

链路模式：只针对从指定链路访问到本资源的请求做统计 判断是否超过阈值

配置示例：

例如有两条请求链路：

• /test1 --> /common

• /test2 --> /common

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

给Service层中的方法添加@SentinelResource注解以达到Sentinel添加资源：

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

链路模式中 是对不同来源的两个链路做监控

<