限流用令牌桶控制请求洪峰，熔断用三态模型隔离故障依赖，二者需与降级、监控、热配置结合构建弹性链路。
限流：控制请求洪峰，保护服务稳定性
云原生场景下，突发流量容易压垮后端服务。Golang 中常用 token bucket（令牌桶） 和 leaky bucket（漏桶） 实现限流，其中 golang.org/x/time/rate 提供了轻量、线程安全的令牌桶实现。
- 用
rate.NewLimiter(rate.Limit(100), 1)创建每秒最多 100 次请求、初始令牌为 1 的限流器 - 在 HTTP handler 中调用
limiter.Allow()或limiter.Wait(ctx)判断是否放行；拒绝时返回429 Too Many Requests - 对不同接口或租户做差异化限流，可结合路由参数或 JWT 声明动态选择限流器（如用
sync.Map缓存 key → limiter 映射）
熔断：自动隔离故障依赖，避免雪崩
当下游服务持续超时或失败，熔断器会快速失败本地调用，跳过真实请求，给下游“喘息”时间。推荐使用 sony/gobreaker 库，它实现了经典的三态熔断模型（Closed → Open → Half-Open）。
- 初始化时设置失败阈值（如连续 5 次错误）、超时窗口（60 秒）、半开探测间隔（30 秒）
- 包裹外部调用：
cb.Execute(func() (interface{}, error) { return callDownstream() }) - 熔断打开后，所有请求立即返回预设错误（如
errors.New("service unavailable")），不发起网络请求 - 注意：熔断状态需持久化或共享（如通过 Redis）才能在多实例间协同，否则单机熔断效果有限
组合策略：限流 + 熔断 + 降级，构建弹性链路
单一机制不足以应对复杂故障。建议按调用链分层设计容错：
- 入口层（API Gateway）做全局 QPS 限流，防恶意刷量
-
服务层对每个下游依赖（DB、Redis、第三方 API）单独配置熔断器，并配以超时和重试（如
backoff.Retry） - 业务层在熔断触发时提供兜底逻辑（如返回缓存数据、静态默认值、简化响应体）
- 所有容错行为记录结构化日志（含指标标签：service、upstream、status、latency），接入 Prometheus + Grafana 监控熔断率、限流拒绝数等关键信号
实践提醒：别忽略可观测性与配置热更新
限流阈值和熔断参数不是写死的常量，需支持运行时调整。
立即学习“go语言免费学习笔记（深入）”；
- 用
viper或go-config加载配置，监听文件/Consul/etcd 变更，动态重建限流器或更新熔断器参数 - 暴露 /health/ready 接口时，加入限流器状态（如当前剩余令牌）、熔断器状态（Closed/Open/HalfOpen）作为就绪条件
- 在日志中打标 “ratelimit_rejected=1” 或 “circuit_open=1”，便于在 Loki 或 ELK 中聚合分析异常模式
基本上就这些。不复杂但容易忽略的是：限流和熔断不是加了就完事，必须配合监控告警和定期压测验证效果。
