Netflix 在一篇技术博客中详细介绍了如何重新设计驱动 Service Topology 的流式处理管道，以支撑其生产规模。新系统采用三阶段结构，将中间解析与数据丰富、持久化分离，并把回压传播回 Kafka 而非丢弃记录，同时用服务器发送事件（SSE）取代内部传输中的 gRPC。
Service Topology 是 Netflix 的多源服务依赖图——它将来自 eBPF 网络流、IPC 指标和分布式追踪的独立存储视图结合到一起。工程师可以独立查询各层，也可以合并以获得更全面的服务依赖视图。Netflix 用它做事故调查、影响范围分析、依赖关系理解和生产变更管理。
但原始流记录反映的是网络跳转（hop），而非逻辑上的应用依赖——流量可能经过负载均衡、NAT 网关、API 网关或代理。要把「跳转」翻译成「应用到应用的边」，需要一套能扛住生产规模的处理管道。
这正是这篇文章的锚点。热门目标 + 中间跳转导致实例变成「热点」，某些实例 I/O 密集数据丰富操作流量可达典型值 100 倍。
解析与丰富/持久化分离，负载可重新分配；回压反传 Kafka，高负载下延迟新鲜度而非丢数据。
对比视角：架构升级的核心不是换语言或换框架，而是重新划分责任边界与压力传导路径。
第一阶段消费多区域 Kafka 流，过滤无效记录，按五分钟窗口批处理，创建初始聚合器。第二阶段将中间跳转解析为直接的应用到应用边，重新分发结果。最后阶段在持久化到图数据库之前，为节点添加健康、归属和元数据。
为什么解析要单独拆一层？因为中间解析需要将相关流汇聚在一起，热门目标及其中间跳转容易让实例变成「热点」。将解析与丰富/持久化分离，系统才能重新分配这些负载。
三阶段拆分的本质：把「重计算」（解析）与「重 I/O」（丰富 + 写入）隔离，避免互相拖累。
管道使用 Apache Pekko Streams 管理回压。当图存储跟不上节奏时，压力沿处理阶段向上游传播，直到 Kafka 消费者暂停，记录保留在 Kafka 中等待容量恢复。
Netflix 认为这比在事故期间生成已过时的批量地图更可取——高负载下出现的是新鲜度延迟，而不是数据丢失或不完整的地图。
另一个关键替换：管道阶段之间的 gRPC 改为服务器发送事件（SSE）。在 Netflix 的规模下，序列化、连接池管理和流式响应的内存压力代价很高，SSE 更轻量且兼容反应式回压。
一个诚实的注脚：内部传输与暴露给 Service Topology 客户的 gRPC API 是分离的——外部接口不变，内部工程细节自由演进。
Netflix 的 Service Topology 本质上是实时依赖关系分析系统——这恰恰是大模型训练与推理服务中越来越关键的能力。
当 AI 服务依赖复杂的数据管道、多级缓存与异构算力池时，三阶段解析 + 回压反传的设计直接适用于：
「压力向上游传播、记录保留在 Kafka 等待恢复」的策略，对 AI 场景中的训练数据管道尤其有借鉴意义——宁可延迟，不可丢样本。
Netflix 的管道升级揭示了一个 AI 基础设施界的规律：当依赖关系成为系统本身的一等公民，架构设计就必须把「重计算」与「重 I/O」拆开、把压力传导路径显式化——这套方法论正在从流处理社区向 AI Infra 迁移。