作者 | Patrick Farry

譯者 | 張衛(wèi)濱

在最近的 LinkedIn 工程博客文章 中，Bohan Yang 介紹了公司如何升級基于 ZooKeeper 的傳統(tǒng)服務(wù)發(fā)現(xiàn)平臺的項目。面對數(shù)千個微服務(wù)即將達到的容量上限，LinkedIn 需要一個更具擴展性的架構(gòu)。新系統(tǒng)利用 Apache Kafka 處理寫入，使用 xDS 協(xié)議 處理讀取，實現(xiàn)了最終一致性，并允許非 Java 客戶端成為一等公民。為確保穩(wěn)定性，團隊實施了“雙模式（Dual Mode）”策略，支持增量式、零停機遷移。

團隊發(fā)現(xiàn)了基于傳統(tǒng) Apache ZooKeeper 系統(tǒng)的關(guān)鍵擴展性問題。應(yīng)用服務(wù)器的直接寫入以及客戶端的直接讀取 / 監(jiān)聽，意味著大規(guī)模應(yīng)用部署會引發(fā)巨大的寫入峰值和后續(xù)的“讀取風(fēng)暴”，導(dǎo)致高延遲和會話超時。此外，由于 ZooKeeper 強制強一致性（嚴(yán)格順序），讀取請求的積壓可能會阻塞寫入，導(dǎo)致健康節(jié)點無法通過健康檢查。團隊估計，當(dāng)前系統(tǒng)在 2025 年達到了最大容量。

為了解決這些問題，團隊開發(fā)了一種新架構(gòu)，從強一致性模型轉(zhuǎn)向最終一致性模型，提供了更好的性能、可用性和可擴展性。新系統(tǒng)將寫入路徑（通過 Kafka）與讀取路徑（通過 Observer 服務(wù)）分離。服務(wù)發(fā)現(xiàn) Observer 消費 Kafka 事件以更新其內(nèi)存緩存，并通過 xDS 協(xié)議向客戶端推送更新，該協(xié)議與 Envoy 和 gRPC 兼容。采用 xDS 標(biāo)準(zhǔn)使 LinkedIn 能夠部署除 Java 以外的多種語言客戶端。這一技術(shù)決策也為未來與服務(wù)網(wǎng)格（Envoy）和集中式負(fù)載均衡的集成奠定了基礎(chǔ)。

升級后的基準(zhǔn)測試表明，單個 Observer 實例可維持 40,000 個客戶端流，并每秒處理 10,000 次更新。Observer 在每個數(shù)據(jù)中心（fabric）獨立運行，但允許客戶端連接到遠程 Observer 以實現(xiàn)故障轉(zhuǎn)移或跨數(shù)據(jù)中心流量。

遷移過程必須在不中斷每日數(shù)十億次請求且無需數(shù)千名應(yīng)用所有者手動更改的情況下進行。團隊實施了雙讀和雙寫機制。對于讀取，客戶端同時訂閱 ZooKeeper 和新的 Observer。在客戶端系統(tǒng)遷移的試點階段，ZooKeeper 仍然是流量路由的事實來源，而后臺線程在切換流量之前，會根據(jù) ZooKeeper 數(shù)據(jù)驗證 Observer 數(shù)據(jù)的準(zhǔn)確性。對于寫入，應(yīng)用服務(wù)器同時向 ZooKeeper 和 Kafka 聲明其存在。自動化定時任務(wù)會分析 ZooKeeper 監(jiān)聽器，以識別阻礙 ZooKeeper 寫入退役的“長尾” 傳統(tǒng)客戶端。

新服務(wù)實施后，數(shù)據(jù)傳播延遲顯著改善，從 P50 < 10 秒 /P99 < 30 秒降至 P50 < 1 秒 /P99 < 5 秒。該系統(tǒng)現(xiàn)在支持每個數(shù)據(jù)中心數(shù)十萬個應(yīng)用實例，并通過 Observer 層實現(xiàn)水平擴展。

LinkedIn Re-Architects Service Discovery: Replacing Zookeeper with Kafka and xDS at Scale(https://www.infoq.com/news/2026/02/linkedin-service-discovery/)

聲明：本文為 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。