在最近的 LinkedIn 工程博客文章 中，Bohan Yang 介绍了公司如何升级基于 ZooKeeper 的传统服务发现平台的项目。面对数千个微服务即将达到的容量上限，LinkedIn 需要一个更具扩展性的架构。新系统利用 Apache Kafka 处理写入，使用 xDS 协议 处理读取，实现了最终一致性，并允许非 Java 客户端成为一等公民。为确保稳定性，团队实施了“双模式（Dual Mode）”策略，支持增量式、零停机迁移。
团队发现了基于传统 Apache ZooKeeper 系统的关键扩展性问题。应用服务器的直接写入以及客户端的直接读取 / 监听，意味着大规模应用部署会引发巨大的写入峰值和后续的“读取风暴”，导致高延迟和会话超时。此外，由于 ZooKeeper 强制强一致性（严格顺序），读取请求的积压可能会阻塞写入，导致健康节点无法通过健康检查。团队估计，当前系统在 2025 年达到了最大容量。
为了解决这些问题，团队开发了一种新架构，从强一致性模型转向最终一致性模型，提供了更好的性能、可用性和可扩展性。新系统将写入路径（通过 Kafka）与读取路径（通过 Observer 服务）分离。服务发现 Observer 消费 Kafka 事件以更新其内存缓存，并通过 xDS 协议向客户端推送更新，该协议与 Envoy 和 gRPC 兼容。采用 xDS 标准使 LinkedIn 能够部署除 Java 以外的多种语言客户端。这一技术决策也为未来与服务网格（Envoy）和集中式负载均衡的集成奠定了基础。
升级后的基准测试表明，单个 Observer 实例可维持 40,000 个客户端流，并每秒处理 10,000 次更新。Observer 在每个数据中心（fabric）独立运行，但允许客户端连接到远程 Observer 以实现故障转移或跨数据中心流量。
迁移过程必须在不中断每日数十亿次请求且无需数千名应用所有者手动更改的情况下进行。团队实施了双读和双写机制。对于读取，客户端同时订阅 ZooKeeper 和新的 Observer。在客户端系统迁移的试点阶段，ZooKeeper 仍然是流量路由的事实来源，而后台线程在切换流量之前，会根据 ZooKeeper 数据验证 Observer 数据的准确性。对于写入，应用服务器同时向 ZooKeeper 和 Kafka 声明其存在。自动化定时任务会分析 ZooKeeper 监听器，以识别阻碍 ZooKeeper 写入退役的“长尾” 传统客户端。
新服务实施后，数据传播延迟显著改善，从 P50 < 10 秒 /P99 < 30 秒降至 P50 < 1 秒 /P99 < 5 秒。该系统现在支持每个数据中心数十万个应用实例，并通过 Observer 层实现水平扩展。
原文链接：
LinkedIn Re-Architects Service Discovery: Replacing Zookeeper with Kafka and xDS at Scale(https://www.infoq.com/news/2026/02/linkedin-service-discovery/)
