Go net/http Client为不同上游拆分 Transport的工程设计

一个 Go 服务同时访问支付、搜索或文件存储等多个上游时，最稳妥的做法是让每个上游绑定自己的 http.Client 和 http.Transport。公共配置可以先建立基线，再通过 Transport.Clone 派生副本；代理、TLS、连接池和压缩策略只在对应副本上覆盖，不要直接修改全局 http.DefaultTransport。

先把上游约束映射到 Transport 责任

拆分前先列一张上游责任表。请求是否可取消属于请求级问题，放在 context.Context；代理地址、TLS 根证书、连接复用和每主机连接上限属于 Transport 问题。http.Client 则是调用入口，通常作为长期对象复用。

为每个上游创建独立 Client 和 Transport

公共基线只保存确实相同的连接策略，例如环境代理、空闲连接总数和连接空闲时间。下面的例子让上游 A 限制每主机空闲连接数，让上游 B 关闭自动压缩；两个客户端不会互相覆盖配置。

package upstream

import (
    "context"
    "fmt"
    "io"
    "net/http"
    "time"
)

type Clients struct {
    A *http.Client
    B *http.Client
}

func NewClients() *Clients {
    // 只把两个上游真正共用的连接策略放进基线。
    base := &http.Transport{
        Proxy:                 http.ProxyFromEnvironment,
        MaxIdleConns:          100,
        MaxIdleConnsPerHost:   20,
        IdleConnTimeout:       90 * time.Second,
        TLSHandshakeTimeout:   10 * time.Second,
    }

    // Clone 后再覆盖差异，避免复用同一个可变 Transport。
    aTransport := base.Clone()
    aTransport.MaxIdleConnsPerHost = 8
    bTransport := base.Clone()
    bTransport.DisableCompression = true

    return &Clients{
        A: &http.Client{Transport: aTransport, Timeout: 15 * time.Second},
        B: &http.Client{Transport: bTransport, Timeout: 30 * time.Second},
    }
}

func Fetch(ctx context.Context, client *http.Client, endpoint string) ([]byte, int, error) {
    // context 只控制当前调用，不能把请求截止时间写入共享 Transport。
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, endpoint, nil)
    if err != nil {
        return nil, 0, err
    }
    resp, err := client.Do(req)
    if err != nil {
        return nil, 0, err
    }
    // 读取完成后关闭响应体，连接才有机会回到空闲池。
    defer resp.Body.Close()
    body, err := io.ReadAll(resp.Body)
    return body, resp.StatusCode, err
}

这里的关键不是把配置复制得越多越好，而是把差异显式留在对应上游。Client.Timeout 可以作为总时限，具体请求仍建议传入带截止时间的 context。客户端和 Transport 都适合并发复用，因此应放在服务对象、依赖容器或进程级初始化中。

把请求级超时与连接级策略分开

常见误区是为了某一个慢请求临时修改 Transport，或者为每次调用新建 Client。前者会把局部需求带给其他请求，后者会损失连接复用并增加握手开销。正确边界是：Transport 固定上游的网络策略，context 描述本次调用能等待多久。

ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel() // 释放定时器，避免调用结束后仍保留计时资源。

body, status, err := Fetch(ctx, clients.A, "https://api-a.example/v1/profile")
if err != nil {
    // 日志应带上游标识，区分取消、连接失败和响应读取失败。
    return fmt.Errorf("upstream A request failed: %w", err)
}
_ = body
_ = status

示例中的域名只是占位符，实际项目应使用自己的上游地址。需要注意，context 取消并不等于服务端一定停止处理；它首先保证本地调用尽快返回，并让底层请求释放本地资源。

用关闭动作和故障维度守住工程边界

配置发生热切换时，先让新 Client 接管，再对旧 Client 调用 CloseIdleConnections，清理不再需要的空闲连接。不要在每个请求结束后关闭整个 Transport，也不要把 resp.Body.Close 省略掉。

排查多上游问题时，日志至少记录 upstream、请求路径、耗时、错误类型和 HTTP 状态码。连接建立失败、TLS 握手超时、响应头等待超时与业务状态码不是同一类故障，分开记录才能决定是调整 Transport、请求 context 还是处理上游返回。

常见问题

多个上游可以共享一个 Transport 吗？

只有代理、TLS、连接池和协议策略确实相同，并且不需要独立关闭或独立观测时才适合共享。只要网络边界或生命周期不同，就用独立 Transport。

为什么不建议直接改 http.DefaultTransport？

它可能被服务中的其他调用共享，修改一个上游的代理、TLS或连接上限会产生跨模块串扰。更清晰的方式是自建基线并按上游 Clone。

Client 和 Transport 应该每次请求创建吗？

不应该。官方文档明确建议并发复用 Client 与 Transport；请求差异放进 request、Header 和 context，连接级差异放进长期存活的 Transport。