在現代的大規模微服務架構中，理解服務之間的依賴關係至關重要。當系統發生故障時，工程師需要快速得知哪個服務影響了誰，以及流量是如何在成千上萬個實例之間流動。Netflix 為了達成這個目標，開發了一套名為 Service Topology 的即時服務拓撲圖系統。這套系統能將分散在不同層級的數據整合，為工程師提供一個視覺化的服務依賴地圖，用於事故調查、分析故障影響範圍（Blast Radius）、理解依賴關係以及管理生產環境的變更。
為了構建這張地圖，Service Topology 整合了三種不同的數據源：第一是 eBPF 網路流（Network Flows），eBPF 是一種在 Linux 核心中運行高效程式的技術，能無需修改應用程式碼即可監控網路封包；第二是進程間通訊（IPC）指標，記錄應用程式層級的呼叫；第三則是分散式追蹤（Distributed Tracing），用以追蹤單一請求在多個服務間的完整路徑。工程師可以獨立查詢這些層級，也可以將其合併以獲得更全面的視角。
然而，在生產環境的極大規模下，處理這些海量數據面臨著嚴峻的挑戰，尤其是網路流數據的處理管線。原始的網路流紀錄僅顯示網路跳轉（Network Hops），而非邏輯上的應用程式依賴。流量在到達目標服務前，可能會經過負載平衡器、NAT 閘道、API 閘道或代理伺服器等中間設備。如果直接將這些跳轉視為依賴，會導致拓撲圖充斥著大量無意義的中間節點，無法反映真實的業務邏輯。
為了解決這個問題，Netflix 將網路流的攝取路徑重新設計為三個獨立階段。第一階段負責消耗來自多個區域的 Apache Kafka 串流（Kafka 是一種分散式訊息佇列系統），過濾無效紀錄，並將數據按五分鐘窗口進行分批處理以建立初步的聚合器。第二階段則執行中間件解析（Intermediary Resolution），將網路跳轉轉換為直接的應用程式對應用程式邊緣（Edges），並重新分發結果。最後一階段則為節點富集（Enrichment），將服務的健康狀態、所有權和元數據等資訊補全，最後將結果持久化到圖資料庫中。
這種三階段分離的設計解決了先前版本中嚴重的熱點問題。在舊設計中，由於解析中間件需要將相關流量聚集在一起，導致熱門目標服務及其相關中間件的處理壓力過大。某些執行個體承受的流量高達平均值的 100 倍，且同時需要執行高 I/O 的富集工作，造成系統不穩定。透過將解析與富集、持久化分離，Netflix 能更有效地重新分發工作負載，避免單一節點過載。
在系統穩定性方面，Netflix 引入了 Apache Pekko Streams 來管理背壓（Backpressure）。背壓是一種流量控制機制，當下游系統處理速度跟不上上游發送速度時，會向來源端發出信號要求減速。當圖資料庫寫入速度變慢時，壓力會沿著管線向上傳遞，直到 Kafka 消費者暫停讀取。這意味著在極高負載下，系統會選擇延遲數據的即時性，而非直接丟棄紀錄或產生不完整的地圖。對於 Netflix 而言，在事故期間看到稍微延遲但完整地圖，比看到一個即時但殘缺、甚至因丟包而錯誤的地圖要有用得多。
此外，Netflix 在管線階段之間將傳輸協議從 gRPC 替換為伺服器發送事件（Server-Sent Events, SSE）。gRPC 雖然強大，但在處理極高容量的內部傳輸時，序列化開銷、連接池管理以及串流回應產生的記憶體壓力變得過高。SSE 是一種更輕量級的單向推送技術，且與反應式背壓機制相容，能顯著降低傳輸成本。需要注意的是，這僅限於內部管線傳輸，對外提供給客戶端的 API 依然保留 gRPC。
為了應對動態的流量需求，處理集群會根據需求伸縮。每個執行個體從服務註冊表（Service Registry）讀取健康的實例清單，並利用一致性雜湊（Consistent Hashing）決定由哪個執行個體擁有特定的聚合器。當有新實例加入或舊實例離開時，只有受影響的聚合器會遷移到新所有者，無需執行全域的重新平衡過程，極大地提升了擴展效率。
最後，針對事故回溯的需求，Service Topology 並非儲存完整的圖快照或重新播放所有事件日誌，而是保留時間窗口的聚合器快照以及屬性級別的變更歷史。這種設計允許工程師重建特定時間點的拓撲結構，精確分析在事故發生前後，服務依賴關係發生了哪些關鍵變化。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。