ZK 还是 etcd：云原生时代的协调服务选型

先把协议账算平

第 15 篇在锁视角选过一轮，本篇把镜头拉到基础设施视角：到底养不养一个协调服务，养谁。先算协议账——ZAB 与 Raft 在能力上半斤八两：都是 Leader 主写、过半提交、任期制防脑裂、日志复制保安全（第 9、13 篇已对照过）。差异在工程气质：ZAB 为 ZooKeeper 深度定制，外界复用不了；Raft 作为通用共识算法被工业界大规模复用（etcd、TiKV、Consul、CockroachDB），实现多、资料多、可验证性强。协议账打平之后，选型天平真正压下来的三块砝码是：数据模型、时代生态、运维成本。

功能账：细节气质的差异

两家功能清单高度重合——强一致 KV、Watch 变更、临时性（会话/租约）、选主与锁——差异在气质。ZooKeeper 是树形命名空间，目录层级天然表达从属关系（/services/order/provider-1），但子节点数量多了 getChildren 全量拉取笨重；etcd 是扁平 key 空间加范围查询，prefix range 一次拿一批，配合 MVCC 修订号还能查任意历史版本——「这个 key 上个月是什么值」只有 etcd 秒答。Watch 的成色上一系列已经对比过：一次性续订对流式订阅，后者省一个数量级的代码。gRPC 对 HTTP/2 多路复用也让 etcd 在连接利用率上占优。

时代账：生态绑定才是主战场

ZooKeeper 生于 2008 年的 Hadoop 时代，Java 加 JVM，撑起了 Kafka（早期）、HBase、HDFS、Dubbo、Solr 的元数据底座——大数据与 RPC 的老栈里 ZK 躲不掉。etcd 生于 2013 年的 CoreOS，Go 加 gRPC，2014 年成为 Kubernetes 的存储内核——云原生栈里 etcd 是空气。由此推出本篇最实用的结论：选型往往不是「选谁」，而是「你已经在用谁」。跑在 K8s 上的团队，etcd 集群已经在机房里了，复用它做锁与选主是零增量成本（注意容量与压力别拖累 K8s 本身）；Kafka、Dubbo 老栈团队，ZK 就在旁边，顺手用；绿地新项目、云原生优先，直接 etcd。

运维账：各自的家务事

两家的运维家务清单各有各的琐碎。ZooKeeper：JVM 调优（堆大小、GC 选型直接影响会话误判率，第 11 篇的红线）、事务日志与快照的磁盘规划、集群扩缩容要逐台滚动重启；ZNode 数据量一大，启动恢复慢。etcd：MVCC 历史不清理会膨胀，要定期 compaction（压缩修订历史）加 defrag（碎片整理），磁盘 IO 抖动直接威胁 Raft 心跳——官方反复强调 etcd 对磁盘延迟敏感，ssd 起步。好消息是两家的托管服务都已成熟（各大云的注册配置中心产品），愿意花钱换省心的话，家务清单可以整张外包。规模参考：3 节点起步扛日常，5 节点扛半数单点故障与滚动升级，更大规模说明用法该反思（协调服务不该扛业务数据）。

收束成一句决策口诀：老栈用 ZK，新栈用 etcd，都为了锁才引入的话——先回去看第 16 篇，确认真的绕不开再养。协调服务是基础设施级的投入，它的正确性红利要叠在「低频高危」的场景上才划算。下一篇把系列里所有反面教材集结成册：七个生产事故，条条都有前文伏笔。