在微服務架構中，當服務數量達到數千個且部署頻率極高時，工程師最頭痛的往往不是單一服務的 Bug，而是服務之間的依賴關係。當系統發生故障時，我們通常需要快速回答三個核心問題：誰在呼叫我？如果我掛了會影響誰（爆炸半徑 Blast Radius）？問題是出在我這裡，還是上游傳下來的？
傳統的觀測工具如日誌、指標或分佈式追蹤雖然能提供部分資訊，但缺乏一個統一且即時的全局視角。為了滿足這個需求，Netflix 開發了 Service Topology 系統，旨在建立一個能即時更新且可查詢的動態依賴圖。
多源數據融合解決資訊盲區
單一的數據來源往往存在缺陷，Netflix 採取了三路數據融合的策略，利用不同層級的數據來互補缺失。
第一路是 eBPF 網路流日誌。eBPF 是一種在 Linux 核心層級運行程式的技術，它能直接監控網路封包。其優勢在於全面性，即使服務沒有安裝任何監控插件，也能被捕捉到。但缺點是缺乏應用層上下文，它只知道 IP 之間有流量，不知道呼叫的是哪個 API 接口。
第二路是 IPC 指標。這是由服務主動發出的內部行程間通訊數據。它能提供具體的端點名稱和協議細節，但限制在於只有被正確配置監控的服務才會發送數據。
第三路是分佈式追蹤。透過追蹤單次請求的完整路徑，可以看清實際的呼叫分支。然而，由於追蹤數據量龐大，通常會採取採樣（Sampling）機制，這意味著它無法捕捉到所有低頻率的呼叫路徑。
透過將這三者合併，Netflix 能在確保覆蓋率的同時，兼顧詳細的 API 上下文與實際的請求路徑。
處理網路中間件的雜訊
在實際的雲端環境中，服務 A 呼叫服務 B 之間通常會經過負載均衡器（Load Balancer）或 NAT 閘道。如果直接記錄網路流，圖表會充斥著大量的中間件節點，導致工程師無法直觀地看到應用程式之間的直接關係。
Netflix 建立了一個三階段的聚合管線，其中關鍵的一步是中間件解析（Intermediary Resolution）。系統會將多跳的路徑（例如 A 到 LB 到 B）壓縮成一條直接的邊（A 到 B）。這種漸進式處理方式能有效分散計算壓力，避免單一高流量的中間件節點變成系統處理的效能瓶頸。
系統架構與實務考量
在底層實作上，該系統使用 Apache Pekko Streams 處理跨區域的 Kafka 數據流，並將結果儲存在自研的分佈式鍵值儲存系統中，上方疊加一層專為快速遍歷設計的圖資料庫層。
為了確保在事故處理時能快速反應，系統對 gRPC API 的回應時間要求在亞秒級（Sub-second）。此外，對於歷史查詢，他們並非儲存大量的快照，而是採用時間視窗聚合（Time-window Aggregation），讓工程師能對比故障發生前後的拓撲變化，而不需要承受極高的儲存成本。
從失敗經驗中學習
Netflix 指出，這個系統的設計是經過多次嘗試後才定型的。他們發現三件事：首先，靜態或延遲較高的依賴圖在每日多次部署的環境中完全沒用；其次，在小規模環境可行的方案，在數千個服務的量級下會直接崩潰；最重要的一點是，錯誤或不完整的依賴數據比沒有數據更危險，因為它會誤導工程師在壓力巨大的故障排除過程中做出錯誤判斷。
未來方向
目前該系統主要解決的是可視化與查詢問題。未來的演進方向將是將部署事件與配置變更整合進拓撲圖中，最終目標是將此圖作為自動化根因分析（Automated Root Cause Analysis）的基礎，讓系統能自動推論出故障的源頭。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。