服务发现是客户端行为，需与连接管理、健康探测、路由决策耦合；C++中须用thread_local或加权随机避免轮询状态冲突，etcd watch需双缓冲+独立线程，DNS-SD不适用于生产级负载均衡。
服务发现不是注册中心，而是客户端行为
RPC 服务发现的核心不在服务端“提供什么”，而在客户端“怎么找”。C++ 没有内置的服务发现机制，etcd、consul 或 nacos 都只是存储载体，真正决定负载均衡策略的是客户端 SDK 的实现逻辑。
常见错误是把服务发现写成“定时拉取一次列表 + 随机选一个”，这会导致：节点下线后仍被调用、权重更新延迟、连接复用失效。关键点在于——发现必须和连接管理、健康探测、路由决策耦合。
-
std::shared_ptr管理服务实例生命周期，避免裸指针悬挂 - 每个
ServiceInstance必须带last_heartbeat_time和fail_count字段，用于剔除不可用节点 - 不直接缓存 IP:port 字符串，而缓存封装了连接池、重试策略、熔断器的
EndpointHandle对象
如何让 round-robin 真正“轮”起来（非线程安全陷阱）
C++ 中最常写的 round_robin_picker 在多线程并发调用时会错乱，因为多个线程共享同一个计数器变量。这不是算法问题，是状态隔离缺失。
典型错误现象：std::atomic<int> idx_</int> 被所有 RPC 调用共用，结果高并发下大量请求打到同一台机器，负载严重倾斜。
立即学习“C++免费学习笔记（深入）”；
- 正确做法：为每个线程或每个
Channel实例维护独立的idx_，用thread_local或std::unordered_map<:thread::id int></:thread::id>存储 - 更稳妥的是改用加权随机（
weighted_random_picker），它天然无状态，只要权重更新及时，比轮询更抗抖动 - 如果坚持用轮询，务必在
pick()返回前做健康检查 —— 否则刚轮到的节点可能已失联
etcd watch 机制在 C++ 客户端中的落地难点
C++ 生态里没有像 Go 那样开箱即用的 Watch 接口，用 libcurl 或 grpc++ 手写长连接容易卡死或漏事件。根本问题是：HTTP/2 流式响应需与本地服务列表变更同步，且不能阻塞主调用线程。
错误表现：etcd watch 连接断开后没重连、收到 PUT 事件但没更新内存中 ServiceDiscoveryCache、并发更新 cache 导致 std::map 迭代器失效。
- 必须用独立线程跑 watch 循环，配合
std::condition_variable通知主线程刷新 - cache 更新要用双缓冲：先构建新
std::vector<serviceinstance></serviceinstance>，再原子交换指针（std::atomic_load/store） - watch path 建议设为
/services/{service_name}/，避免监听根路径导致事件爆炸
为什么不用 DNS-SD？gRPC 的 dns:// 不适合生产级负载均衡
dns:// scheme 看似简单，但它依赖操作系统 resolver 缓存（如 /etc/resolv.conf 中的 options timeout:），实际无法控制 TTL、不支持权重、无法主动探活。
真实场景下，DNS 返回的 A 记录可能被内核缓存 30 秒，期间节点宕机也不会感知；SRV 记录在多数 Linux 发行版默认不启用，getaddrinfo() 甚至忽略 port 字段。
- 除非你完全控制 DNS 基础设施（比如 CoreDNS + 自定义插件），否则别指望
dns://做服务发现 - gRPC C++ 的
resolver接口可自定义，但实现一个支持健康检查 + 权重 + watch 的CustomResolver工作量远超直接对接 etcd client - 若已有 DNS 基础设施，建议只用它做初始引导（bootstrap），后续立刻切到 etcd/consul 的长连接 watch
真正的难点从来不是“怎么注册”，而是“怎么让每次 channel->CreateCall() 都拿到当前最健康的 endpoint”。这个决策链路上任何一环（缓存、网络、解析、连接池）出偏差，负载就失衡了。
