Sentinel系统自适应限流是基于CPU、RT、QPS等多维指标动态调控入口流量的全局保护机制，其核心是SystemRule与BBR模式，通过实时采集系统负载并平滑调整阈值，实现“最大吞吐量”与“稳定性”的动态平衡，而非依赖静态阈值或单一Load指标。
自适应限流不是 Gin 原生能力，得靠 Sentinel
Gin 本身不提供自适应限流（如根据系统负载动态调整阈值），它只负责路由和中间件编排。真正实现自适应限流的是 Sentinel —— Alibaba 开源的流量治理组件，它能基于 QPS、CPU 使用率、平均 RT 等指标实时计算并调整限流阈值。
如果你在 Gin 项目里看到“自适应限流”，背后一定是集成了 Sentinel，而不是靠 Gin 自己或手写中间件实现的。
-
Sentinel的SystemRule（系统规则）才是自适应的核心：它监控全局指标（比如整个进程的 CPU > 80%），一旦触发就自动降低所有受保护资源的单机阈值，甚至直接拒绝新请求 - 单纯用
gin+time.Ticker或sync.Mutex实现的令牌桶/漏桶，都是静态限流——rate 和 capacity 写死，无法响应负载变化 - 网上有些文章把“根据当前请求数动态调 rate”叫自适应，那是误用术语；真正的自适应必须依赖外部可观测指标，而非仅请求计数
为什么 BBR 模式常被误认为是 Gin 自带功能
很多人在文档里看到 sentinel.BBR（Busy-Backoff Rate）策略，就以为这是 Gin 的能力。其实 BBR 是 Sentinel 提供的一种系统级限流模式，它会：
- 持续采集当前系统的
load（Linux 下的 /proc/loadavg）、CPU usage、RT、QPS - 用一个平滑衰减函数（类似指数移动平均）计算“当前可承载容量”
- 当检测到系统开始变慢（RT 上升）或过载（CPU > 90%），自动把限流阈值从 1000 QPS 降到 600，再降到 300……直到恢复
这个过程完全由 Sentinel 的 SystemSlot 在 filter 链中完成，Gin 只是被动接收 sentinel.Entry 的 BlockError 并返回 429。
接入 Sentinel BBR 的三个硬性前提
想让自适应限流真正起作用，光引入包不够，以下三点缺一不可：
- 必须启用
Sentinel的指标收集器：sentinel.InitWithConfig(&sentinel.Config{MetricsLogOutput: os.Stdout})，否则没有数据源 - 必须注册系统规则：
sentinel.LoadRules([]*sentinel.SystemRule{{MetricType: sentinel.Load, Threshold: 2.0}})，其中MetricType支持sentinel.Load/sentinel.CPU/sentinel.RT/sentinel.QPS - Gin 路由必须包裹
sentinel.Entry：每个 handler 开头调e, err := sentinel.Entry("api_order_create")，结尾调e.Exit()，否则Sentinel不知道该统计哪条链路
漏掉任意一步，你写的都只是静态限流，和“自适应”毫无关系。
别在单机场景强行套用 BBR
BBR 模式本质是“单机自治”，它假设你部署的是独立进程（比如一个 Pod 一个实例）。但在以下场景下，它会失效或反效果：
- K8s 中多个 Pod 共享同一套后端 DB：一个 Pod 的 CPU 高 ≠ 整体瓶颈，此时降阈值反而导致流量打到其他健康 Pod，引发雪崩
- 使用了连接池（如 pgxpool）且 pool size 固定：CPU 高可能只是连接等待，实际 DB 还有余力，BBR 却误判为过载
- 应用启用了 GC Tuning（如
GOGC=100）：GC STW 阶段 RT 突增，BBR 会误触发限流，但其实只是短暂卡顿
生产环境若要用 BBR，务必搭配 sentinel-dashboard 实时观察 system_rule_effective 指标，并设置 fallback 规则（比如 CPU > 95% 才触发，避免毛刺干扰）。
