Kratos客户端默认启用P2C负载均衡，但需服务发现正常返回节点列表才能生效；验证方式包括查日志“p2c: picked node”、调用/debug/selector接口、模拟延迟观察切换行为，并排查Registry连通性、服务名一致性及Resolver注册问题。
Kratos 客户端负载均衡默认启用 P2C，不需要额外配置；但服务发现若没配对或 Resolver 不生效，负载均衡就形同虚设——节点列表为空，Select 方法永远返回 nil。
如何确认 P2C 负载均衡已实际生效
别只看代码里有没有 SetGlobalSelector，关键得验证运行时是否真在选节点。P2C 的核心行为是：每次调用前从当前可用节点中随机挑两个，比 EWMA 延迟 + in-flight 请求量 + CPU 使用率（如果服务端上报了）得出胜出者。
- 检查日志里是否有
"p2c: picked node"或类似调试输出（需开启kratos/log的 debug 级别） - 用
curl http://localhost:9000/debug/selector（如果启用了 debug server）查看当前节点列表和权重快照 - 故意让一个后端延迟飙升（如加
time.Sleep(2 * time.Second)），观察客户端是否快速切走——P2C 对延迟敏感，3 秒内就会降权 - 注意：
inflight统计依赖 gRPC 的UnaryClientInterceptor，若手动绕过拦截器（比如直连grpc.Dial），P2C 就收不到实时请求数，会退化为纯延迟比较
服务发现没返回节点的 3 个高频原因
负载均衡器再聪明，也得有节点可选。常见“空列表”问题往往卡在服务发现环节，而非 Balancer 本身。
-
Registry配置地址错或不可达：比如consul.address = "127.0.0.1:8500"在容器里访问不到宿主机；用telnet consul:8500或curl -v http://consul:8500/v1/status/leader实测连通性 - 服务注册名不一致：客户端
Dial("discovery:///user.service")中的user.service必须和服务端注册时的ServiceInstance.Name完全匹配（区分大小写、无空格） - Resolver 未注册或 scheme 不匹配：Kratos 默认只内置
dns和passthrough；若用kuberesolver，必须提前resolver.Register(&kuberesolver.Builder{})，且 Dial 地址必须是dns:///user-service.default.svc.cluster.local这类合法 DNS 格式
为什么 Headless Service + kuberesolver 是 Kubernetes 下的刚需
普通 Kubernetes Service（ClusterIP）背后是 kube-proxy 的 iptables/ipvs 规则，gRPC 客户端一旦建连就长驻单个 Pod，其他副本完全闲置——这不是负载均衡，是单点连接。
- Headless Service（
clusterIP: None）让 DNS 解析直接返回 Pod IP 列表，kuberesolver才能拿到真实后端地址传给 Balancer - 必须关闭 gRPC 的 DNS 缓存：在
grpc.DialOption中加grpc.WithResolvers(kuberesolver.Builder)，并确保不带grpc.WithBlock()，否则会卡死在初始解析 - 注意 kuberesolver 的 namespace 默认是
default，跨 namespace 调用需显式拼接完整域名，如user-service.oasis-dev.svc.cluster.local
调试时怎么拿到当前调用的真实后端地址
线上排查经常要确认“这次请求到底打到哪个实例了”，不能只靠日志猜。
- 在 RPC 方法里用
peer.FromContext(ctx)获取对端信息：if p, ok := peer.FromContext(ctx); ok { log.Printf("actual backend: %s", p.Addr.String()) } - 这个地址是 Balancer
Select后建立连接时注入的，所以必须在拦截器或业务 handler 内获取，不能在Dial阶段 - 如果用的是自定义 Balancer 且没调用
cc.NewSubConn的opts注入peer.Peer，这里就会是空值 - 生产环境慎用：频繁调用
peer.FromContext并打印会增加 context 查找开销，建议仅限 debug 模式开启
真正容易被忽略的是：服务发现与负载均衡的生命周期耦合度极高。节点列表更新不及时（比如 Consul 健康检查间隔设成 30 秒），P2C 再灵敏也得等下一次 Apply；而 Resolver 若没实现 watch 机制，节点上下线就只能靠轮询兜底。这些细节不在代码里显眼，却决定着流量能否真正均匀分散。
