LinkedIn重构服务发现：在大规模环境中用Kafka和xDS取代Zookeeper

在最近的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