- 使用 Spring Initializr 创建 Spring Boot 应用程序
- 在Spring Boot中配置Cassandra
- 在 Spring Boot 上配置 Tomcat 连接池
- 将Camel消息路由到嵌入WildFly的Artemis上
在上一节中我们知道Sentinel 支持以下几种规则:流量控制规则、熔断降级规则、系统保护规则、来源访问控制规则 和 热点参数规则。
Sentinel 的所有规则都可以在内存态中动态地查询及修改,修改之后立即生效。同时 Sentinel 也提供相关 API,供您来定制自己的规则策略
本篇文章我们来看一下Sentinel的流量控制规则
**流量控制(Flow Control)**其原理是监控应用流量的 QPS 或并发线程数等指标,当达到指定的阈值时对流量进行控制,以避免被瞬时的流量高峰冲垮,从而保障应用的高可用性。
限流的直接表现是在执行流控的时候抛出 FlowException
异常。FlowException
是 BlockException
的子类,我们可以捕捉 BlockException
来自定义被限流之后的处理逻辑。
同一个资源可以对应多条限流规则。FlowSlot
会对该资源的所有限流规则依次遍历,直到有规则触发限流或者所有规则遍历完毕。
一条限流规则主要由下面几个因素组成,我们可以组合这些元素来实现不同的限流效果。
Field | 说明 | 默认值 |
---|---|---|
resource | 资源名,资源名是限流规则的作用对象 | |
count | 限流阈值 | |
grade | 限流阈值类型,QPS 或线程数模式 | QPS 模式 |
limitApp | 流控针对的调用来源 | default ,代表不区分调用来源 |
strategy | 调用关系限流策略:直接、链路、关联 | 根据资源本身(直接) |
controlBehavior | 流控效果(直接拒绝 / 排队等待 / 慢启动模式),不支持按调用关系限流 | 直接拒绝 |
流量控制主要有两种统计类型,一种是统计线程数,另外一种则是统计 QPS。类型由 grade
字段来定义。
打开我们的Sentinel DashBoard界面,在侧边栏菜单的簇点链路
中找到我们需要流控的资源,我们这里是/test/hello
,点击后面的+流控
按钮,即可打开新增流控规则的界面。如下图所示
在新增流控规则的窗口中我们直接展开高级选项(这里暂时不讨论集群方式),如下图所示:
我们也可以在流控规则菜单中点击新增流控规则
,只不过这种方式弹出的新增窗口的资源名要自己指定
我们这里先做一个简单的流控测试,我们将单机阈值
直接设置为1,其余保持默认;按照这样的配置如果一秒内的请求数大于1那么资源就会被直接流控,抛出Blocked by Sentinel (flow limiting)
异常。如下图所示:
线程数限流用于保护业务线程数不被耗尽。例如,当应用所依赖的下游应用由于某种原因导致服务不稳定、响应延迟增加,对于调用者来说,意味着吞吐量下降和更多的线程数占用,极端情况下甚至导致线程池耗尽。为应对高线程占用的情况,业内有使用隔离的方案,比如通过不同业务逻辑使用不同线程池来隔离业务自身之间的资源争抢(线程池隔离),或者使用信号量来控制同时请求的个数(信号量隔离)。这种隔离方案虽然能够控制线程数量,但无法控制请求排队时间。当请求过多时排队也是无益的,直接拒绝能够迅速降低系统压力。Sentinel线程数限流不负责创建和管理线程池,而是简单统计当前请求上下文的线程个数,如果超出阈值,新的请求会被立即拒绝。
我们直接打开新增流控规则
窗口,阈值类型选择并发线程数,单机阈值设置为2。如下图所示:
并发线程数测试我们需要使用JMeter来模拟线程进行压力测试,有关JMeter的使用可以参考文章压力测试工具JMeter的简单使用
我们新建一个线程组,在启动的时候同时发送10个请求,如下所示:
我们点击菜单栏上方绿色的启动按钮启动测试,在结果树中查看执行结果,如下图所示:
在新增流控规则
界面的高级选项中有一项流控模式可供选择,分别是直接
、关联
和链路(后期专门介绍链路,本文不具体展开)
当配置资源在运行过程中超过当前规则配置的阈值之后对该资源请求做相应的流控效果。上面基于QPA/并发数的流量控制
与并发线程数流量控制
中的小试牛刀就是基于这种方式处理的
当配置资源在运行过程中超过当前配置规则配置的阈值之后对他所关联的资源请求做相应的流控效果。对于该迷失的效果请看下面的实例
我们修改TestController.java
,在里面我们新增方法sayBye(),然后重启系统。如下图所示:
/**
* @Author Christy
* @Date 2021/8/6 10:17
**/
@RestController
@RequestMapping("/test")
public class TestController {
private static final Logger log = LoggerFactory.getLogger(TestController.class);
@RequestMapping("/hello")
public String sayHello(){
log.info("Hello, Sentinel!");
return "Hello, Sentinel!";
}
@RequestMapping("/bye")
public String sayBye(){
log.info("Bye, Sentinel!");
return "Bye, Sentinel!";
}
}
我们修改前面的柜子,流控模式选择关联,关联资源写/test/bye
,流控效果(后面讲)暂时选快速失败
我们修改JMeter中的线程组,设置循环每秒钟发送10个请求,如下图所示:
修改http请求路径为/test/bye
,如下图所示:
启动JMeter测试,结果如下所示:
从图中我们可以看到对于关联资源/test/bye
可以正常访问,但是对于资源/test/hello
却被限流了,所以对于关联模式这是一种反向流控:当被关联资源达到阈值,会对资源进行流控
当配置资源在运行过程中超过当前配置规则的阈值后对链路中的资源直接抛出失败。这种模式在后面我们单独拿出来讲,这里先忽略。
流控效果选项只是针对QPS来说的,如果我们将阈值类型选择并发线程数
的话可以看到是没有流控效果这一选项的
上面我们演示的例子效果都是直接拒绝,这里就不说了。
我们修改流控规则,阈值类型选择QPS
,单机阈值为10
,流控效果为Warm Up
,预热时长为20
,如下图所示:
通俗一点讲就是我们设置的阈值是10,预热时长是20。那么当大量请求同时涌入系统时,系统会经过20秒钟的预热才会一次处理10个请求,在20秒钟之内先期可能会处理3个、5个、8个再至10个
我们修改线程组线程数为15/s,一直发送。如下图所示:
http请求路径修改为最开始的/test/hello
,如下图所示:
然后们启动JMeter发送请求,注意观察IDEA的控制台输出。
在刚开始的几秒中内每次只请求三次,如下图所示
运行到第6~8秒的时候QPS由4增加到5
在超出20秒以后QPS趋于稳定为10
匀速排队模式就相对简单了。JMeter我们不做改动,按照下图修改规则
这里的超时时间是毫秒,而Warm Up的预热时间单位是秒,这里要注意
控制台每秒打印输出的次数就是我们设置的阈值,这就是匀速排队的效果。
本系列专题源码已经上传至gitee:https://gitee.com/tide001/springcloud_parent,欢迎下载交流
这也不是一篇非常详细的源码领读,源码细节还需你自己仔细咀嚼 这只是我在改了些sentinel bug后,梳理的脉络,主要是脉络。看完后对Sentinel的源码模块划分和大致交互有个整体印象。 从而
还有其他类似的问题,但我想将其归结为最基本的问题。 我正在运行一个 .NET 应用程序 (C#) 并尝试连接并监视一组运行哨兵 ( 3x 哨兵监控 1 个主站和 2 个从站)。它们在 linux 机器
我们有 2 个运行 HA 应用程序的应用程序/Web 服务器,我们需要设置具有高可用性/复制功能的 Redis 以支持我们的应用程序。 考虑到 3 个节点的最低哨兵设置要求。 我们计划准备第一个应用程
我想知道是否可以将 Azure AD 用户配置文件详细信息(使用位置、国家或地区、办公室)获取到 azure Sentinel 日志中? Kusto 查询会是什么? 最佳答案 此功能将作为 Azure
Sentinel Dashboard限流规则保存 sentinel在限流规则配置方面提供了可视化页面 sentinel dashboard,源码可从github下载,请自行搜索,此处不提供下载链接
概念 何为热点?热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据,并对其访问进行限制。比如: 商品 ID 为参数,统计一段时间内最常购买的商品 ID 并进行限制
概述 除了流量控制以外,对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。由于调用关系的复杂性,如果调用链路中的某个资源不稳定,最终会导致请求发生堆积。Sentinel 熔断降级会在调
前言 在上一节中我们知道Sentinel 支持以下几种规则:流量控制规则、熔断降级规则、系统保护规则、来源访问控制规则 和 热点参数规则。 Sentinel 的所有规则都可以在内存态中动态地查询及修改
在之前使用Nacos持久化规则的文档中,最后发现只能使用Nacos推送配置到控制台,那么怎么实现控制台和Nacos的双向同步呢? 这里不直接提供解决方案,我们还是先分析下控制台的源码。 下面我们分
化整为零 我们已经知道了Slot是从第一个往后一直传递到最后一个的,且当信息传递到StatisticSlot时,这里就开始进行统计了,统计的结果又会被后续的Slot所采用,作为规则校验的依据。我们先
Sentinel简介 Sentinel 是阿里中间件团队开源的,面向分布式服务架构的轻量级高可用流量控制组件,主要以流量为切入点,从流量控制、熔断降级、系统负载保护等多个维度来帮助用户保护服务的稳定
之前遗留问题 之前我们集成了Nacos,实现了推送规则到客户端,但是控制台添加的规则不能持久化到Naocs中,这时需要对控制台源码进行改造。 先来回顾下默认添加流控规则的执行流程: 1、 控
Sentinel 中有很多比较重要的概念,我们要了解一个框架,首先要对框架中重要的概念实体进行分析,本文我将跟大家一起来分析一下 Sentinel 中非常重要的几个概念。 Resource Res
通过sentinel 的控制台,我们可以对规则进行查询和修改,也可以查看到实时监控,机器列表等信息,所以我们需要对 sentinel 的控制台做个完整的了解。 启动控制台 从github上下载源码
随着微服务的流行,服务和服务之间的稳定性变得越来越重要。Sentinel 是面向分布式服务架构的流量控制组件,主要以流量为切入点,从流量控制、熔断降级、系统自适应保护等多个维度来帮助您保障微服务的稳定
控制台 控制台主要的处理类是 FlowControllerV1 。 @RestController @RequestMapping(value = "/v1/flow") pu
项目结构 将Sentinel的源码fork到自己的github库中,接着把源码clone到本地,然后开始源码阅读之旅吧。 首先我们看一下Sentinel项目的整个结构: sentine
雪崩效应 雪崩 一种自然现象,当山坡积雪内部的内聚力抗拒不了它所受到的重力拉引时,便向下滑动,引起大量雪体崩塌。 雪崩效应广泛应用于各种领域,比如密码学术语、管理学、商业等。 服务雪崩 在软件
实时监控 集成控制台后,当有请求时,实时监控页面会显示当前服务各个接口的访问信息,以图表的形式展示给用户,包含访问时间、通过 QPS、拒绝QPS、响应时间(ms)等信息。 簇点链路 列表:用
实时监控 Sentinel 提供对所有资源的实时监控,我们可以通过控制台查看。 可以很清楚的看到当前QPS流量趋势。 监控API 簇点监控 获取簇点列表 API: GET /cluste
我是一名优秀的程序员,十分优秀!