springcloud入门——Sentinel流控

目录

 1.Sentinel 简介

2.Sentinel初始化监控

3.Sentinel流控规则简介

4.Sentinel流控规则应用

---

 1.Sentinel 简介

随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。其功能与Hystrix类似。

一句话，Sentinel就是一个流量防卫兵。

Sentinel 分为两个部分：

• 核心库（Java 客户端）不依赖任何框架/库，能够运行于所有 Java 运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。
• 控制台（Dashboard）基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等应用容器。

Sentinel 的主要特性：

Hystrix与Sentinel比较：

• Hystrix

需要我们程序员自己手工搭建监控平台

没有一套web界面可以给我们进行更加细粒度化得配置流控、速率控制、服务熔断、服务降级

• Sentinel

单独一个组件，可以独立出来。

直接界面化的细粒度统一配置。

sentinel使用

运行命令：java -jar sentinel-dashboard-1.7.0.jar

（前提：Java 8 环境、8080端口不能被占用）

访问Sentinel管理界面localhost:8080，登录账号密码均为sentinel

2.Sentinel初始化监控

新建模块：cloudalibaba-sentinel-service8401，修改pom

编写yml文件：

编写一个控制类进行测试：

启动Sentinel8080 - java -jar sentinel-dashboard-1.7.0.jar ——>启动微服务8401——>启动8401微服务后查看sentienl控制台

什么都没有。

Sentinel采用懒加载，先执行一次访问才可监控。

效果 - sentinel8080正在监控微服务8401

3.Sentinel流控规则简介

资源名：唯一名称，默认请求路径。
针对来源：Sentinel可以针对调用者进行限流，填写微服务名，默认default（不区分来源）。
阈值类型/单机阈值：

• QPS(每秒钟的请求数量)︰当调用该API的QPS达到阈值的时候，进行限流。
• 线程数：当调用该API的线程数达到阈值的时候，进行限流。

是否集群：不需要集群。
流控模式：

• 直接：API达到限流条件时，直接限流。
• 关联：当关联的资源达到阈值时，就限流自己。
• 链路：只记录指定链路上的流量（指定资源从入口资源进来的流量，如果达到阈值，就进行限流)【API级别的针对来源】。

流控效果：

• 快速失败：直接失败，抛异常。
• Warm up：根据Code Factor（冷加载因子，默认3）的值，从阈值/codeFactor，经过预热时长，才达到设置的QPS阈值。
• 排队等待：匀速排队，让请求以匀速的速度通过，阈值类型必须设置为QPS，否则无效。
   

4.Sentinel流控规则应用

直接——快速失败：

新增流控规则，模式直接—快速失败（默认）：1秒钟内查询1次就是OK，若超过次数1，就直接快速失败，报默认错误。

测试：快速多次点击访问http://localhost:8401/testA

结果：返回页面 Blocked by Sentinel (flow limiting)

线程数——快速失败：

新增流控规则，线程数-直接：当调用该API的线程数达到阈值的时候，进行限流。

（即在里面进行流量控制，此例中一次只能有一个线程访问，其他线程失败）

 关联：

新增流控规则，当关联资源/testB的QPS阀值超过1时，就限流/testA的Rest访问地址，当关联资源到阈值后限制配置好的资源名。（别人达阈值，自己限流）

Postman模拟并发密集访问testB

访问testB成功

postman里新建多线程集合组

将访问地址添加进新新线程组

Run - 大批量线程高并发访问B

Postman运行后，点击访问http://localhost:8401/testA，结果Blocked by Sentinel(flow limiting)

应用场景

如：订单支付接口达阈值，服务器无法承受，限流订单下达接口，减少未来要处理的订单支付。

案例，阀值为10+预热时长设置5秒。

warm-up：

新增流控规则，系统初始化的阀值为5/ 3约等于3：即阀值刚开始为3，然后过了5秒后阀值才慢慢升高恢复到5。

（Warm Up方式，即预热/冷启动方式。当系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮。）

测试

多次快速点击http://localhost:8401/testB - 刚开始不行，后续慢慢OK

应用场景

如：秒杀系统在开启的瞬间，会有很多流量上来，很有可能把系统打死，预热方式就是把为了保护系统，可慢慢的把流量放进来,慢慢的把阀值增长到设置的阀值。

排队等待：

新增流控规则，匀速排队，让请求以均匀的速度通过，阀值类型必须设成QPS，否则无效。

设置：/testA每秒1次请求，超过的话就排队等待，等待的超时时间为20000毫秒。

这种方式主要用于处理间隔性突发的流量，例如消息队列。想象一下这样的场景，在某一秒有大量的请求到来，而接下来的几秒则处于空闲状态，我们希望系统能够在接下来的空闲期间逐渐处理这些请求，而不是在第一秒直接拒绝多余的请求。

注意：匀速排队模式暂时不支持 QPS > 1000 的场景。