17370845950

Go微服务依赖管理需显式控制连接行为、超时、重试、熔断与服务发现；HTTP/gRPC调用必须使用带截止时间的context，禁用硬编码地址，区分错误类型重试，保障幂等性，并通过真实业务路径健康检查。

Go 本身没有内置的“微服务依赖管理”机制——go mod 管理的是代码包依赖，不是运行时服务依赖。真正要控制的是服务间调用的**连接行为、超时、重试、熔断和发现方式**。

服务调用前必须显式配置超时与上下文取消

Go 的 http.Client 和 gRPC 客户端默认不设超时，一次卡死会拖垮整个调用链。所有出向请求都应绑定带截止时间的 context.Context。

• HTTP 调用：用 http.NewRequestWithContext()，不要用 http.Get() 这类便捷函数
• gRPC 调用：每个 CallOption 都需传入 grpc.WaitForReady(false) + grpc.Timeout(5 * time.Second)
• 避免在 handler 中直接用 context.Background() 构造子 context；应从入参 ctx 派生

req, _ := http.NewRequestWithContext(ctx, "GET", "http://user-svc:8080/profile/123", nil)
resp, err := httpClient.Do(req) // httpClient 应复用，且 Transport 已配好 IdleConnTimeout

不要在代码里硬编码服务地址

写死 "http://order-svc:9001" 或 "order-svc:900

• 通过环境变量注入，如 ORDER_SERVICE_ADDR，启动时校验非空
• 或使用服务发现客户端（Consul、Nacos、etcd）动态拉取，但需封装重试+缓存逻辑，避免每次调用都查注册中心
• Kubernetes 环境下优先用 DNS 名（order-svc.default.svc.cluster.local），由 kube-dns 解析，无需额外组件

重试策略必须按错误类型区分，不能无脑重试

对 400、404、501 这类语义明确的错误重试毫无意义；而连接拒绝、超时、503 才值得重试。gRPC 的 RetryPolicy 或 HTTP 中间件需精细控制。

• HTTP：用 retryablehttp.Client，设置 RetryMax 和 RetryBackoff，并自定义 CheckRetry 函数过滤状态码
• gRPC：启用 grpc.WithDefaultCallOptions(grpc.RetryPolicy(...))，但注意 v1.54+ 后该 API 已标记为实验性，生产建议用中间件封装
• 幂等性必须由业务保证：GET /idempotent-order?token=xxx 比盲目重试 POST /order 更可靠

retryClient := retryablehttp.NewClient()
retryClient.RetryMax = 2
retryClient.CheckRetry = func(ctx context.Context, resp *http.Response, err error) bool {
    if err != nil || resp.StatusCode == 400 || resp.StatusCode == 404 {
        return false // 不重试
    }
    return resp.StatusCode >= 500
}

依赖健康检查不能只 ping 端口，要走真实业务路径

只用 tcp.Dial 检查 order-svc:9001 是否通，掩盖了服务已启动但 DB 连接池耗尽、Redis 拒绝新连接等问题。

• 暴露 /health 接口，内部执行关键依赖探活（如 SELECT 1、PING Redis、调用下游 /ready）
• 调用方在初始化 client 时，可同步发起一次 HEAD /health，失败则 panic 或降级到备用地址
• K8s 的 livenessProbe 和 readinessProbe 应指向该接口，避免流量打入未就绪实例

最容易被忽略的是：依赖控制不是加几个库就能解决的，它要求每个服务明确声明自己依赖谁、以什么方式调用、失败后如何退化。一个没写 context.WithTimeout 的 HTTP 调用，可能让整个请求链在等待下游时静默卡住 30 秒——而监控里只看到“慢”，看不到根因。