三类注册中心实现方案在透明度与CAP归属上的取舍

实现服务发现有三条不同路线，各自的CAP归属和对应用的透明程度不同。基于 分布式K/V框架自建（ZooKeeper、etcd）：这些框架本身自带共识算法（etcd用 Raft、ZooKeeper用ZAB，都是CP的；也有人用Redis自建、天然AP），只提供 CRUD/Watch这类极简API，服务注册、健康检查等能力都要自己在上面搭建， 如今一般只有大厂才会这样直接造轮子。基于DNS基础设施（SkyDNS、CoreDNS）： 好处是对应用完全透明，任何语言框架天然支持HTTP/DNS，不受技术选型约束； 坏处是这种透明并不简单——客户端负载均衡、远程调用这些问题要自己另外 解决，而且必须受限于DNS协议本身的机制（比如缓存期限只能靠TTL控制，想 换成KeepAlive长连接判活就很麻烦），CP还是AP取决于后端存储实现。专门的 服务发现框架（Eureka、Consul、Nacos）：可以自己决定CP还是AP（甚至像 Nacos一样类Raft协议实现CP、自研Distro协议实现AP两者都支持，但每次只能 二选一，不是同时满足CAP），代价是对应用不透明、需要考虑语言框架集成， 但换来的是开发便捷性——因为配套组件（如Ribbon、OpenFeign）早已做好 集成，写声明式接口就能跑起来。透明度和开发便捷性在这里呈现出此消彼长 的关系。