如何使用Golang实现服务降级策略_Golang微服务异常处理与降级方法

服务降级需主动设计而非简单加fallback：用context控制超时，区分transient与permanent错误，降级逻辑独立封装、无副作用，并配合熔断与动态开关。

服务降级不是加个 fallback 就完事

Go 本身没有内置的降级机制（比如 Spring 的 @HystrixCommand），必须靠组合 context.Context、time.AfterFunc、错误分类和显式分支来实现。盲目套用“超时就走降级”会掩盖真实问题——比如下游返回了 503 Service Unavailable，但你只判断了超时，结果把业务错误当成了网络抖动处理。

用 `context.WithTimeout` 控制主调用，但降级逻辑必须独立封装

不能把降级代码塞进 defer 或 recover 里——那属于 panic 恢复，不是降级。真正的降级是「主动选择次优路径」，比如查缓存代替查 DB、返回默认值代替实时计算、调用轻量接口代替重逻辑。

主流程用 ctx, cancel := context.WithTimeout(context.Background(), 800*time.Millisecond)，并确保所有下游调用（HTTP、gRPC、DB）都接收并传递该 ctx
降级函数必须是纯函数或无副作用函数：不改状态、不发日志、不触发告警（这些应在主流程失败后统一处理）
避免在降级分支里再起 goroutine 或调用另一个可能失败的服务——这会让降级链失控

func getUser(ctx context.Context, userID string) (*User, error) {
    // 主调用
    user, err := callUserService(ctx, userID)
    if err == nil {
        return user, nil
    }
    if errors.Is(err, context.DeadlineExceeded) || errors.Is(err, context.Canceled) {
        return fallbackUser(userID), nil // 明确的降级入口
    }
    return nil, err
}

区分 transient error 和 permanent error 再决定是否降级

不是所有错误都该触发降级。比如 user not found 是业务正常态，不该走兜底；而 connection refused 或 i/o timeout 才是需要降级的 transient 场景。

HTTP 客户端建议用 http.DefaultClient.Transport 配置 MaxIdleConnsPerHost 和 IdleConnTimeout，避免连接池耗尽导致的假超时
对 gRPC 调用，检查 status.Code(err)：只有 codes.Unavailable、codes.DeadlineExceeded 等才考虑降级；codes.NotFound 或 codes.InvalidArgument 应直接返回
数据库操作中，sql.ErrNoRows 不是错误，是预期结果；而 "dial tcp: i/o timeout" 才要触发降级

降级开关必须可动态控制，且带熔断联动

硬编码的降级开关等于没开关。上线后发现降级逻辑有 bug，或者下游恢复了但你的服务还在返回默认值——这就成了故障放大器。

用原子变量 + HTTP handler 控制开关：var enableFallback atomic.Bool，暴露 /admin/feature/fallback?enable=true
降级不应孤立存在：建议和 gobreaker 这类库配合，当错误率连续 10 秒 > 50%，自动打开熔断器，此时所有请求直走降级，不再尝试主路径
记录降级发生次数和原因（如 "fallback_due_to_context_timeout"），但别在每次降级时打 info 日志——高频降级会导致日志风暴

降级最易被忽略的一点：它和重试不是互斥关系。先重试 2 次（间隔指数退避），再降级，比直接降级更稳妥；但重试必须带 ctx 并共享同一个 deadline，否则会延长整体延迟。