Golang RPC长连接与复用实现方法

Go rpc.Client 默认不复用连接，需手动长期持有同一实例并发调用，并在连接异常时重建；HTTP 模式下须自定义 http.Transport 启用连接池，且需主动健康检查与错误重试。

Go rpc.Client 默认不复用连接，需手动管理

Go 标准库的 net/rpc 包中，rpc.Dial（如 rpc.DialHTTP 或 rpc.Dial）每次调用都会新建 TCP 连接，不会自动复用。这意味着频繁调用 rpc.Dial 会快速耗尽本地端口、触发 TIME_WAIT、增加 handshake 开销。真正的“长连接复用”必须由使用者显式持有并重复使用同一个 *rpc.Client 实例。

复用 *rpc.Client 的正确姿势

核心原则：一个连接对应一个 *rpc.Client，该实例可安全并发调用（内部已加锁），且应长期复用直至服务不可达或主动关闭。

• 不要在每次 RPC 调用前 rpc.Dial，也不要在调用后立刻 client.Close()
• 应在初始化阶段建立连接，保存为包级变量、结构体字段或通过依赖注入传递
• 连接异常（如网络中断）时，Call 或 Go 方法会返回错误，此时应重建 *rpc.Client 并替换旧实例（需加锁保护）
• *rpc.Client 不是线程安全的 Close —— 多个 goroutine 同时调用 Close() 可能 panic，确保仅由单一控制流关闭

var client *rpc.Client

func initClient() {
    var err error
    client, err = rpc.Dial("tcp", "127.0.0.1:8080")
    if err != nil {
        log.Fatal(err)
    }
}

func CallService(method string, args interface{}, reply interface{}) error {
    return client.Call(method, args, reply)
}

HTTP 模式下复用更需注意 http.Transport

若使用 rpc.DialHTTP，底层走 HTTP/1.1，复用依赖于 http.Transport 的连接池。但标准 rpc.DialHTTP 创建的是无配置的默认 client，其 transport 不启用 KeepAlive 或复用。必须手动构造带复用能力的 *http.Client，再传给 rpc.NewClient。

• 直接调用 rpc.DialHTTP 仍会新建连接，无法复用
• 应使用 rpc.NewClient + 自定义 *http.Client，其中 Transport 配置 MaxIdleConns 和 MaxIdleConnsPerHost
• HTTP RPC 的 client.Close() 实际关闭底层 HTTP 连接，复用时切勿频繁关闭

transport := &http.Transport{
    MaxIdleConns:        100,
    MaxIdleConnsPerHost: 100,
}
httpClient := &http.Client{Transport: transport}
conn, _ := httpClient.Post("http://127.0.0.1:8080/_goRPC_", "application/json", nil)
client := rpc.NewClient(conn)

连接健康检查与自动重连容易被忽略

复用连接不等于永不失败。网络抖动、服务重启、防火墙超时都会让已有连接静默失效。仅靠 Call 返回 error 是被动响应，无法提前剔除坏连接。生产环境需配合主动探测或失败回退策略。

• 不要假设 client != nil 就代表连接可用 —— Write 可能阻塞或返回 io.EOF/connection refused
• 可在调用前发轻量 ping 方法（服务端实现空逻辑），或对错误类型做判断（如 net.OpError 表示底层连接异常）
• 建议封装一层 CallWithRetry，在首次失败后重建 client 并重试一次（避免雪崩）
• 连接复用周期越长，越需要考虑服务发现与 endpoint 变更 —— 静态地址复用可能指向已下线实例

复用本身很简单，难的是在连接失效边界上保持行为稳定；多数问题不出在 Dial，而出在 Close 和错误处理的时机。