InfoQ

Uber Automates Dependency Analysis Across Its Service Mesh

6.9内容质量
Uber Automates Dependency Analysis Across Its Service Mesh

TL;DR · AI 摘要

Uber Automates Dependency Analysis Across Its Service Mesh - InfoQ InfoQ Homepage News Uber Automates Dependency Analysi...

核心要点

  • 主题聚焦：Uber Automates Dependency Analysis Across Its Se
  • 来源：InfoQ，建议结合原文判断细节。
  • AI 分析暂不可用，本条为保底评分与摘要。
#AI#编程#后端#云计算#安全
打开原文

Uber 在其服务网格中自动化依赖分析 - InfoQ

InfoQ 首页新闻 Uber 在其服务网格中自动化依赖分析

架构与设计

QCon 旧金山（11 月 16-20 日）：深入的技术会议。改变你思维方式的同行对话。

Uber 在其服务网格中自动化依赖分析

2026 年 10 月 16 日 2 分钟阅读

作者：

  • Leela Kumili

#### 关注我们

YouTube

232K 粉丝

LinkedIn

26K 粉丝

Instagram

新

RSS

19K 读者

X

57.1k 粉丝

Facebook

21K 赞

Bluesky

收听本文 -

0:00

音频准备播放

您的浏览器不支持音频元素。

正常

1.25x

1.5x

点赞

新下拉阅读列表

  • 阅读列表

Uber 开发了一种自动化方法来映射服务依赖关系，并分类下游故障如何在其服务网格中传播。该系统使用 RPC 中间件来关联生产请求中的调用方和被调用方故障，将依赖关系分类为 fail-close（关闭故障）、fail-open（开启故障）或 unknown（未知）。Uber 表示，这种方法已为关键 API 编制了依赖关系目录，并在其服务网格中对大多数 fail-close 异常进行了索引。Uber 工程团队在 LinkedIn 帖子中强调了这一需求：

当请求失败时，你如何确定真正的原因？在 Uber 的规模下，这会迅速变得复杂。成千上万的服务和依赖关系相互作用，传统的追踪方法无法快速为工程师提供完整的画面。

在微服务架构中，请求可能穿越深度嵌套且异步的服务调用，使得难以确定哪个依赖关系导致了故障。Uber 将 fail-close 依赖定义为一种其故障可以一致导致调用方故障的依赖关系。fail-open 依赖则可能在不导致调用方故障的情况下失败，而证据不足则会导致未知分类。该分类随后可以应用于调用路径，以识别故障可能如何向原始 API 传播。

Uber 最初考虑使用分布式追踪来建立这些关系，但发现采样速度对于罕见故障来说太慢。公司表示，超过 99.9% 的请求都能在可接受的延迟范围内无错误完成。在 0.01% 的采样率和 99.9% 的可用性下，一个错误请求被采样的概率为 1000 万分之一。在每秒 500 个请求的情况下，捕获一个失败请求可能需要 5 小时 33 分 20 秒。

Uber 工程师 Deepanshu Mehndiratta、Alok Srivastava 和 Shivam Jindal 将这种方法描述为在单个请求可见性与更快的依赖分析之间的权衡。

我们需要更快的反馈机制，因此我们开始通过日志来识别依赖关系。

Uber 请求流经 Muttley 代理，显示调用方和被调用方通信及遥测数据（来源：Uber 博客文章）

Uber 通过 Muttley（一种用于路由和遥测的本地代理）路由服务到服务的请求。然而，Muttley 缺乏精确依赖关联所需的调用方端点上下文。Uber 将分析功能添加到 YARPC（其用于 Go 和 Java 的 RPC 框架）中，使用入站和出站中间件。

入站中间件会生成一个请求 ID，并将调用者服务和端点记录在内存中的 RequestTracker 中。该 ID 通过 Go 的 context 传播，使出站中间件能够记录下游服务、端点和调用结果。请求完成时，中间件会发出指标，捕获调用者和被调用者的失败状态。

完整请求流程用于映射入站和出站失败（来源：Uber 博客文章）

Uber 根据观察到的调用者和被调用者结果，为每个调用者依赖项计算失败相关性概率。概率值 ≥0.8 被归类为关闭失败（fail-close），≤0.2 被归类为开放失败（fail-open），中间值则归类为未知。重试处理单独进行，以避免将其视为独立依赖项。与使用 OpenTelemetry 构建的分布式追踪管道不同（尾部采样可根据错误或延迟保留追踪），Uber 使用中间件指标来捕获生产环境中的失败，无需存储和评估单个追踪，以请求级细节换取更广泛的覆盖范围。

作者部分主包装器

关于作者

部分标题

每个作者的主包装器

#### Leela Kumili

显示更多

显示更少

#### 此内容属于依赖管理主题

##### 相关主题：

  • 开发
  • 架构与设计
  • RPC
  • 可观测性
  • 中间件
  • 依赖管理
  • 微服务
  • 服务网格
  • 可靠性
  • 分布式追踪
  • 中间件管理
  • OpenTelemetry
  • 失败
  • 服务可靠性
  • 相关编辑内容
  • 相关赞助商 AI 的物理约束：AI 如何重塑数据中心
  • 相关赞助商 PostgreSQL 专为时间序列规模而生 无需牺牲性能即可使用 PostgreSQL 处理海量时间序列数据。了解 Tiger Data 如何实现高速数据摄入、快速查询和可扩展存储。了解更多。

InfoQ 新闻通讯

每周五汇总 InfoQ 上一周的内容，每周二发送。加入超过 250,000 名高级开发者的社区。查看示例

我们保护您的隐私。