etcd 与配置中心选型：一致性、监听与容灾的三维对比

一个反复出现的选型题

「服务发现用 etcd，配置用 Nacos/Apollo，还是全用 etcd？」这个选型题几乎每个微服务团队都会遇到。答案取决于三个维度：一致性要求、监听机制、容灾与运维成本。这篇给一个三维对比框架。

一、一致性：强一致 vs 最终一致的适用边界

- etcd：基于 Raft 的强一致，每次写入需要多数派确认——适合服务发现（实例列表错了会路由到不存在的节点）、分布式锁、leader 选举这类「一致性错误代价高」的场景；

- Nacos/Apollo 类配置中心：配置分发多为最终一致（客户端轮询或长轮询拉取），秒级延迟——配置场景对一致性的容忍度高（配置错了改回来就行），换来的却是更好的水平扩展与多数据中心支持。

判断标准：数据的错误半径。etcd 里存的是「系统运行的拓扑真相」，错了全错；配置中心里存的是「系统运行的行为参数」，错了可回滚。

二、监听机制：watch 的语义差异

- etcd watch：基于 Raft revision 的事件流，事件不丢、有序，客户端断线重连从历史 revision 续传——语义精确，但客户端要处理事件重放逻辑；

- 配置中心长轮询：客户端定时拉取变更，实现简单、对网络友好，但变更延迟等于轮询间隔，且拿不到变更历史。

服务发现的场景需要 watch 语义（实例上下线要实时感知）；配置下发对秒级延迟不敏感。这是两者分工的技术根基。

三、容灾与运维：真正的分水岭

- etcd：3/5 节点 Raft 集群，扩容缩容要动多数派，磁盘性能敏感（Raft 写入 fsync），运维门槛高——它是个「需要被认真运维的分布式系统」；

- 配置中心：Nacos 支持 AP/Dual 模式切换，Apollo 的多数据中心架构成熟，云厂商托管版本免运维——更接近「开箱即用的基础设施」。

中小团队的建议：配置用云托管配置中心（免运维），服务发现直接用 K8s 原生（K8s 自己的 etcd 就是服务注册表）——多数团队的 etcd 需求已经被 K8s 内置消化了。只有自建服务发现（非 K8s 环境）或需要分布式协调原语的团队才需要自管 etcd。

四、混合形态：各取所长的真实架构

成熟团队的真实形态往往是混合的：K8s etcd 管服务发现、Nacos 管业务配置与动态参数、Apollo 管应用配置、etcd 独立集群管分布式锁与选型类协调原语。关键原则：每类数据放在「错误半径与一致性要求匹配」的存储里，而不是追求单一组件统一天下——统一带来的运维集中度收益，会被故障半径扩大抵消。

结语

选型没有标准答案，只有匹配答案。三个维度按你的业务排序：一致性错误代价、监听实时性要求、运维投入意愿——三个答案组合出来的选择，就是你的正确选择。