静态阈值的宿命
回看限流篇配的每一个阈值：QPS 5000、并发 200、线程 20——全是人拍的。拍小了，业务正常增长就误杀；拍大了，形同虚设；每次扩容、每次下游改造，都得重新拍一遍。容量的本质是 f(机器数、依赖 RT、数据量、缓存命中率)，每个因子都在变，静态数字注定追不上。自适应保护的思路换了方向：不再猜测容量，直接测量容量。
BBR：用测量代替猜测
灵感来自 TCP 的 BBR 拥塞控制：不预测网络能扛多少，而是持续测量——测出瓶颈带宽与往返时延，在途数据量超过「带宽 × 时延」就收手。Google 把它搬进了 gRPC 的自适应限流，Sentinel 的系统自适应规则同源：用最近观测到的容量，约束当前的负载。
两个关键测量值：maxQps——最近窗口观测到的最大 QPS；minRt——最近窗口里最小的平均 RT（RT 最小时系统最轻松，那是最真实的单请求容量）。两者相乘，就是系统能稳住的最大并发。
系统自适应限流
// Sentinel 系统自适应规则的 BBR 思路
long maxQps = 观测窗口内最大 QPS; // 测出来的
long minRt = 观测窗口内最小平均 RT; // 测出来的
long capacity = maxQps * minRt / 1000; // 稳住所需的最大并发
if (当前并发处理中的请求数 > capacity) {
reject(); // 排队的先处理完，新请求少进
}与固定阈值的区别在于：容量数字是「刚测的」——机器扩容后 maxQps 自动变大，下游变慢后 minRt 自动变小（能稳住的并发变少），阈值跟着现实走，不再需要人追着改。
自适应的三层
自适应思想在稳定性体系里到处都是：系统级——Sentinel 系统规则按 load、CPU、并发自动限流；熔断级——半开探测成功率高就延长观察、失败率高就缩短休眠，参数自己调自己；资源级——K8s HPA 按 CPU 或自定义指标自动扩缩容，容量不够就加机器，是最粗也最有效的自适应。弹性扩容解决「不够用」，自适应限流解决「来了也接不住」，两者互补。
自适应不是银弹
三个局限要心里有数：冷启动误判——服务刚起流量小，测出的 maxQps 偏低，需要预热期（还记得限流篇的 WarmUp 吗）；突发滞后——测量天然滞后于现实，瞬时洪峰先打到系统，自适应阈值才反应过来，所以限流、熔断的静态防线仍然要留；黑天鹅不管——自适应消化正常波动，缓存雪崩、主从切换这种天塌下来，还是要预案与降级。
分工一句话：静态阈值挡已知洪峰，自适应机制消化正常波动，预案兜底未知灾难。
单点的保护机制装齐了，理论闭环了——但没人真正知道它们扛不扛得住真实洪水。容量上限是多少？哪层先垮？预案真的生效吗？压力得真打进来才知道。下篇聊全链路压测：洪水来之前，先演一遍。
评论 (0)