在微服务架构中，Eureka、Zookeeper 和 Consul 作为服务注册与发现组件，它们在一致性模型、健康检查机制以及 CAP 理论中的定位上有哪些关键差异？
考察说明
评估对微服务注册中心原理差异的理解，以及根据 CAP 和场景进行技术选型的能力。
回答思路
- 【回答框架 1】Eureka 基于 AP 原则，优先保证可用性和分区容错性，节点间采用对等复制，服务注册信息最终一致，客户端缓存与服务端心跳机制保障高可用。
- 【回答框架 2】Zookeeper 基于 CP 原则，通过 ZAB 协议实现强一致性，当 Leader 节点故障时，在选举期间服务不可用，适合对一致性要求高、对短暂不可用容忍度低的场景（如分布式协调）。
- 【回答框架 3】Consul 同样偏向 CP，采用 Raft 协议，支持多数据中心，提供 HTTP/DNS 接口，健康检查更灵活（支持 TCP、HTTP、gRPC），并集成 Key-Value 存储。
- 【回答框架 4】在健康检查方面，Eureka 通过客户端心跳续约，Zookeeper 依赖临时节点与 session 超时，Consul 可定制健康检查策略，三者对实例状态的感知及时性不同。
- 【回答框架 5】适用场景：Eureka 适合需要高可用、允许数据短暂不一致的微服务注册；Zookeeper 适合强一致性的分布式协调；Consul 适合需要多数据中心和灵活健康检查的微服务，且支持配置管理，但运维复杂度相对较高。
- 【关键点 1】Eureka 是 AP 系统，保障可用性，数据最终一致。
- 【关键点 2】Zookeeper 是 CP 系统，强一致但Leader选举期间不可用。
- 【关键点 3】Consul 基于 Raft，支持多数据中心，健康检查灵活。
- 【关键点 4】Eureka 用客户端心跳，Zookeeper 用临时节点，Consul 支持多种健康检查方式。
- 【关键点 5】选型时需结合业务对一致性、可用性和运维成本的要求。
- 【易错点 1】误认为所有注册中心都保证数据强一致，实际 Eureka 是最终一致。
- 【易错点 2】忽略 Zookeeper 在节点故障时短暂不可用的风险。
- 【易错点 3】将 Consul 的 Key-Value 存储与配置中心功能混淆，它本身提供 KV 存储，但配置管理需结合其他工具或使用其内置功能。