Netflix分享了有关 Service Topology 的细节。该内部系统为数千个微服务创建并维护一个实时依赖关系图，帮助工程师了解服务如何互相连接并更快地解决问题。系统将三类独立数据源合并到一个可查询的图中，并会在流量模式发生变化时实现近实时的更新。
开发该系统的动机来自于过去四年中在工程支持请求中反复出现的模式。调试分布式系统的工程师经常面对相同的问题，那就是他们需要知道哪些服务是相互依赖的，他们会询问某次变更或故障的影响范围（blast radius），以及判断问题是发生在本地还是来自上游依赖。现有的可观测性工具、指标、日志和追踪各自只捕捉了部分信息，但没有提供运行时服务连接的统一视图。
系统从三类来源摄取数据，每类数据保存在独立的图分区中。基于 eBPF 的网络流量日志在内核层捕获数据，即使服务没有做插桩也能获得完整的视图，但缺少应用层上下文信息（例如，被调用的是哪个 API 端点）。由已加入插桩的服务发出的 IPC 指标能够提供端点和协议级别的细节信息，但仅限于那些主动上报的服务。汇总的分布式追踪能揭示真实的请求路径（含条件分支），但受到采样的限制。每一层都弥补了其它层的不足，查询可以只针对某一层，也可以并行合并三层数据进行分析。
为了解决原始网络流量数据的关键问题，系统采用了一个三阶段的聚合流水线。日志会记录通过负载均衡器和 NAT 网关等中间服务的每一跳，但它们并不能直接展示工程师需要的应用到应用的直接连接。第二阶段执行中间服务的解析，将多跳路径折叠为直接的边。分级的方法分摊了负载，也有助于在某些中间服务流量过大时防止出现热点。
Netflix 方法：三类事实来源
流水线处理是在跨区域的 Kafka 消费者上使用Apache Pekko Streams 来运行的。图存储构建在 Netflix 内部的分布式键值系统之上，并采用专为快速遍历而设计的图数据库层。通过 gRPC API 暴露拓扑，支持多跳查询、按可用性等级和业务域过滤，并将亚秒级（sub-second）响应时间作为硬性要求。
历史查询使用时间窗口聚合而不是保留独立的快照，这样可以在不产生高存储成本的情况下查看过去某一时间点的拓扑。团队认为这对将依赖关系变化与事件发生时间进行关联非常有帮助。
团队指出，一些设计决策来自早期失败尝试的教训。在每天部署多次的环境中，静态或有延迟的依赖映射证明毫无用处。能在小规模下工作的解决方案在 Netflix 的服务数量和流量规模面前会遇到瓶颈。而不完整或不正确的依赖数据反而比没有数据更糟，因为它会在事故中误导工程师得出错误结论。
未来的工作将包括把部署事件和配置变更事件加入拓扑图。从长远来看，团队希望用该图作为自动化根因分析的基础。
Netflix 的这篇文章发布在一个公开工程写作相对稀少的领域。近期，大多数关于服务依赖映射的公开工作，要么止步于 OpenTelemetry 的 Service Graph Connector 能从追踪中推导出的内容，要么把依赖图视为其他事情的基础设施支持，例如，Cloudflare 的 AI 智能体上下文或 Stripe 的指标迁移项目。
至今还没有其他团队以相同深度公开分享如何在这样的规模下构建一个多源、存储于图数据库、近实时的拓扑系统。这要么是因为在 Netflix 这样的服务数量面前该问题确实罕见，要么是因为解决了该问题的团队将其视为竞争优势而将方案保留为内部资料。
查看英文原文：How Netflix Maps Thousands of Microservices in Real-Time
