go服务需主动配置自适应保护机制以防雪崩，sentinel go通过监控cpu、load、avgrt、concurrent、qps五类指标，结合bbr算法动态限流，并支持内存自适应与熔断降级。
Go语言服务在负载过高时不会自动“刹车”，必须主动配置保护机制，否则容易因CPU打满、连接耗尽、goroutine堆积而雪崩。核心思路是：监控关键指标 → 触发阈值 → 限流/熔断/降级 → 快速失败。
系统指标监控与自适应限流
单纯靠固定QPS限流不够灵活，Sentinel Go的系统自适应保护能根据实时资源状态动态调整。它默认采集五类指标：
- CPUUsage：全平台可用，推荐设为80%作为基础阈值
- Load：仅Linux生效（看load1），适合物理机或容器部署
- AvgRT：平均响应时间持续升高，说明下游或自身处理变慢
- Concurrent：并发请求数突增，可能压垮数据库连接池
- QPS：入站流量陡增，需结合其他指标判断是否真实过载
注意：这些规则必须显式调用 system.LoadRules() 才生效，初始化sentinel后不调用等于没配。规则中Strategy字段只能选一种策略，多个规则并存时取最严的一个触发。
BBR算法驱动的智能过载控制
受TCP BBR启发，Sentinel Go的BBR限流不依赖人工预设QPS，而是建模系统“服务能力”：
- 每100ms采样一次 Pass（成功请求数） 和 RT（响应时间）
- 计算当前 Inflight（正在处理的请求数）
- 当 Pass × RT 且CPU滑动均值超阈值（如800），即判定过载
- 进入保护后有冷却期，防止负载短暂回落就放行大量请求导致震荡
这种机制让系统在硬件升级或扩容后无需改配置，就能自动提升承载能力。
内存与连接层的双重防护
过载常始于内存和网络连接失控：
- 内存自适应：通过 core/flow/tc_adaptive.go 动态调整限流阈值——内存使用高则收紧，低则放宽
- HTTP服务器层：必须设 ReadTimeout（建议5s）、IdleTimeout（防keep-alive僵尸连接）、WriteTimeout（防模板渲染卡死）
- Worker Pool模式：用带缓冲的 chan func() 控制最大并发，Submit会自然阻塞，比计数器更轻量可靠
别只盯着业务逻辑限流，底层连接管理漏掉一个超时，就可能让FD耗尽、服务假死。
熔断与快速失败兜底
当依赖服务（如DB、第三方API）持续异常时，光限流不够，需熔断隔离：
- 用 gobreaker 库实现标准三态熔断：Closed→Open→Half-Open
- 错误率阈值（如50%）、Open持续时间（如60秒）、Half-Open试探请求数（如3个）需按业务容忍度设置
- Open状态下直接返回预设降级结果（如缓存数据、空列表、默认文案），不发起远程调用
熔断不是“放弃”，而是把有限资源留给健康链路，等故障服务恢复后再渐进放量。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
