首页 > 其他分享 >十一、Sentinel之系统规则

十一、Sentinel之系统规则

时间:2023-07-05 19:56:35浏览次数:41  
标签:RT 十一 load 请求 系统 流量 规则 Sentinel 水管

Sentinel 系统自适应保护从整体维度对应用入口流量进行控制,结合应用的 Load、总体平均 RT、入口 QPS 和线程数等几个维度的监控指标,让系统的入口流量和系统的负载达到一个平衡,让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。

一、背景

在开始之前,先回顾一下 Sentinel 做系统自适应保护的目的:

  • 保证系统不被拖垮

  • 在系统稳定的前提下,保持系统的吞吐量

长期以来,系统自适应保护的思路是根据硬指标,即系统的负载 (load1) 来做系统过载保护。当系统负载高于某个阈值,就禁止或者减少流量的进入;当 load 开始好转,则恢复流量的进入。这个思路给我们带来了不可避免的两个问题:

  • load 是一个“果”,如果根据 load 的情况来调节流量的通过率,那么就始终有延迟性。也就意味着通过率的任何调整,都会过一段时间才能看到效果。当前通过率是使 load 恶化的一个动作,那么也至少要过 1 秒之后才能观测到;同理,如果当前通过率调整是让 load 好转的一个动作,也需要 1 秒之后才能继续调整,这样就浪费了系统的处理能力。所以我们看到的曲线,总是会有抖动。

  • 恢复慢。想象一下这样的一个场景(真实),出现了这样一个问题,下游应用不可靠,导致应用 RT 很高,从而 load 到了一个很高的点。过了一段时间之后下游应用恢复了,应用 RT 也相应减少。这个时候,其实应该大幅度增大流量的通过率;但是由于这个时候 load 仍然很高,通过率的恢复仍然不高。

TCP BBR 的思想给了我们一个很大的启发。我们应该根据系统能够处理的请求,和允许进来的请求,来做平衡,而不是根据一个间接的指标(系统 load)来做限流。最终我们追求的目标是 在系统不被拖垮的情况下,提高系统的吞吐率,而不是 load 一定要到低于某个阈值。如果我们还是按照固有的思维,超过特定的 load 就禁止流量进入,系统 load 恢复就放开流量,这样做的结果是无论我们怎么调参数,调比例,都是按照果来调节因,都无法取得良好的效果。

Sentinel 在系统自适应保护的做法是,用 load1 作为启动控制流量的值,而允许通过的流量由处理请求的能力,即请求的响应时间以及当前系统正在处理的请求速率来决定。

二、系统规则

系统保护规则是从应用级别的入口流量进行控制,从单台机器的总体 Load、RT、入口 QPS 和线程数四个维度监控应用数据,让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。

系统保护规则是应用整体维度的,而不是资源维度的,并且仅对入口流量生效。入口流量指的是进入应用的流量(EntryType.IN),比如 Web 服务或 Dubbo 服务端接收的请求,都属于入口流量。

系统规则支持以下的阈值类型:

  • Load(仅对 Linux/Unix-like 机器生效):当系统 load1 (1分钟的平均负载)超过阈值,且系统当前的并发线程数超过系统容量时才会触发系统保护。系统容量由系统的 maxQps * minRt 计算得出。设定参考值一般是 CPU cores * 2.5。

  • CPU usage(1.5.0+ 版本):当系统 CPU 使用率超过阈值即触发系统保护(取值范围 0.0-1.0)。

  • RT:当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护,单位是毫秒。

  • 线程数:当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。

  • 入口 QPS:当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护。

三、原理

先用经典图来镇楼:
 

 
我们把系统处理请求的过程想象为一个水管,到来的请求是往这个水管灌水,当系统处理顺畅的时候,请求不需要排队,直接从水管中穿过,这个请求的RT是最短的;反之,当请求堆积的时候,那么处理请求的时间则会变为:排队时间 + 最短处理时间。

  • 推论一: 如果我们能够保证水管里的水量,能够让水顺畅的流动,则不会增加排队的请求;也就是说,这个时候的系统负载不会进一步恶化。

我们用 T 来表示(水管内部的水量),用RT来表示请求的处理时间,用P来表示进来的请求数,那么一个请求从进入水管道到从水管出来,这个水管会存在 P * RT 个请求。换一句话来说,当 T ≈ QPS * Avg(RT) 的时候,我们可以认为系统的处理能力和允许进入的请求个数达到了平衡,系统的负载不会进一步恶化。

