C++ gRPC 官方库（v1.60+）不支持XDS服务发现，因高维护成本与低使用率未实现xdslb/xds_resolver；替代方案有DNS SRV+自定义resolver、etcd/ZooKeeper轮询watch、Envoy sidecar透传。
gRPC C++ 客户端怎么用 XDS 做服务发现
不能直接用。C++ gRPC 官方库至今（v1.60+）不支持 XDS 服务发现协议，grpc::Channel 默认只认 DNS、fake_resolver 或自定义 resolver，但没内置 xdslb 或 xds_resolver。
为什么 C++ 没有 XDS 支持
Google 内部早期用 XDS 主要驱动 Envoy 和 Go/Java 客户端，C++ 侧长期聚焦于高性能和稳定性，XDS 实现被判定为“高维护成本 + 低使用率”。直到现在，grpc::experimental::CreateCustomResolver 虽开放了接口，但官方没提供 XDS 协议解析、EDS/CDS/LDS/RDS 状态机、安全凭据加载等完整逻辑。
常见错误现象：GRPC_ARG_DNS_ENABLE_SRV_QUERIES=1 不起作用；配置 xds:// URI 报 Unknown resolver scheme: xds；或客户端静默 fallback 到 DNS。
- XDS 需要 TLS 双向认证、x509-SVID 证书轮换、gRPC over gRPC（XDS 控制面本身是 gRPC 服务），C++ 库缺少配套 credential 插件
- EDS 响应里的 endpoint 权重、health status、metadata 解析需手动映射到
grpc::ChannelArgs，官方无标准转换规则 - 控制面变更（如集群下线）触发的 graceful shutdown 流程，C++ resolver API 未暴露连接驱逐钩子
实际能用的替代方案
绕过 XDS，但保留服务发现能力，有三个可落地的选择：
立即学习“C++免费学习笔记（深入）”；
-
DNS SRV 记录 + 自定义 resolver：在 Kubernetes 中部署 CoreDNS 插件生成
_grpc._tcp.svc.cluster.localSRV 记录，再用grpc::experimental::CreateCustomResolver解析，比硬编码 host:port 更可控 -
etcd/ZooKeeper + 轮询 watch：启动时从 etcd 读取
/services/my-service/instances，监听变更，用grpc::ChannelArguments::SetPointer注入grpc_channel_args构建grpc::Channel，注意避免频繁重建 Channel（会丢连接） -
Envoy sidecar 透传：最省事——让 C++ 客户端连本地
127.0.0.1:10000的 Envoy，由 Envoy 负责 XDS 接入、负载均衡、熔断。此时客户端完全无感，但多一层网络跳转，延迟增加 ~0.2ms（实测）
示例（DNS SRV 场景）：grpc::CreateChannel("dns:///my-service.default.svc.cluster.local", ...)，前提是 CoreDNS 已配置 SRV 回应，且 gRPC 编译时启用了 GRPC_DNS_RESOLVER=ares。
如果非要自己写 XDS resolver，关键坑在哪
不是写不出来，而是容易在线上出 silent failure：
-
grpc_resolver_next_result返回的grpc_channel_args必须包含GRPC_ARG_SERVER_URI，否则 channel 初始化失败但不报错 - XDS 响应中的
load_assignment.endpoints[0].lb_endpoints[i].endpoint.address是envoy.config.core.v3.Address，需手动 decode 成grpc_resolved_address，字节序、IPv6 scope_id 容易翻车 - 控制面断连后，resolver 必须主动调用
grpc_resolver_next_locked触发重试，否则客户端永远卡在旧 endpoints - 不用
grpc_timer管理心跳，而用 std::thread + sleep，会导致 gRPC 内存泄漏（timer heap 被 bypass）
真正麻烦的不是协议解析，是状态同步：CDS 更新 cluster 后，EDS 必须等对应 cluster ready 才能发请求，否则 UNAVAILABLE 错误里看不到真实原因。
