熔断与降级是Golang微服务保障韧性的基本能力：通过sony/gobreaker实现按依赖隔离的熔断，结合有业务语义的降级策略、context超时控制及Prometheus可观测性闭环。
在 Golang 微服务中，熔断与降级不是“可选项”，而是保障系统韧性的基本能力。核心思路是：当依赖服务持续失败时，主动切断调用（熔断），避免雪崩；同时提供有损但可用的备用逻辑（降级），保证主流程不卡死。
用 circuitbreaker 实现熔断
推荐使用 sony/gobreaker 库，轻量、稳定、符合 Hystrix 思想。它通过滑动窗口统计失败率，自动在 Closed / Half-Open / Open 三种状态间切换。
基本用法：
- 定义 breaker：用
gobreaker.NewCircuitBreaker配置失败阈值、超时时间、半开探测间隔等 - 包裹外部调用：所有对下游服务的 HTTP 或 RPC 调用，都用
cb.Execute包一层 - 处理 Open 状态：Execute 返回
gobreaker.ErrOpenState时，说明已熔断，应跳过原逻辑，走降级分支
注意：熔断器需按依赖维度隔离（如每个下游服务一个 breaker），不能全局共用一个实例。
结合 fallback 实现降级
降级不是“随便返回个默认值”，而是要有业务语义的兜底策略。常见方式包括：
- 静态响应：如返回缓存的旧数据、预设的提示文案（“服务暂不可用，请稍后再试”）
- 本地计算替代：比如推荐服务不可用时，退化为按热度排序
- 异步兜底：记录失败请求到队列，后台重试或人工干预
关键点：降级逻辑必须无外部依赖、执行快、不抛 panic。建议把降级函数作为参数传入，和主逻辑解耦。
用 context 控制超时与取消
熔断前的“第一道防线”是超时控制。Golang 的 context 是天然选择：
- 每次发起 HTTP 请求或 gRPC 调用前，用
context.WithTimeout包装上下文 - 超时后自动 cancel，避免 goroutine 泄漏和长尾延迟拖垮上游
- 可将 timeout 和熔断阈值联动设计（例如：超时 800ms 触发一次失败计数，连续 5 次超时则熔断）
别忘了在 handler 入口统一设置 request-level context，并透传到底层调用链。
可观测性：让熔断“看得见”
没有监控的熔断等于盲操作。至少要暴露以下指标：
- 各 breaker 的当前状态（Open/Closed/Half-Open）
- 请求成功率、失败率、被拒绝数（即熔断拦截数）
- 降级触发次数及对应原因（超时/熔断/异常）
推荐用 prometheus + gob
reaker.Metrics 自动采集，再接入 Grafana 做看板。一旦 Open 率突增，立刻排查下游或网络问题。
基本上就这些。Golang 做微服务容错不复杂，但容易忽略状态隔离、降级语义和指标闭环。把熔断器当成“带开关的代理”，把降级当成“有契约的备选方案”，再配上 context 和 metrics，就能扛住大部分依赖抖动。
