在微服务架构中，Eureka 与 Zookeeper 各自扮演什么角色？请从服务注册与发现、一致性模型、可用性、集群通信方式以及运维成本等方面，分析它们之间的主要区别。
考察说明
考查对服务注册中心组件 Eureka 与 Zookeeper 在架构、一致性与可用性取舍上的理解深度。
回答思路
- 【回答框架 1】Eureka 是 Netflix 开源的服务注册与发现组件，采用 AP 设计，优先保证可用性，允许在分区时返回陈旧数据，通过客户端缓存和心跳续约机制实现最终一致。Zookeeper 是分布式协调服务，基于 ZAB 协议提供强一致性，采用 CP 设计，在选主或分区时可能短暂不可用。
- 【回答框架 2】Eureka 采用对等节点复制模式，所有节点平等，任一节点故障不影响整体，客户端可向任意节点注册或拉取服务列表，无主从概念，适合注册中心场景。Zookeeper 依赖 Leader 节点，写入请求必须经 Leader 处理，Follower 只读，Leader 故障时需重新选举，期间服务不可用，对注册中心而言可能导致雪崩风险。
- 【回答框架 3】Eureka 通过心跳续约和自我保护机制应对网络分区，如果短时间内大量实例失联，Eureka 会进入自我保护模式，不剔除疑似故障的实例，以保证可用性。Zookeeper 使用临时节点和会话超时检测实例状态，客户端与服务器断开后，临时节点自动删除，实现服务上下线通知，但依赖会话维持，网络抖动会导致频繁注册与下线。
- 【回答框架 4】在典型微服务场景下，Eureka 更适用于高可用的注册中心，支持区域亲和和缓存，降低对中心的依赖；Zookeeper 更适用于需要强一致性的分布式协调任务，如 leader 选举、分布式锁，但作为注册中心需承受一致性带来的可用性风险。运维上 Eureka 部署简单，Zookeeper 需要关注 znode 数量和集群配置。
- 【关键点 1】Eureka 是 AP 系统，优先可用性，允许最终一致；Zookeeper 是 CP 系统，优先一致性，可能牺牲可用性。
- 【关键点 2】Eureka 无主节点，所有节点平等；Zookeeper 有 Leader 和 Follower 角色，写入依赖 Leader。
- 【关键点 3】Eureka 有自我保护机制，网络分区时不轻易剔除实例；Zookeeper 基于临时节点，会话超时即删除。
- 【关键点 4】选择时若注册中心需高可用，选 Eureka；若需强一致协调能力，选 Zookeeper。
- 【易错点 1】不要把 Eureka 的 AP 特性混同为最终一致性，它通过客户端缓存和心跳实现最终一致，但仍可能有短暂差异。
- 【易错点 2】Zookeeper 的临时节点是会话级别的，网络抖动可能触发大量节点创建与删除，造成不必要开销。
- 【易错点 3】Eureka 的自我保护机制可能掩盖真实故障，运维时需监控服务实际可用性，而非仅依赖服务列表。