Netflix 技术博客服务拓扑系列的第二篇，讲怎么做而不是做了什么：为了实时服务依赖地图，他们用流式优先架构替掉批处理，靠反应式流背压扛住每秒百万级流记录，用三级分布式聚合管线解决网络中间件解析和热点节点两个看似无关的问题，并实现了拓扑的时间旅行查询。全文最有价值的不是架构图，而是 V1 上生产后连环暴露的九个瓶颈，以及一条贯穿始终的方法论：测量驱动，一次只修一个瓶颈，规模会定性改变一切结论。

读 Netflix 技术博客《From Silos to Service Topology》的工程向笔记：Netflix 分析了四年的工程师求助记录，发现最高频的问题全是依赖问题（上下游是谁、爆炸半径多大、故障源在哪），于是用三路互补的数据源（eBPF 网络流、IPC 指标、分布式追踪）各自建图、物理隔离、并行查询后合并，再经 Kafka + Pekko Streams 三级聚合管线实时入库，最终对外暴露亚秒级查询的 gRPC API 和可视化界面；核心启示是「单一数据源永远讲不全依赖关系」和「小时级陈旧的拓扑图是考古不是可观测性」。