在一家互联网公司里，订单系统要调用库存系统，用户系统又要通知消息系统发短信。这些系统都是独立运行的ref="/tag/414/" style="color:#E3A3CF;font-weight:bold;">服务，今天可能在10.1.1.10这台机器上，明天因为扩容又跑到了10.1.1.20。那它们怎么知道对方现在在哪？这时候就得靠服务发现了。
Zookeeper 是怎么帮上忙的？
Zookeeper 本是个分布式协调工具，像一个高可用的小型文件系统，但它特别适合做服务发现。每个服务启动时，都会在 Zookeeper 的指定路径下创建一个临时节点，比如 /services/order-service/10.1.1.10:8080。这个“临时”很关键——一旦服务挂了，连接断开，节点自动消失，其他服务就不会再往这个地址发请求。
调用方呢？它会监听这个路径下的子节点变化。一旦有新增或删除，Zookeeper 会立刻通知它，相当于告诉它：“兄弟，服务列表更新了，赶紧刷新一下。”这样整个系统就能动态感知服务的位置变化。
实际代码长什么样？
用 Java 写个简单例子，注册一个服务到 Zookeeper：
CuratorFramework client = CuratorFrameworkFactory.newClient("127.0.0.1:2181", new ExponentialBackoffRetry(1000, 3));
client.start();
String servicePath = "/services/user-service";
String instancePath = servicePath + "/" + "10.1.1.15:9000";
client.create().creatingParentsIfNeeded().withMode(CreateMode.EPHEMERAL).forPath(instancePath);上面这段代码的意思是：连上 Zookeeper，创建一个临时节点，表示当前这个用户服务实例正在运行。如果进程崩溃，节点自动被删。
再看消费者如何获取可用服务列表：
List<String> instances = client.getChildren().forPath(servicePath);
for (String instance : instances) {
System.out.println("发现实例：" + instance);
}
// 同时可以监听变化
client.getChildren().usingWatcher(watcher).forPath(servicePath);这样一来，哪怕服务频繁上下线，调用方也能及时掌握最新情况，避免把请求发到已经宕机的机器上。
为什么选 Zookeeper 而不是别的方式？
有人用配置文件写死地址，改一次就得重启所有相关服务；也有人用数据库存服务列表，但查数据库有延迟，还多了一层依赖。Zookeeper 的优势在于高可用、强一致，而且变更通知几乎是实时的。
当然它也不是万能的。运维得跟上，Zookeeper 集群本身不能挂；另外对小项目来说，引入 Zookeeper 可能有点重。但如果系统规模上来，服务越来越多，这套机制就显得非常必要。
就像公司大了要有员工通讯录，还得是能自动同步的那种。Zookeeper 就是微服务体系里的那本活通讯录，谁来了谁走，一清二楚。