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