不是必须选etcd或Consul，而是取决于控制面是否绑定Kubernetes：K8s环境优先复用etcd，轻量稳定；混合环境（VM+容器）则选Consul，因其原生支持多数据中心、DNS接口和丰富健康检查，但需单独运维。
服务发现必须选 etcd 还是 Consul？
不是“必须选谁”，而是看你的控制面是否已绑定 Kubernetes。etcd 是 K8s 的底层存储，如果你的微服务跑在 K8s 集群里，直接复用 etcd 做服务注册最省事，clientv3 SDK 稳定、轻量、无额外运维负担；Consul 更适合混合环境（比如部分服务在 VM、部分在容器），它自带健康检查 UI 和 DNS 接口，但要单独部署和维护 Server 集群。
常见错误：在 K8s 环境里硬上 Consul，结果 Service IP 变更后 Consul 里的注册信息滞后，导致 connection refused 或路由到已销毁 Pod。
- etcd 场景下，用
clientv3.Watcher监听/services/{name}路径，比轮询快且节省资源 - Consul 场景下，务必关闭默认的
passing健康检查模式，改用tcp或自定义 HTTP 检查，否则节点假死不剔除 - 两者都别依赖客户端缓存——gRPC 的
round_robinLB 默认不刷新后端列表，得配合resolver.Builder主动 reload
gRPC 服务间通信怎么避免超时雪崩？
超时不是设一个 context.WithTimeout 就完事。gRPC 客户端默认没有重试策略，下游抖动时，上游会堆积大量 goroutine 等待响应，最终触发内存溢出或连接耗尽。
真实场景中，DeadlineExceeded 错误往往不是网络问题，而是下游服务因 GC STW 或锁竞争卡住 5 秒以上。
立即学习“go语言免费学习笔记（深入）”；
- 每个 RPC 方法单独配超时，不要全局统一设 5s；读操作可设 2s，写操作根据业务逻辑设 8–15s
- 启用 gRPC 内置重试：
grpc_retry.WithMax(2)，但必须加grpc_retry.WithPerRetryTimeout(3 * time.Second)，否则重试会继承原始 timeout - 关键链路（如订单创建）禁用重试，改用幂等 key + 状态机兜底，避免重复扣库存
- 在中间件里记录
grpc.Peer和实际耗时，别只看status.Code，很多Unknown错误其实是 TCP RST 导致的
分片键（shard key）选错会导致什么？
一致性哈希只是分片工具，真正决定负载是否均衡的是分片键本身。选错键，再好的哈希算法也救不了——比如用用户手机号做订单分片键，结果 80% 订单集中在前三位数字为 “138/139/186” 的几个节点上。
典型错误现象：cpu_usage > 90% 的 Data Node 日志里反复出现同一段 GetNode("138****") 调用。
- 优先选业务实体 ID（如
order_id），但必须确保其生成逻辑具备全局唯一性和散列性；雪花算法生成的 ID 天然适合 - 避免用时间戳、自增序列、地域编码等有明显偏斜倾向的字段
- 如果必须用非均匀字段（如用户昵称），先做一次
sha256(nickname)[:8]再哈希，别直接crc32([]byte(nickname)) - 上线前用真实流量抽样跑
GetNode10 万次，统计各节点命中次数标准差，超过均值 ±15% 就得换键
故障转移时 etcd watch 为什么丢事件？
etcd v3 的 watch 机制不是强顺序保证的——当 leader 切换或网络分区恢复时，client 可能错过中间的 delete + put 事件，导致本地服务列表状态陈旧。这不是 bug，是设计权衡。
现象是：某个服务实例宕机后，客户端还在往它发请求，直到下一次健康检查失败才剔除，间隔可能长达 30 秒。
- 永远不要只依赖单次 watch 事件更新服务列表；每次收到事件后，主动调用
clientv3.Get全量拉取最新/services/xxx下所有 key - 给每个服务实例加 lease TTL（比如 15s），服务端必须定期
KeepAlive，断连自动过期，比 HTTP 健康检查更及时 - watch 的
WithPrevKV选项有用，但只对变更事件有效，对初始 list 没帮助，得自己补全 - 如果业务容忍秒级不一致，直接用 K8s Endpoints + Headless Service，比自己搞 etcd watch 更可靠
真正卡住落地的，从来不是“能不能实现”，而是分片键选型时没压测、etcd watch 没补全、gRPC 超时没分层——这些点不手工验证一遍，架构图再漂亮也没法上线。