接下来的问题是,水管的水位是可以达到了一个平衡点,但是这个平衡点只能保证水管的水位不再继续增高,但是还面临一个问题,就是在达到平衡点之前,这个水管里已经堆积了多少水。如果之前水管的水已经在一个量级了,那么这个时候系统允许通过的水量可能只能缓慢通过,RT会大,之前堆积在水管里的水会滞留;反之,如果之前的水管水位偏低,那么又会浪费了系统的处理能力。

  • 推论二: 当保持入口的流量使水管出来的流量达到最大值的时候,可以最大利用水管的处理能力。

然而,和 TCP BBR 的不一样的地方在于,还需要用一个系统负载的值(load1)来激发这套机制启动。

四、演示

在Sentinel dashboard 配置系统规则:
 

 

配置入口QPS为1。对所有的请求都有效。在浏览器中访问http://localhost:7001/consumer/hotKey?a=aa,快速点击刷新,多点几次,看到:
 

 

标签:RT,十一,load,请求,系统,流量,规则,Sentinel,水管
From: https://www.cnblogs.com/shigongp/p/17527173.html

相关文章

  • 第十一届地质资源管理与可持续发展国际学术会议(GRMSD2023)
    第十一届地质资源管理与可持续发展学术会议(GRMSD2023)将于2023年12月17-18日在中国北京召开。 主要目标是促进地质学、资源勘探和开发方面的研究和开发活动,我们诚挚地邀请您出席会议,分享地质、资源勘探开发及相关领域的观点和经验。所有被接受的论文将被EICompendex和Scopus检索......
  • 【十一】JavaScript之案例-todolist
    【十一】JavaScript之案例-todolist基本页面<!DOCTYPEhtml><htmllang="en"><head><metacharset="UTF-8"><title>Title</title><style>body,ul,input{margin:0;padding:......
  • 网络安全开发架构之基于规则引擎的开发架构
    原文合集地址如下,有需要的朋友可以关注本文地址合集地址规则引擎架构常见的表现形式规则引擎架构可以有多种不同的表现形式,以下是一些常见的表现形式:中心化规则引擎中心化规则引擎是指规则引擎的核心逻辑集中在一个中心服务器或平台上。该服务器负责规则的管理、执行和决策......
  • .NET RulesEngine(规则引擎)
    ulesEngine是微软推出的规则引擎,规则引擎在很多企业开发中有所应用,是处理经常变动需求的一种优雅的方法。个人任务,规则引擎适用于以下的一些场景:输入输出类型数量比较固定,但是执行逻辑经常变化;switch条件经常变化,复杂switch语句的替代;会变动的,具有多种条件或......
  • JAVA获取字符串内的括号对(支持多层级);获取括号对的内容;按指定规则返回括号对位置;
    先看结果:处理字符串 "这个是一条测试用的字符串[(5(4(3[(1)(2)]))(7))][(6)]"结果  解决思路:参考正则表达式里面出入站部分 代码实现如下:方法调用“: Stringtest="这个是一条测试用的字符串[(5(4(3[(1)(2)]))(7))][(6)]";LinkedHashMap<Inte......
  • 八、Sentinel之流量控制
    FlowSlot会根据预设的规则,结合前面NodeSelectorSlot、ClusterNodeBuilderSlot、StatistcSlot统计出来的实时信息进行流量控制。限流的直接表现是在执行EntrynodeA=SphU.entry(资源名字)的时候抛出FlowException异常。FlowException是BlockException的子类,您可以捕捉......
  • 六、配置获取规则
    在有了cluster概念后,配置的规则就显得重要了。比如应用部署在A机房,但是并没有在Apollo新建cluster,这个时候Apollo的行为是怎样的?或者在运行时指定了cluster=SomeCluster,但是并没有在Apollo新建cluster,这个时候Apollo的行为是怎样的?接下来就来介绍一下配置获取的规则。一、应......
  • 添加ingress规则的时候报错
    [root@k8s-master01test]#kubectlapply-fweb-ingress.yamlErrorfromserver(InternalError):errorwhencreating"web-ingress.yaml":Internalerroroccurred:failedcallingwebhook"validate.nginx.ingress.kubernetes.io":failedtoca......
  • nginx之location规则详解
    一、语法规则:=开头表示精确匹配^~ 开头表示uri以某个常规字符串开头,理解为匹配url路径即可(非正则)~ 开头表示区分大小写的正则匹配~* 开头表示不区分大小写的正则匹配!~和!~*分别为区分大小写不匹配及不区分大小写不匹配的正则/ 通用匹配,任何请求都会匹配......
  • nginx之proxy_pass规则详解
    在nginx中配置proxy_pass代理转发时,如果在proxy_pass后面的url加/,表示绝对根路径;如果没有/,表示相对路径,把匹配的路径部分也给代理走。假设下面四种情况分别用http://192.168.1.1/proxy/test.html进行访问。第一种:location/proxy/{proxy_passhttp://127.0.0.1/;}代......