内容提要
LinkedIn升级了基于ZooKeeper的服务发现平台，采用Apache Kafka和xDS协议，实现可扩展架构。新系统支持最终一致性，允许非Java客户端参与。通过“双模式”策略，团队实现了零停机迁移，解决了ZooKeeper的性能瓶颈，显著提升了数据传播速度和系统可扩展性。
关键要点
-
LinkedIn升级了基于ZooKeeper的服务发现平台，以应对微服务数量激增带来的可扩展性需求。
-
新系统采用Apache Kafka进行写入，使用xDS协议进行读取，实现最终一致性，支持非Java客户端。
-
团队实施了“双模式”策略，实现零停机迁移，确保系统稳定性。
-
旧系统存在性能瓶颈，强一致性导致高延迟和会话超时，预计在2025年达到最大容量。
-
新架构从强一致性转向最终一致性，分离写入路径和读取路径，提升性能和可用性。
-
服务发现观察者通过Kafka事件更新内存缓存，并通过xDS协议推送更新，支持多种编程语言的客户端。
-
升级后，单个观察者实例可维护4万客户端流，每秒处理1万次更新。
-
迁移过程中未中断每日数十亿请求，实施了双重读取和写入机制。
-
数据传播延迟显著改善，系统现在支持每个数据中心数十万应用实例，具备水平扩展能力。
延伸问答
LinkedIn为什么要升级其服务发现平台？
LinkedIn升级服务发现平台是为了应对微服务数量激增带来的可扩展性需求，解决旧系统的性能瓶颈。
新系统是如何实现最终一致性的？
新系统通过使用Apache Kafka进行写入和xDS协议进行读取，实现了最终一致性，支持非Java客户端。
LinkedIn在迁移过程中如何确保零停机？
团队实施了“双模式”策略，允许同时使用ZooKeeper和新Observer进行读写，确保迁移过程中不影响日常请求。
新架构相比旧系统有哪些性能提升？
新架构将强一致性转向最终一致性，显著降低了数据传播延迟，支持每个数据中心数十万应用实例。
单个观察者实例的处理能力如何？
单个观察者实例可以维护4万客户端流，每秒处理1万次更新。
新系统如何支持多种编程语言的客户端？
新系统通过xDS协议的使用，使得LinkedIn能够部署多种编程语言的客户端，超越了Java的限制。
