如何在Golang微服务中使用RPCX作为服务治理通信组件

在实际的微服务架构里，服务注册与发现这件事，rpcx默认是“装死”的——不配插件就不干活。很多新手踩的第一个坑就是：服务端直接 server.Serve() 启动后，客户端用 NewPeer2PeerDiscovery 死活连不上。原因很简单，服务端根本就没向注册中心上报过自己的地址。

必须手动加载注册中心插件，并配好地址。举个 etcd 的例子：

s := server.NewServer(
    server.WithRegistry(&etcd.Registry{
        Address: []string{"http://127.0.0.1:2379"},
        Timeout: 5 * time.Second,
    }),
)

• 注册中心类型（etcd、consul、zookeeper）需要对应导入 github.com/smallnest/rpcx/registry/xxx 包，缺了它就报错。
• server.RegisterName() 的第三个参数是版本号，建议填 "v1"，默认为空，客户端匹配时可能会丢。
• 如果非要用 Peer2PeerDiscovery 这种点对点直连，服务端可以不用注册插件，但客户端得硬编码地址，生产环境就别指望这么干了。

客户端负载均衡策略选错会导致请求全部打到单个实例

NewXClient 的第三个参数是选择器（selector），千万别被 RandomSelect 这个名字骗了——它只在第一次请求时随机挑一个节点，后面所有请求都固定打在那一个上，除非节点挂了才换。这哪里是负载均衡，分明是“定点扫射”。

真正能持续分发请求的策略是 client.RoundRobin 或 client.SmoothWeightedRoundRobin：

xclient := client.NewXClient(
    "Arith", 
    client.Failfast, // 超时立即失败，不重试
    client.RoundRobin, // 每次请求轮询下一个节点
    d, 
    client.DefaultOption,
)

• Failtry 会重试（默认3次），短时不可用时有用，但用不好会放大雪崩风险。
• 权重策略需要服务端注册时带 Weight 字段，否则退化为普通轮询。
• 想自己实现选择器？必须实现 Selector 接口，直接传个函数不行。

传输协议切换要同步改客户端和服务端配置

rpcx 支持 TCP/KCP/QUIC/UTP，但两端协议不匹配时连接直接拒绝，错误信息一般是 read tcp: i/o timeout 或 connection refused，没有明确提示“协议不对”，排查起来很头大。

比如启用 KCP：

• 服务端启动用 s.Serve("kcp", ":8972")，并且编译时需加 -tags kcp。
• 客户端发现器地址必须写成 kcp@localhost:8972，不能仍用 tcp@...。
• KCP 默认开启快速重传和拥塞控制，但在内网稳定环境下效率反而不如 TCP，实测延迟高 10%~15%。

QUIC 同理，Go 版本需要 ≥1.18，编译加 -tags quic，客户端地址前缀为 quic@...。

TLS加密必须两端同时启用，且证书验证逻辑不同

rpcx 的 TLS 不是“开个开关就完事”。服务端配了 WithTLSConfig 后，客户端如果不配 TLSConfig，连接会被直接断开，报错 remote error: tls: bad certificate，而不是连接超时。

• 服务端 tls.Config 中 ClientAuth 设为 tls.RequireAndVerifyClientCert 时，客户端必须提供有效证书，否则握手失败。
• 客户端如果跳过证书校验（InsecureSkipVerify: true），服务端日志里不报错，但通信实际上是明文——rpcx 不强制校验，这个点容易被忽略。
• JWT 认证需要配合 serverplugin.AuthPlugin 使用，单独配 TLS 不等于身份认证已启用。

协议层加密和业务层认证是两件事，缺一不可；很多团队只做了 TLS，就以为安全加固已完成，其实还差得远。