InfoQ
·
LinkedIn重新架构服务发现：在大规模环境中用Kafka和xDS替代Zookeeper
内容提要
LinkedIn升级了基于ZooKeeper的服务发现平台，采用Apache Kafka和xDS协议，实现可扩展架构。新系统支持最终一致性，允许非Java客户端参与。通过“双模式”策略，团队实现了零停机迁移，解决了ZooKeeper的性能瓶颈，显著提升了数据传播速度和系统可扩展性。
关键要点
-
LinkedIn升级了基于ZooKeeper的服务发现平台，以应对微服务数量激增带来的可扩展性需求。
-
新系统采用Apache Kafka进行写入，使用xDS协议进行读取，实现最终一致性，支持非Java客户端。
-
团队实施了“双模式”策略，实现零停机迁移，确保系统稳定性。
-
旧系统存在性能瓶颈，强一致性导致高延迟和会话超时，预计在2025年达到最大容量。
-
新架构从强一致性转向最终一致性，分离写入路径和读取路径，提升性能和可用性。
-
服务发现观察者通过Kafka事件更新内存缓存，并通过xDS协议推送更新，支持多种编程语言的客户端。
-
升级后，单个观察者实例可维护4万客户端流，每秒处理1万次更新。
-
迁移过程中未中断每日数十亿请求，实施了双重读取和写入机制。
-
数据传播延迟显著改善，系统现在支持每个数据中心数十万应用实例，具备水平扩展能力。
延伸解读
架构升级的必要性
LinkedIn面临着微服务数量激增的挑战，旧有的ZooKeeper架构在性能和可扩展性上存在瓶颈。通过升级到基于Kafka和xDS的新架构，LinkedIn不仅解决了即将达到的容量限制，还提升了系统的整体性能和可用性。这一转变反映了现代企业在技术架构上必须不断适应变化的需求。
双模式迁移策略的优势
LinkedIn在迁移过程中采用了“双模式”策略，确保了零停机迁移。这种策略允许新旧系统并行运行，降低了迁移风险，确保了数十亿请求的连续处理。这一方法为其他企业在进行系统升级时提供了宝贵的经验，尤其是在需要高可用性的场景中。
最终一致性的影响
新架构从强一致性转向最终一致性，显著提升了数据传播速度和系统响应能力。这种变化使得系统能够更好地处理高并发请求，减少了延迟，适应了现代应用的需求。企业在设计服务发现系统时，需考虑一致性模型对性能的影响，以实现更高的可扩展性。
延伸问答
LinkedIn为什么要升级其服务发现平台？
LinkedIn升级服务发现平台是为了应对微服务数量激增带来的可扩展性需求，解决旧系统的性能瓶颈。
新系统是如何实现最终一致性的？
新系统通过使用Apache Kafka进行写入和xDS协议进行读取，实现了最终一致性，支持非Java客户端。
LinkedIn在迁移过程中如何确保零停机？
团队实施了“双模式”策略，允许同时使用ZooKeeper和新Observer进行读写，确保迁移过程中不影响日常请求。
新架构相比旧系统有哪些性能提升？
新架构将强一致性转向最终一致性，显著降低了数据传播延迟，支持每个数据中心数十万应用实例。
单个观察者实例的处理能力如何？
单个观察者实例可以维护4万客户端流，每秒处理1万次更新。
新系统如何支持多种编程语言的客户端？
新系统通过xDS协议的使用，使得LinkedIn能够部署多种编程语言的客户端，超越了Java的限制。
