Microservices - MSE V3
流量防护规则适用场景
概述
- 微服务的稳定性一直是您非常关注的话题
- 随着业务从单体架构向分布式架构演进以及部署方式的变化,服务之间的依赖关系变得越来越复杂,业务系统也面临着巨大的高可用挑战
- MSE流量防护就是一款借助流量控制、热点防护等模块,来提高应用高可用能力的产品
- 本文介绍各个流量防护规则以及适用的场景
不稳定场景
在生产环境中您可能遇到过以下不稳定的情况:
- 大促时瞬间洪峰流量使得系统超出最大负载、Load飙高、系统崩溃导致用户无法下单
- “黑马”热点商品击穿缓存、数据库被打垮、挤占正常流量
- 调用端被不稳定第三方服务拖垮、线程池被占满、调用堆积,导致整个调用链路卡死
这些不稳定的场景可能会导致严重后果,但很多时候开发者容易忽视这些与流量、依赖相关的高可用防护。MSE流量防护功能就可以预防这些不稳定因素带来的影响,针对流量进行高可用的防护,从而保障服务“稳如磐石”。
核心场景
流量防护各规则说明和适用的核心场景如下表所示
接口流控规则
描述
通过MSE配置QPS模式的流控规则,当每秒的请求量超过设定的阈值时,会自动拒绝多余的请求
核心场景
适用于需要限制突发的流量,在尽可能处理请求的同时来保障服务不被击垮的场景
并发隔离规则
描述
控制某些调用的并发数(即正在进行的数目),防止过多的慢调用挤占正常的调用
核心场景
在调用第三方服务时,防止过多的慢调用挤占正常调用的资源,避免服务不可用
熔断规则
描述
对不稳定的弱依赖调用进行自动熔断降级,暂时切断下游不稳定的调用,避免局部不稳定因素导致整体的雪崩
核心场景
避免局部不稳定因素(某个慢调用、异常服务)导致整体的雪崩,例如切断某个RT高的第三方服务调用
热点参数防护规则
描述
自动识别热点参数并控制每个热点值的访问频次或并发量,可以有效地防止过“热”的参数访问挤占正常的调用资源
核心场景
适用于针对某些热点数据中访问频次最高的Top数据进行控制的场景,例如针对一段时间内最频繁购买的商品ID进行控制,防止突发热点商品击穿缓存而导致大量请求到数据库的情形
流量控制规则
场景说明
- 流量是随机、不可预测的,可能就在某一时间会出现流量洪峰,例如双十一零点的场景
- 然而系统的容量总是有限的,如果突如其来的流量超过了系统的承受能力,就可能会导致请求处理堆栈、堆积的请求处理缓慢、CPU/Load飙高,最后导致系统崩溃
- 因此,您需要针对这种突发的流量来进行限制,在尽可能处理请求的同时来保障服务不被击垮,这就是流量控制
- 流量控制的场景是非常通用的,适用于脉冲流量类等场景
流控规则说明
- 通常在Web入口或服务提供方(Service Provider)的场景下,需要保护服务提供方自身不被流量洪峰打垮
- 此时通常根据服务提供方的服务能力进行流量控制,或针对特定的服务调用方进行限制
- 您可以结合前期压测评估核心接口的承受能力,通过MSE配置QPS模式的流控规则,当每秒的请求量超过设定的阈值时,会自动拒绝多余的请求
并发控制
场景说明
- 一个服务常常会调用别的模块,可能是另外一个远程服务、数据库,或者第三方API等
- 例如,支付的时候,可能需要远程调用银联提供的API;查询某个商品的价格,可能需要进行数据库查询
- 然而,这个被依赖服务的稳定性是不能保证的
- 如果依赖的服务出现了不稳定的情况,请求的响应时间变长,则调用服务的方法的响应时间也会变长,线程会产生堆积,最终可能耗尽业务自身的线程池,服务本身也变得不可用
微服务的架构示例图如下:
- 现代微服务架构都是分布式的,由许多微服务组成
- 不同服务之间相互调用,组成复杂的调用链路
- 以上的问题在链路调用中会产生放大的效果
- 复杂链路上的某一环不稳定,就可能会层层级联,最终导致整个链路都不可用
规则说明
- MSE提供流量并发控制的能力,避免慢调用等不稳定因素造成服务不可用
- 并发控制作为一种轻量级隔离的手段,控制某些调用的并发数(即正在进行的数目),防止过多的慢调用挤占正常的调用
热点参数防护规则
场景说明
- 为了防止被大流量打垮,您通常会对核心接口配置限流规则,但有的场景下配置普通的流控规则是不够的
- 例如大促峰值的时候,会有不少“热点”商品,这些热点商品的瞬时访问量非常高
- 通常您可以事先预测一波热点商品,并对这些商品信息进行缓存“预热”,以便在出现大量访问时可以快速返回而不会都经过数据库
- 但每次大促都会涌现出一些“黑马”商品,这些“黑马”商品是无法事先预测的,没有被预热
- 当这些“黑马”商品访问量激增时,大量的请求会击穿缓存,直接经过数据库,导致数据库访问缓慢,挤占正常商品请求的资源池,最后导致系统崩溃
规则说明
此时,利用MSE的热点参数流控能力,自动识别热点参数并控制每个热点值的访问频次或并发量,可以有效地防止过“热”的参数访问挤占正常的调用资源
配置流控规则
概述
- 配置流控规则的原理是监控应用或服务流量的QPS指标,当指标达到设定的阈值时立即拦截流量,避免应用被瞬时的流量高峰冲垮,从而保障应用高可用性
- 本文介绍如何配置管理流控规则,以及常用场景的流控配置规则
前提条件
- 开通企业版
- MSE治理中心已接入微服务应用
背景信息
- 流量控制在网络传输中是一个常用的概念,常用于调整网络包的发送数据
- 系统需处理的请求是随机不可控的,而系统的处理能力是有限的,因此就需要根据系统的处理能力对流量进行控制
功能入口
- 登录MSE治理中心控制台,并在顶部菜单栏选择地域
- 在左侧导航栏,选择治理中心 > 应用治理
- 在应用列表页面,单击目标应用的资源卡片
- 进入应用之后,选择以下任意一种方法新建流控规则:
- 在左侧导航栏,单击应用概览。单击通过QPS TOP页签,然后单击对应接口的操作列下的流控
- 在左侧导航栏,单击接口详情。单击接口流控页签,然后单击新增流控规则
- 在左侧导航栏,单击流量治理。单击流量防护页签,再单击接口流控页签,然后单击新增流控规则
- 在新增流控防护规则或新增规则对话框中配置规则信息
- 单击新建
常用场景
削峰填谷,使流量匀速通过
- 请求流量具有波峰波谷的特点,流控的原理是将前面的峰值流量延迟(排队时长)到后面再处理,既能最大化满足所有请求,又能保证用户体验
- 在新增流控防护规则或新增规则对话框中配置以下规则信息
- 配置匀速模式下请求单机QPS阈值为5
- 流控效果选择排队等待
- 超时时间为5s
- 系统则每 200ms 处理一条请求,多余的处理任务将排队;同时设置了等待时长为5s,则预计排队时长超过5s的处理任务将快速失败,直接返回默认流控信息,如文本、静态页面等
更多信息
- 接口名称
- 待流控的资源名称
- 是否开启
- 打开开关表示启用该规则,关闭开关表示禁用该规则
- 开关修改之后会立即生效
- 单机QPS阈值
- 触发对流控接口的统计维度对象的QPS阈值
- 流控效果
- 快速失败
- 达到阈值时,立即拦截请求
- 按照应用系统设置中的适配模块配置信息,进行内容返回
- 排队等待
- 请求匀速通过,允许排队等待,通常用于请求调用削峰填谷等场景
- 需设置具体的超时时间,达到超时时间后请求会快速失败
- 快速失败
配置熔断规则
概述
- MSE的熔断规则可以监控应用内部或者下游依赖的响应时间或异常比例
- 当达到指定的阈值时,MSE会立即降低下游依赖的优先级
- 在指定的时间内,系统不会调用该异常资源,避免应用的不稳定运行,从而保障应用高可用性
- 指定时间过后,系统会重新恢复对该资源的调用
- 本文介绍如何配置熔断规则以及规则的配置示例
背景信息
熔断规则配置通常用于弱依赖降级场景
- 除流量控制外,对调用链路中不稳定的方法或者下游依赖进行熔断也是流量防护的重要措施之一
- 由于调用关系的复杂性,如果调用链路中的某一环节出现错误,会导致此请求失败,甚至放大不稳定性,导致整个链路无法正常服务
- 熔断功能会在调用链路中某个方法出现不稳定时(例如某方法出现Timeout或异常比例升高),对这个方法的调用进行限制,让请求快速失败,避免此错误影响整个链路
- 关于熔断的相关信息,请参见下图
功能入口
- 登录MSE治理中心控制台,并在顶部菜单栏选择地域
- 在左侧导航栏,选择治理中心 > 应用治理
- 在应用列表页面单击目标应用的资源卡片,选择以下任意一种方法新建流控规则
- 在左侧导航栏,单击接口详情,切换至客户端接口列表。选择具体接口后,单击服务熔断页签,然后单击新增熔断规则
- 在左侧导航栏,单击流量治理。单击流量防护页签,单击熔断规则,然后单击新增熔断规则
- 在新增熔断防护规则对话框中配置规则信息,然后单击新增
规则详情
- 接口名称
- 适用该规则的应用资源
- 统计窗口时长
- 统计的时间窗口长度,取值范围为1秒~120分钟
- 最小请求数目
- 触发熔断的最小请求数目,若当前统计窗口内的请求数小于此值,即使达到熔断条件规则也不会触发
- 阈值类型 - 选择以慢调用比例(%)或异常比例(%)作为阈值
- 选择以慢调用比例作为阈值,需要设置允许的慢调用RT(即最大的响应时间),请求的响应时间大于该值则统计为慢调用
- 在熔断比例阈值中设置触发熔断的慢调用比例
- 规则开启后,在单位统计时长内请求数目大于设置的最小请求数目,并且慢调用的比例大于阈值,则接下来的熔断时长(s)内请求会自动被熔断
- 经过熔断时长后熔断器会进入探测恢复状态,若接下来的一个请求响应时间小于设置的慢调用RT则结束熔断,若大于设置的慢调用RT则会再次被熔断
- 选择以异常比例作为阈值,需要在熔断比例阈值中设置触发熔断的异常比例
- 规则开启后,在单位统计时长内请求数量大于最小请求数据,并且异常请求的比例大于阈值,则接下来的熔断时长(s)内请求会自动被熔断
- 选择以慢调用比例作为阈值,需要设置允许的慢调用RT(即最大的响应时间),请求的响应时间大于该值则统计为慢调用
- 熔断时长(s)
- 即熔断触发后持续的时间
- 资源进入熔断状态后,在配置的熔断时长内,请求都会快速失败
- 熔断恢复策略
- 熔断器进入恢复阶段(半开启状态)的恢复策略
- 单次探测恢复
- 经过熔断时长后,熔断器会对接下来的一个请求进行探测,若该请求符合预期(不为慢调用或没有异常),则结束熔断;否则重新回到熔断阶段
- 渐进式恢复:需要设置恢复阶段数和每步最小通过数目
- 经过熔断时长后,熔断器按照设定的恢复阶段数进行渐进式恢复,若该阶段内请求达到一定量即每步最小通过数目,则触发检查。检查的请求若都未超过阈值,则逐步提高允许通过的请求比例,直到请求完全恢复;若某一步的指标超出阈值,则重新回到熔断阶段。
- 请求比例T=100/恢复阶段数N,则第一阶段请求比例为T,第二阶段为2T,直到100%。
- 例如恢复阶段数为3,每步最小通过数目为5,则三个阶段分别按照33%、67%和100%的比例放入请求,当每阶段的请求数目大于等于5时进行检查,若请求的指标未超阈值则进入下一恢复阶段,直至完全恢复。
熔断器状态机
上述规则参数背后是一个标准的熔断器状态机(与 Sentinel CircuitBreaker 的 CLOSED/OPEN/HALF_OPEN 三态、Hystrix/Resilience4j 的实现同构):
stateDiagram-v2
direction TB
Closed : 关闭 CLOSED<br/>正常放行,持续统计
Open : 打开 OPEN<br/>快速失败,不碰下游
HalfOpen : 半开 HALF-OPEN<br/>按恢复策略探测
[*] --> Closed
Closed --> Open : 请求数 ≥ 最小请求数目<br/>且比例 > 阈值
Open --> HalfOpen : 熔断时长耗尽
HalfOpen --> Closed : 探测符合预期<br/>完全恢复
HalfOpen --> Open : 探测仍失败<br/>重新熔断计时
半开状态内部的两种恢复策略:
stateDiagram-v2
direction TB
Probe : 单次探测恢复<br/>放行 1 个请求验证
Progressive : 渐进式恢复<br/>N = 恢复阶段数
[*] --> Probe : 恢复策略 = 单次探测
[*] --> Progressive : 恢复策略 = 渐进式
Progressive --> Progressive : 第 k 阶段放量 k×(100/N)%<br/>检查通过 → 下一阶段
- 单次探测:放行接下来 1 个请求,符合预期则结束熔断,否则重新回到熔断阶段
- 渐进式:按
T = 100/恢复阶段数 N的步长逐阶段放量(N=3 → 33% → 67% → 100%),每阶段累积到每步最小通过数目才做检查,避免半开瞬间放量再次打垮尚未恢复的下游
几个参数与状态的对应关系:
- 统计窗口时长 + 最小请求数目:作用于
CLOSED状态——避免低流量时个别慢请求误触发(分母太小导致比例失真) - 熔断时长:决定
OPEN状态持续多久——期间请求快速失败,完全不触碰下游,给下游喘息时间 - 熔断恢复策略:决定
HALF-OPEN的行为——单次探测是标准实现(放行 1 个请求验证);渐进式恢复是 MSE 的扩展,按100/恢复阶段数 N的步长逐阶段放量(如 N=3 → 33% → 67% → 100%),每阶段累积到”每步最小通过数目”才做检查,避免半开瞬间放量再次打垮尚未恢复的下游 - 半开失败回退:探测不符合预期则重新回到
OPEN且熔断时长重新计时——这就是熔断器”自愈”与”震荡”的来源
常用场景1:慢调用熔断示例
- 例如调用第三方服务,但响应时间太慢,会影响当前接口,所以对其进行熔断操作
- 在新增熔断防护规则对话框中配置以下示例规则信息
| 参数 | 示例值 | 描述 |
|---|---|---|
| 接口名称 | test | 接口名称 |
| 统计窗口时长 | 1 | 统计时长为1秒 |
| 最小请求数目 | 10 | 触发熔断的最小请求数目为10 |
| 阈值类型 | 慢调用比例 | 选择以慢调用比例作为阈值 |
| 慢调用RT | 1000 | 超过1000毫秒则判定为慢请求 |
| 熔断比例阈值 | 80% | 触发熔断的慢调用比例阈值为80% |
| 熔断时长(s) | 10 | 熔断时长有10秒 |
| 熔断恢复策略 | 单次探测恢复 | 经过熔断时长后,熔断器会对接下来的一个请求进行探测,若该请求符合预期(不为慢调用或没有异常),则结束熔断;否则重新回到熔断阶段 |
- 规则开启后,在统计时长1秒内,当请求数目大于10,并且慢调用的比例大于80%的时候,则在接下来10秒的熔断时长内,请求都会快速失败
- 经过10秒后熔断器会进入探测恢复状态,若接下来的一个请求响应时间小于设置的1000 ms则结束熔断,若大于1000 ms则会再次被熔断
常用场景2:异常熔断示例
- 例如第三方内容展示时,系统会出现异常,当异常比例较高时,可以对其进行熔断操作,以保证更好的用户体验
- 在新增熔断防护规则对话框中配置以下示例规则信息
| 参数 | 示例值 | 描述 |
|---|---|---|
| 接口名称 | test | 接口名称 |
| 统计窗口时长 | 1 | 统计时长为1秒 |
| 最小请求数目 | 10 | 触发熔断的最小请求数目为10 |
| 阈值类型 | 异常比例 | 选择以异常比例作为阈值 |
| 熔断比例阈值 | 80% | 触发熔断的慢调用比例阈值为80% |
| 熔断时长(s) | 10 | 熔断时长有10秒 |
| 熔断恢复策略 | 单次探测恢复 | 经过熔断时长后,熔断器会对接下来的一个请求进行探测,若该请求符合预期(不为慢调用或没有异常),则结束熔断;否则重新回到熔断阶段 |
- 规则开启后,在统计时长1秒内,当请求数目大于10,并且异常的比例大于80%的时候,则在接下来10秒的熔断时长内,请求都会快速失败
- 经过10秒后熔断器会进入探测恢复状态,若接下来的一个请求没有异常则结束熔断,否则会再次熔断
配置热点参数防护规则
HTTP 请求
概述
热点参数防护规则(HTTP 请求)为原Web防护规则
- MSE的热点参数防护规则(HTTP 请求)面向提供Web服务的应用,针对访问请求中的一些参数项进行精细化的流量控制
- 对于使用了主流Web框架(Servlet容器、Spring Web、Spring Boot)的应用,MSE实现了API粒度的请求参数解析,通过配置热点参数防护规则(HTTP 请求),可以对请求中IP、Host、Header、URL Param等参数维度的资源调用进行流量控制,保护业务与系统的稳定性
- 本文介绍如何为应用配置热点参数防护规则(HTTP 请求)
背景信息
- 在提供Web服务的场景下,除了API维度的限流降级防护,针对访问请求来源IP、访问请求Param参数等资源调用的限流防护是各种业务场景下能更好保证业务应用正常运行的手段
- 例如,在一些大流量的Web业务场景下,不仅需要对当前接口进行限制,而且需要针对当前访问频次最高的来源IP或访问频次最高的商品ID,有针对性地对其访问进行限制,本示例如下:
- 对一段时间内最频繁购买的商品ID进行限制,以防击穿缓存而导致大量请求到数据库的情况
- 对一段时间内频繁大量访问的来源IP进行限制,防止利用虚假信息恶意刷单
功能入口
- 登录MSE治理中心控制台,并在顶部菜单栏选择地域
- 在左侧导航栏,选择治理中心 > 应用治理
- 在应用列表页面,单击目标应用的资源卡片
- 进入应用之后,在左侧导航栏,单击接口详情。单击热点参数防护(HTTP 请求)页签,然后单击新增热点参数防护(HTTP 请求)
- 在新增热点参数防护(HTTP 请求)对话框,配置规则信息,完成配置后单击新增
- 在规则列表选择对应的规则,并在状态栏下单击开启
- 在温馨提示对话框,单击确认,开启已配置的防护规则
示例场景1:热点商品秒杀
- 在秒杀等抢购商品的场景下,由于流量较大,可能会导致系统响应不及时甚至崩溃
- 为保证系统稳定,可配置热点参数防护规则,超过一定阈值后,系统会拒绝多余的热点商品流量
- 例如购买同一商品,希望1秒内同个商品超过100次请求后,对多余的请求进行拒绝,可在新增热点参数防护(HTTP 请求)对话框中配置以下规则信息,表示1秒内,针对热点商品ID进行下单的请求,每个单独商品ID每秒最多只能允许100个请求,其余超出的当前商品下单请求都会被拒绝,返回自定义的信息
- 参数属性选择URL参数
- 在参数属性中,选择当前热点商品ID所对应的参数字段,例如,假设URL参数中存在一个stockId字段对应请求的商品ID,那么参数属性可以选择URL参数,并在参数名称中填写属性在请求中对应的字段名称
- URL参数名称输入stockId
- 阈值输入100个请求/每秒
- 流控方式选择快速失败
- 参数属性选择URL参数
示例场景2:防止恶意刷单
- 例如在促销活动中,某些恶意刷单请求较多的时候,会占用较多商品库存或服务器资源
- 这种情况下可以针对其IP来源进行排队等待的处理,使访问请求匀速通过,防止过量的请求对服务稳定性产生影响
- 在新增热点参数防护(HTTP 请求)对话框中配置以下规则信息,表示每个不同来源IP调用此接口的请求会以每10 ms一个的速度匀速通过(1s/100=10 ms),后续多余的请求要进行排队等待
- 排队中的请求如果等待时长超过30 ms就会立即失败
- 参数属性选择Client IP
- 阈值类型默认选择请求数
- 阈值输入100个请求/每秒
- 流控方式选择排队等待
- 超时时间输入30
- 是否开启选择开启
配置项说明
参数属性
针对所选API的参数属性进行流量控制
| 参数属性 | 描述 |
|---|---|
| Client IP | 请求端的IP地址 若请求经过代理,会优先尝试从X-Forwarded-For请求头中获取IP信息,如果其IP信息存在,将会使用该IP作为实际请求端IP地址 |
| Remote Host | 请求端的Host Header |
| Header | 根据指定的HTTP Header进行解析,如果填写某个具体的Header Key,则该规则针对这个Header Key下面的热点值分别进行限制 选择Header后,可选择配置请求属性值的匹配策略,只有匹配该模式的请求属性值会纳入统计和流控 |
| URL参数 | 根据指定的HTTP请求参数进行解析,需要填写对应的参数名称 选择URL参数后,可选择配置请求属性值的匹配策略,只有匹配该模式的请求属性值会纳入统计和流 |
匹配模式和匹配串 - 可选
若选择参数属性为Header或URL参数,可打开属性值匹配开关,并设置匹配模式和匹配串,匹配模式如下:
- 精确:严格按照给定的匹配串来匹配值
- 字串:若请求属性值包含该子串匹配成功,比如若子串设置匹配ab,则aba和cabc都可以匹配,而cba则不能匹配
- 正则:按给定的正则表达式匹配串进行匹配
阈值类型
默认为请求数
阈值
- 触发对流控接口的统计维度对象的QPS阈值
- 设置时,需选择统计时间间隔,支持秒、分钟、小时和天四种维度
- 例如,若阈值填写为10,统计间隔选择分,则表示每分钟对应的请求数目不超过10个
高级选项
流控方式
- 快速失败:当阈值类型为QPS时,被拦截的流量将快速失败,即达到阈值时,立即拦截请求
- 被拦截拒绝掉的请求,将返回行为管理中配置的自定义信息,若未配置会返回默认行为,即429错误码加上默认文本信息
- 排队等待:当阈值类型为QPS时,被拦截的请求将匀速通过,允许排队等待
- 需设置具体的超时时间,预计达到超时时间的请求会立即失败,而不会排队
- 例如,QPS配置为10,则代表请求每100 ms才能通过一个,多出的请求将排队等待通过
- 超时时间代表最大排队时间,超出最大排队时间的请求将会直接被拒绝
- 排队等待时,QPS不要超过1000(请求间隔1 ms)
Burst size
当流控方式选择为快速失败时,可以额外设置一个Burst Size,即针对突发请求额外允许的请求数目
超时时间
- 当流控方式选择为排队等待时,需设置具体的超时时间,单位为ms
- 例如,QPS配置为5,则代表请求每200 ms才能通过一个,多出的请求将排队等待通过
- 超时时间代表最大排队时间,超出最大排队时间的请求将会直接被拒绝
是否开启
- 开启:热点参数防护规则(HTTP 请求)创建后即生效
- 关闭:热点参数防护规则(HTTP 请求)创建后不生效
关联行为
- 默认行为:默认为此选项
- 如您无需自定义限流后处理行为,选择默认行为即可
- 默认行为为返回429错误码加上默认的文本信息
- 新增行为:新增自定义限流后处理行为,创建完成后您可在关联行为选择框中下拉选择
配置系统防护
概述
- 系统防护提供了在不同场景下的节点维度的流量防护能力,以应对各种预期外的情况
- 例如,当未配置流量防护规则的接口遭遇流量突增时,系统防护能够提供兜底的流量防护,确保应用的稳定性
- 目前,微服务治理针对服务端流量以及客户端流量分别提供了自适应过载保护、总QPS限流、总并发限流、异常调用熔断以及慢调用熔断能力
功能入口
- 登录MSE治理中心控制台,并在顶部菜单栏选择地域
- 在左侧导航栏,选择治理中心 > 应用治理
- 在应用列表页面,单击目标应用的资源卡片,然后在左侧导航栏单击流量治理
- 单击系统防护页签,配置相应的功能
自适应过载保护
自适应过载保护需要Agent版本为3.1.4及以上
简介
- 自适应过载保护将CPU使用率作为衡量系统负载的依据,自适应地调整对服务端流量的限流比例
- 在预期外的流量突增场景下也能将CPU使用率相对平稳地控制在配置的阈值范围内
生效范围
自适应过载保护对所有服务端接口生效,优先级低于流量防护规则
适用场景
- 自适应过载保护为服务端接口提供基于CPU的兜底防护,适用于CPU相关型应用,预期外的接口出现突增 -> 系统CPU持续上升 -> 影响核心接口RT
- 根据不同应用的业务,稳态下的CPU使用率也不同,用户可以通过压测/历史数据确定稳态下的最大CPU使用率并进行适当放大做为阈值进行配置
页面说明
- 页面左侧为自适应过载保护事件列表,右侧展示近5分钟该应用的节点平均CPU使用率变化趋势
- 事件为节点维度,基于算法的状态变更,包含限流开始事件、限流持续事件以及限流结束事件
- 页面顶部包含功能开关及模拟执行设置项。右侧CPU使用率折线图中以蓝色虚线标示保护线(即防护水位阈值)
- 单击事件操作的查看链接,可以查询对应IP节点的CPU使用率数据,并将时间回放至事件上报时间,以观察事件触发时对应节点的CPU使用率以及限流概率等信息
开启状态
- 关闭:自适应过载保护处于关闭状态
- 模拟执行:该状态下,当自适应过载保护触发时,将仅产生相应事件,不实际调整流量防护策略
- 开启:该状态下,当自适应过载保护触发时,实际调整流量防护策略,以一定的比例对所有入口流量进行限流
CPU使用率
- 定义预期的CPU使用率阈值,自适应过载保护会基于系统实际的CPU使用率以及配置的CPU使用率阈值结合算法自适应地调整接口限流的概率
- 帮助系统在高压场景下通过拒绝一部分请求的方式,维持CPU使用率在配置的阈值上下小范围波动
总QPS限流
简介
总QPS限流需要Agent版本为4.2.0及以上
总QPS限流将以节点维度统计总QPS(单节点所有服务端接口QPS之和),对于超过阈值的请求进行限流操作
生效范围
总QPS限流对所有服务端接口生效,优先级低于流量防护规则
适用场景
- 由于不是所有系统的表现都与CPU强相关,有些应用在低CPU负载下也会因为内存、网络等原因导致性能劣化
- 而总QPS限流基于节点的总QPS来进行限流,提供了基于流量的防护手段
- 预期外的接口出现突增 -> 竞争资源紧缺 -> 影响核心接口
- 用户可以通过压测/历史数据确定稳态下的节点总QPS并进行适当放大作为阈值进行配置
页面说明
- 页面左侧为总QPS限流事件,右侧展示近5分钟该应用的节点平均总QPS请求数据变化趋势
- 事件为节点和接口维度,基于实际发生总QPS限流的节点以及接口上报事件,每5分钟上报一次,上报过去5分钟内发生的限流
- 右侧折线图展示总QPS、通过QPS和拒绝QPS三条曲线及阈值参考线,便于观察限流效果
- 单击事件的查看链接,可以查询对应IP节点的总QPS,并将时间回放至事件上报时间附近
- 以观察事件触发时对应节点的总QPS以及限流是否符合预期
- 如果需要查看更加详细的信息,比如接口和节点维度,可以前往接口详情或者节点详情,后续会提供对应的跳转能力
- 右侧请求数据面板展示总QPS、通过QPS和拒绝QPS三条趋势曲线
开启状态
- 关闭:总QPS限流处于关闭状态
- 开启:该状态下,对于超过阈值请求会进行限流操作
总 QPS 阈值
节点维度总 QPS 阈值
总并发限流
简介
总并发限流需要Agent版本为4.2.0及以上
总并发限流将以节点维度统计总并发(单节点所有服务端接口并发之和),对于超过阈值的请求进行限流操作
生效范围
总并发限流对所有服务端接口生效,优先级低于流量防护规则
适用场景
- 在调用RT较高的场景下(普遍超过1s),QPS限流会出现一个比较明显的问题,当系统的竞争资源(线程池、内存、连接池等)被占用时,会导致排队进一步导致接口的RT上升
- 如果此时只采用基于QPS的限流,每秒还是会有少量请求进入,而队列中的请求无法在秒级别消化完成,会导致队列进一步累积,RT进一步上升,无论新旧请求RT都有显著上升
- 此时如果使用了并发限流,如果还有一定量的请求没有完成,新的请求会被直接拒绝,这样虽然请求会被限流,但是系统处理完当前请求后,新的请求就会通过,以较小的排队时间完成请求
- 从整体上看,请求的成功率和平均RT都会有显著的改善
- 预期外的接口出现突增 -> 竞争资源紧缺 -> 队列堆积 -> 所有请求RT上升
- 用户可以通过压测/历史数据确定稳态下的节点总并发并进行适当放大作为阈值进行配置
选型对比:总 QPS 限流 vs 总并发限流
两种限流维度适用场景不同,选型逻辑如下图:
flowchart TD
Burst["预期外接口突增<br/>竞争资源紧缺(线程池 / 连接池 / 内存)"]
Judge{"接口 RT 形态<br/>(压测 / 历史数据确定)"}
Burst --> Judge
Judge -->|"RT 低:亚秒级完成"| LimitQPS["总 QPS 限流<br/>限『速率』"]
Judge -->|"RT 高:普遍超过 1s<br/>或对队列堆积敏感"| LimitCC["总并发限流<br/>限『在途量』"]
subgraph SG_QPS ["总 QPS 限流:每秒进入多少"]
direction TB
Q1["秒级放行 N 个新请求"] --> Q2["当秒内完成、腾出资源"]
Q2 --> Q3["队列不累积<br/>吞吐可控 ✅"]
end
subgraph SG_CC ["总并发限流:同时进行多少"]
direction TB
C1["并发达到阈值"] --> C2["新请求直接拒绝<br/>不进队列"]
C2 --> C3["在途请求正常完成"]
C3 --> C4["腾出额度,放行新请求"]
C4 --> C3
end
LimitQPS --> SG_QPS
LimitCC --> SG_CC
Bad["高 RT 下仍用 QPS 限流的失效链:<br/>每秒仍有请求进入 → 队列秒级消化不完 →<br/>持续累积 → 新旧请求 RT 全体上升 ❌"]
LimitQPS -. "RT 变高后失效" .-> Bad
一句话总结:总 QPS 限流限的是”速率”(每秒进入多少),总并发限流限的是”在途量”(同时进行多少)。两者背后是 Little’s Law:并发 ≈ QPS × RT——RT 低时二者近似等价(限制速率就隐式限制了并发);RT 高且队列敏感时,同样的 QPS 阈值意味着巨大的在途并发,只有并发限流能阻断”排队累积 → RT 全体上升”的恶性循环。
页面说明
- 页面左侧为总并发限流事件,右侧展示近5分钟该应用的节点平均总并发请求数据变化趋势
- 事件为节点+接口维度,基于实际发生总并发限流的节点以及接口上报事件,每5分钟上报一次,上报过去5分钟内发生的限流
- 单击事件的查看链接,可以查询对应IP节点的总并发,并将时间回放至事件上报时间附近
- 以观察事件触发时对应节点的总并发以及限流是否符合预期,如果需要查看更加详细的信息,比如接口和节点维度,可以前往接口详情或者节点详情,后续会提供对应的跳转能力
开启状态
- 关闭:总并发限流处于关闭状态
- 开启:该状态下,对于超过阈值请求会进行限流操作
总并发阈值
节点维度总并发阈值
异常调用熔断
简介
异常调用熔断需要Agent版本为4.2.0及以上
- 异常调用熔断会分别统计每个客户端接口的异常比例,当异常比例大于配置的阈值时对该接口进行熔断
- 熔断期间该接口直接快速失败,并相隔一定时间通过用于探测的请求,探测成功后结束熔断
生效范围
异常调用熔断对所有客户端接口生效,但对于配置了接口维度熔断规则的接口不生效
适用场景
- 异常调用熔断主要分为两类场景
- 超时场景:一个客户端接口的超时异常比例过高,往往是服务提供方出现异常情况,但这会进一步导致调用方(本应用)请求堆积,影响本应用的其他接口,通过熔断的方式可以在提供方异常期间快速失败,避免堆积
- 非超时场景:一个客户端接口的非超时异常比例过高,异常调用熔断能够通过抛出限流异常供用户处理,起到降级的效果,优化异常场景下的用户体验
慢调用熔断
简介
慢调用熔断需要Agent版本为4.2.0及以上
- 慢调用熔断会分别统计每个客户端接口的慢调用比例,当慢调用比例大于配置的阈值时对该接口进行熔断
- 熔断期间该接口直接快速失败,并相隔一定时间通过用于探测的请求,探测成功后结束熔断
生效范围
慢调用熔断对所有客户端接口生效,但对于配置了接口维度熔断规则的接口不生效
适用场景
慢调用熔断的使用场景基本和异常调用熔断中的超时异常相同,区别在于可以动态调整判断慢调用的RT标准,不依赖超时配置
例外项
简介
例外项需要Agent版本为4.2.0及以上
所有系统防护功能均可以配置例外项,对例外项中的接口系统防护会直接通过,而不进行规则的检查
适用场景
- 通常情况下,只有健康检查接口以及系统关键接口需要配置例外项
- 前者避免影响节点的健康状态,后者有单独的接口维度的限流限制,且希望不受系统维度限流的影响
系统防护 vs 流量防护
- 系统防护和流量防护都能够保障应用处于稳态,但是两者覆盖的场景和流量损耗不同
- 触发限流后,系统防护限流返回状态码为429,目前不支持用户自定义配置
- 系统防护以节点维度的指标为依据提供流量防护,能够保障应用本身处于稳态,覆盖大部分场景
- 但是由于系统防护从应用视角出发,对所有接口一视同仁,但在同一个应用中,不同接口的重要性不同,对系统负载的影响也不同
- 流量防护可以通过对不同接口配置不同的阈值,从而覆盖更多的场景,并且在同样起到防护作用的同时尽可能较少限流的流量
- 整体来说系统防护和流量防护都能够起到防护效果,但是在防护场景覆盖率和流量损耗上流量防护效果更好,在配置难度上系统防护更低
- 因此,最佳实践是系统防护+流量防护,系统防护保障应用的稳定性,流量防护通过精细化的配置在防护效果不打折扣的同时减少损耗(限流的流量)
两层防护的分层协作与维度对比如下图:
flowchart TD
T["请求流量"] --> FP{"第一层:流量防护(接口级 · 精细)<br/>命中规则且超过该接口阈值?"}
FP -->|"是"| R1["拒绝 429<br/>流控行为可自定义<br/>拦截『已知热点』,损耗小"]
FP -->|"否(含未配置规则的接口)"| SP{"第二层:系统防护(节点级 · 兜底)<br/>CPU / 总QPS / 总并发 越线?"}
SP -->|"是,按比例"| R2["拒绝 429<br/>行为不可自定义<br/>拦截『未知突增』,一视同仁"]
SP -->|"否"| OK["✅ 放行 · 应用保持稳态"]
subgraph CMP ["维度对比"]
direction LR
SYS["系统防护<br/>节点维度 · 应用视角<br/>所有接口一视同仁<br/>配置难度:低 ✅<br/>场景覆盖:较窄 · 流量损耗:大 ⚠️"]
TRAFFIC["流量防护<br/>接口维度 · 差异化阈值<br/>按接口重要性分层<br/>配置难度:高 ⚠️<br/>场景覆盖:全 · 流量损耗:小 ✅"]
end
一句话理解分工:流量防护在前面”精确制导”——认识每个接口、按重要性给不同阈值,把已知热点的超额流量最小化地拦下来;系统防护在后面”面防御”兜底——它不认识接口,只看节点整体的 CPU/QPS/并发,专拦第一层没覆盖到的未知突增。前者省流量,后者保下限。
配置隔离规则
概述
- 隔离规则通过控制接口或依赖的并发线程数,来保证系统的稳定性
- 通常适用于应用内部或下游依赖出现不稳定的场景,例如慢SQL、下游应用响应时间变长等
- 本文介绍如何配置和管理隔离规则
背景信息
隔离规则配置通常用于强依赖隔离场景
- 当强依赖的方法或接口不稳定的时候,可以通过配置并发线程数来限制不稳定的强依赖并发数,起到隔离异常的效果
- 若运行该请求的响应时间变长,会导致线程的并发数增大
- 当并发数超过阈值以后,MSE将拒绝多余的请求,直到堆积的任务完成,并发线程数减少,从而达到隔离异常、减小不稳定性的效果
如何设定并发线程数阈值,可参见以下内容
并发线程数 = 期望QPS*响应时间+冗余量
例如预期的SQL执行时间为20毫秒,预期该请求每秒有20个,并发最大时为6个,建议并发线程数按照以下逻辑设置:Max(20/1000*20,6)= 6 ,再加上冗余量2 ,则建议并发数阈值设置为8
设置好后,当这个SQL发生死锁或者有性能问题,SQL运行特别慢成为慢SQL时,即使请求不断地进来,也仅仅会占用8个线程,不会因为持续进来的请求(请求也无法在短时间内退出)而耗光进程的活跃线程
当这个SQL恢复正常后,并发数会迅速减少
当并发数减少至低于预设的阈值时,系统就不会拒绝请求,应用的处理能力也快速的恢复
通过这样的方式,起到了根据响应时间自动调节的效果,隔离了不稳定的应用
功能入口
- 登录MSE治理中心控制台,并在顶部菜单栏选择地域
- 在左侧导航栏,选择治理中心 > 应用治理
- 在应用列表页面,单击目标应用的资源卡片
- 进入应用之后,选择以下任意一种方法新建隔离规则:
- 在左侧导航栏,单击应用概览,然后单击通过QPS TOP页签,单击对应接口的操作列下的隔离
- 在左侧导航栏,单击接口详情。单击并发隔离页签,然后单击新增隔离规则
- 在左侧导航栏,单击流量治理。单击流量防护页签,再单击并发隔离页签,然后单击新增隔离规则
- 在新增隔离防护规则或新增规则对话框中配置规则信息,然后单击新增
常用示例:保障自身资源充足
- 当运行该请求的响应时间变长,会导致线程的并发数变大
- 当并发数超过阈值以后,MSE将拒绝多余的请求,直到堆积的任务完成,并发线程数变少
- 达到将异常隔离,减小不稳定性的效果
- 例如某个SQL执行时间为20毫秒,预期该请求每秒有20个
- 在新增隔离防护规则或新增规则对话框中配置以下规则信息:
- 填写接口名称
- 并发数阈值为10
- 设置完成后,当这个SQL发生死锁或者存在性能问题时,该SQL运行变慢,成为慢SQL,此时即使请求不断进来,也仅仅会占用10个线程
- 不会因为持续进来的请求(请求也无法在短时间内退出),从而耗光进程的活跃线程
- 当这个SQL恢复正常后,并发数会迅速减少
- 当并发数减少至低于预设的阈值时,系统就不会拒绝请求,应用的处理能力也快速的恢复
- 通过这样的方式,起到了根据响应时间自动调节的效果,隔离了不稳定的应用
更多信息
| 配置项 | 描述 |
|---|---|
| 接口名称 | 待隔离的资源名称 |
| 并发数阈值 | 资源的并发线程数(即该资源正在执行的线程数)阈值 |
流量治理
无损上下线
在应用启动各阶段,无损上线能提供相应的保护能力,通过无损下线配置来保证应用正常关闭
配置系统防护
系统防护提供了在不同场景下的节点维度的流量防护能力,以应对各种预期外的情况
流量防护
流量防护以流量为切入点,从流量控制、熔断降级、系统负载保护等多个维度来保障业务的稳定性,提供更专业稳定的流量防护手段、秒级的流量水位分布分析功能
配置标签路由
标签路由通过给流量打标、给机器打标、增加路由能力,从而约束符合特征流量只调用到对应标签的节点上,实现按流量特征与机器标签路由的目的
配置同可用区优先
- 同可用区(Availability Zones)优先路由,是指在应用调用服务时,优先调用同机房的服务Provider
- 同可用区优先是一种负载均衡策略,能够使流量在同一个可用区内流转,不仅限于使用默认提供的轮询方式进行负载均衡
配置消息灰度
使用金丝雀发布、全链路灰度以及开发环境隔离等场景中需要使用到消息的灰度,那么您需要开启消息灰度的功能
服务实例隔离与诊断
服务实例隔离与诊断可以有效地应对线上故障(例如内存泄露),提升微服务系统整体稳定性











