Consul 默认AP模型（可用性优先），Etcd基于Raft实现CP（强一致性）；网络分区时Consul可能返回过期服务列表，Etcd则拒绝读请求。
Consul 与 Etcd 的一致性模型差异直接影响服务发现可靠性
Consul 默认走 AP 模型（可用性优先），Etcd 基于 Raft 实现 CP（强一致性）。这意味着：网络分区时，Consul 可能返回过期的服务列表，而 Etcd 会拒绝读请求——不是谁“更好”，而是你的业务能否容忍短暂不可用或临时脏数据。
实操建议：
- 订单、支付等强依赖服务实例准确性的场景，选
etcd；它能保证你拿到的节点列表一定是当前多数派确认存活的 - API 网关、日志收集等对短暂抖动不敏感的场景，
consul更合适；它的 DNS 接口和内置健康检查省去大量客户端逻辑 - 别混用：同一个集群里同时往
consul和etcd注册同一服务，会因心跳周期、超时策略不同导致状态撕裂
服务注册后立即不可见？检查租约与心跳配置
常见错误现象：client.Agent().ServiceRegister() 返回成功，但其他服务查不到该实例——本质是注册中心没把它当“健康节点”纳入服务列表。
原因通常是租约未绑定或心跳失效：
立即学习“go语言免费学习笔记（深入）”；
-
consul中必须显式设置Check.TTL或Check.HTTP，否则注册后立刻被标记为critical -
etcd要求客户端主动维护租约：lease.Grant()后需持续调用lease.KeepAlive()，漏掉一次就触发自动注销 - Go 服务启动后立即注册，但 HTTP 健康检查端点（如
/health）还没 ready，导致 consul 误判下线
消费者拿到服务列表后，如何避免缓存过期导致调用失败
服务发现不是“查一次就够了”。节点可能随时宕机、扩容或滚动更新，硬编码或本地缓存 IP 列表等于埋雷。
正确做法是结合注册中心的 watch 机制 + 客户端负载均衡：
- 用
consul api.ServiceHealth().Get()配合BlockingQuery参数实现长轮询，有变更才拉新列表 - 用
etcd clientv3.Watcher监听/services/order/这类前缀路径，事件驱动更新内存中的 endpoints - 不要自己写重试逻辑去 ping 每个 IP；改用
grpc-go的round_robin或pick_first策略，让 SDK 自动剔除不可达节点
跨数据中心服务发现失效？Consul 的 multi-DC 不是开箱即用
Consul 支持多数据中心，但默认只同步服务目录元数据，不复制健康状态。A 数据中心的节点在 B 数据中心显示为 “passing”，实际可能已宕机。
关键控制点：
- 启用
retry_join_wan并确保 WAN Gossip 正常，否则 DC 间无法建立连接 - 跨 DC 调用必须显式指定
Datacenter参数，consul.Client不会自动路由 - 健康检查结果默认不跨 DC 同步；需在 server 端配置
enable_remote_exec = true并开放 ACL 权限，代价是增加延迟和安全风险
真正难的不是注册或发现，而是让“服务存在”这个事实，在所有观察者眼里保持同步——这取决于你愿意为一致性付出多少延迟和运维成本。
