一个服务挂了,到底会连累多少上下游?这个问题在微服务架构里越来越难回答。客户门户依赖API网关,网关依赖认证服务,认证服务又连着数据库——链条一长,靠人脑推演就容易漏。
![]()
开发者VANSH-AGARWAL-collab在Graph Hacks 2026上做了个项目叫OutageLens AI,思路很直接:把服务依赖、事故记录、解决方案放进同一张图里,用图遍历去找可能的故障路径和相关上下文。技术栈是FalkorDB Cloud、Python、FastAPI、React和Cypher。
为什么是图数据库
排查一次服务故障,知道哪个组件出问题只是起点。工程师还得搞清楚:哪些服务依赖它、影响会传多远、类似事故以前有没有留下解决记录。这些问题的共同点是——它们都关于多个实体之间的关系。
FalkorDB用图的方式表示这些连接,用Cypher查询。应用不需要手工重建依赖链,直接在图上遍历关系就能找到相连的服务。在这个项目里,FalkorDB是整个排查流程背后的核心数据层。
依赖链长什么样
演示用的图叫outagelens,里面有一条服务依赖链:客户门户 → API网关 → 认证服务 → 认证数据库。
图里有三种主要关系:
- DEPENDS_ON:把调用方连到它依赖的组件
- AFFECTS:把事故连到受影响的服
- RESOLVED_BY:把事故连到解决方案记录
图里还有一个示例事故INC-1001和关联的解决方案RES-1001。这样服务拓扑和事故信息就连在了一起,而不是各存各的。需要说明的是,演示中的事故和解决方案记录是合成示例,不是从生产系统采集的数据。
向上游追溯靠一行Cypher
OutageLens AI要解决的关键问题之一,是找出直接或间接依赖某个组件的所有服务。以认证服务为目标,演示拓扑里API网关隔一跳,客户门户隔两跳。
变长关系模式可以遍历这些依赖路径:*1..10允许路径包含一到十段关系,返回的depth值表示调用方与目标组件之间隔了几段关系。方向很关键——DEPENDS_ON从调用方指向被依赖方,所以遍历要找的是依赖路径最终落到目标组件上的那些调用方。
这样一来,排查逻辑里不用写死一条固定的服务链,多层依赖都能展开看。
把依赖和事故历史接上
找到相连服务只是画面的一部分。排查真正有用的时候,是它还能把相关的事故和解决方案一起捞出来。第二个查询匹配影响已识别实体的事故,并可选地取回关联的解决方案。OPTIONAL MATCH的作用是:即使某个事故没有挂解决方案,它也会被返回。
两个查询合起来,展示了图遍历如何把服务依赖和相关事故记录连成一条线。后端把结果整理好交给前端,用户在一个流程里就能看到相连的上下文。
三个组件各管一摊
前端用React和Vite,提供仪表盘和图可视化,用来浏览服务和排查结果。后端用Python和FastAPI,暴露API端点把前端接到图数据库上,文档里列出的端点包括/health、/graph和/investigate。FalkorDB Cloud负责存图、执行用于依赖遍历和事故检索的Cypher查询。数据库访问留在后端,前端只负责呈现返回的图和排查结果。
在文档记录的演示场景里,排查认证服务返回两个上游服务:API网关和客户门户,最大上游依赖深度为两跳,结果里包含事故INC-1001和解决方案RES-1001。图端点也会暴露演示拓扑供可视化使用。
这些结果说明的是工作流在一个小型合成图上跑通了。它不能被解读为生产环境故障检测的证据,也不代表调试时间有可测量的缩短,更不是经过验证的根因诊断。
踩过的坑
关系方向是图排查里一个要紧的考虑。依赖边从调用方指向被使用的组件,所以要找上游调用方,就得遍历那些终点落在目标组件上的路径。方向搞反了,结果就全错了。
另一个体会是把拓扑和事故历史接起来的价值。依赖图能显示服务之间怎么关联,而关联的事故和解决方案记录补上了上下文,帮工程师往下查。
项目还强调了一点:基于图的排查和确定的根因分析不是一回事。找到一条依赖路径能指出可能相关的组件,但要确认事故的真正原因,还需要额外证据。
接下来能往哪走
项目列出了几个潜在的改进方向:接入实时遥测,把服务事件和追踪数据纳入进来让图保持更新;用更大的依赖图和更多样的事故场景评估遍历正确性和查询性能;探索基于检索到的图证据生成自然语言解释;引入带校验和人工审批的受控运行手册执行,让修复流程更安全。这些都是未来的开发方向,不是当前演示已经具备的能力。
OutageLens AI探索的是图数据库如何让相连的服务信息更容易排查。把服务依赖、事故和解决方案放进FalkorDB,用Cypher遍历揭示上游关系、取回相关事故上下文,这套流程在一个统一的工作流里跑通了。当前实现用的是合成演示数据,但这个思路可以作为更高级排查工具的起点——接入实时遥测、更大的图、更多证据。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.