ZooDemo：Spring Cloud ZooKeeper 服务治理

项目背景

ZooDemo 是一个演示 ZooKeeper 作为服务注册中心的 Spring Cloud 项目。虽然现在 Nacos 功能更全面，但很多遗留系统（特别是 Hadoop 生态周边）仍然使用 ZooKeeper。理解 ZooKeeper 的服务治理机制，对维护老系统和理解分布式协调原理都有帮助。

服务注册与发现流程

服务启动 → 向 ZooKeeper 注册临时节点 → 消费者获取节点列表 → 负载均衡调用 → 健康检查摘除异常节点

注册原理

每个服务实例在 ZooKeeper 中创建一个临时顺序节点：

/services/
├── user-service/
│   ├── 0000000001 (临时节点: 192.168.1.1:8080)
│   └── 0000000002 (临时节点: 192.168.1.2:8080)
└── order-service/
    └── 0000000001 (临时节点: 192.168.1.1:8081)

关键：使用临时节点（EPHEMERAL） 而不是持久节点。当服务宕机导致 ZooKeeper 会话超时，临时节点自动删除，消费者立即感知。

服务发现

spring:
  cloud:
    zookeeper:
      connect-string: 192.168.8.133:2181
      discovery:
        enabled: true

消费者通过 Spring Cloud 的 DiscoveryClient 获取服务实例列表，Ribbon 做负载均衡。

ZooKeeper vs Nacos

虽然都是注册中心，但设计理念不同：

对比维度	ZooKeeper	Nacos
一致性协议	ZAB（强一致）	Distro（最终一致）+ Raft
健康检查	客户端心跳 + 会话超时	主动心跳探测
配置管理	需要自己实现 Watcher	内置配置中心
运维成本	安装配置较复杂	Web 控制台 + 命名空间
适用场景	分布式协调、选举	服务治理

选型建议：新项目优先 Nacos，运维更友好，功能更全面。但如果项目中已经用了 ZooKeeper（如 Kafka、HBase 等依赖的场景），用 ZooKeeper 做注册中心可以减少维护组件的数量。

服务治理核心三要素

无论用哪种注册中心，核心能力不变：

1. 注册：服务启动时告诉注册中心自己的地址
2. 发现：消费者从注册中心获取可用服务列表
3. 健康检查：注册中心定期检查服务是否存活，异常节点自动摘除

在这个基础上，高级特性包括：权重路由（给高配机器更高权重）、保护阈值（健康率低于阈值时不过滤）、标签路由（灰度发布）。

踩坑

ZooKeeper 连接超时：服务启动时 ZooKeeper 连接慢导致启动失败。增加超时时间和重试次数可以缓解。

临时节点延迟：服务宕机后 ZooKeeper 会话有超时时间（默认 40 秒），这 40 秒内消费者可能调用到已宕机的服务。调小 tickTime 可以减少这个窗口，但会加重 ZooKeeper 负载。

服务列表缓存：消费者会缓存服务列表，ZK Watcher 通知有延迟，极端情况下调用会失败。结合断路器（Hystrix/Sentinel）做降级。