Uber自动化识别服务网格三类依赖关系

Uber构建了一套自动化服务依赖关系映射系统，用于分析下游故障如何在服务网格中传播。系统借助RPC中间件关联生产请求中的调用方、被调用方及其故障状态，将依赖划分为fail-close、fail-open和unknown三类。目前，该方案已经完成关键API的依赖编目，并覆盖服务网格中的大多数fail-close异常。

在Uber拥有成千上万项服务、且服务之间存在大量嵌套异步调用的情况下，定位一次请求失败的真正根因并不容易。fail-close表示依赖故障会持续导致调用方失败；fail-open表示依赖即使出错，也不会让调用方失败；当现有证据不足时，则标记为unknown。将这些类别应用到完整调用链后，工程师可以推断故障向源头API传播的路径。

团队曾考虑利用分布式追踪建立依赖关系，但罕见故障的采样效率过低。Uber称，超过99.9%的请求能够无错误并在可接受延迟内完成。按照0.01%的采样率和99.9%的服务可用性计算，一条错误请求被采集到的概率只有千万分之一；如果请求速率为每秒500次，捕获一次失败请求平均可能需要5小时33分20秒。因此，该方案在单次请求的完整可见性与更快、更广泛的依赖分析之间进行了取舍，转而通过日志和指标识别关系。

系统通过Muttley路由服务间请求。Muttley是负责路由和遥测的主机内代理，但无法获得调用方端点上下文，因而难以准确建立依赖关联。为此，Uber将分析能力加入面向Go和Java的YARPC RPC框架，并通过入站和出站中间件实现核心逻辑。入站中间件会生成请求ID，并在内存组件RequestTracker中记录调用方服务及端点；该ID随后借助Go的context对象传播，使出站中间件能够记录下游服务、端点和调用结果。请求结束时，中间件会输出同时反映调用方与被调用方故障状态的指标。

Uber根据观测到的调用方和被调用方结果，计算某项依赖与调用方故障之间的关联概率。概率大于或等于0.8时归为fail-close，小于或等于0.2时归为fail-open，介于两者之间则标记为unknown。重试请求会单独处理，避免被错误视为独立依赖。与基于OpenTelemetry的分布式追踪管道不同，后者可通过尾部采样保留错误或高延迟追踪，Uber的方案直接利用中间件指标捕获生产故障，不必存储和评估每条追踪数据，以牺牲部分请求级细节换取更高覆盖率。