Uber's Failover Architecture: Reconciling Reliability and Efficiency in Hyperscale Microservice Infrastructure

Uber 提出的故障转移架构（UFA）通过根据业务关键性区分服务并引入非关键服务的抢占机制，将稳态资源配比从 2 倍降至 1.3 倍，在消除超过一百万个 CPU 核心的同时，将利用率提升至约 30% 并维持了 99.97% 的高可用性。

要点

这篇论文讲述的是 Uber 如何从“花钱买安心”的粗放模式，转型为“精打细算”的聪明模式的故事。

想象一下，Uber 是一个巨大的全球交通调度中心。为了应对任何可能的灾难（比如某个城市的大停电、服务器机房着火），他们过去一直遵循一个极其保守的原则：“双备份”策略。

1. 过去的困境：为了安全，一半的卡车在睡觉

以前，Uber 的做法是：

• 场景：假设 Uber 有 A 和 B 两个巨大的数据中心（就像两个城市）。
• 旧模式：为了安全，他们规定：无论 A 城发生什么，B 城必须随时准备好接住全世界所有的订单。这意味着，B 城平时只处理自己的一半业务，却必须预留双倍的卡车和司机（服务器资源）来应对 A 城突然瘫痪的情况。
• 结果：这就好比一家餐厅，为了防备隔壁店倒闭，自己雇了两倍的厨师。但隔壁店很少倒闭，所以一半的厨师每天大部分时间都在无所事事地发呆。
• 代价：这种“双倍容量”模式导致 Uber 的服务器利用率极低（只有 20%），浪费了巨额资金（相当于闲置了 100 万个 CPU 核心）。

2. 核心洞察：灾难其实很少见

Uber 的数据团队做了一个调查，发现了一个惊人的事实：

• 真正的“全盛期灾难”（即两个城市同时出问题，或者流量达到历史最高峰时发生灾难）一年平均只发生不到 20 个小时。
• 结论：为了这每年 20 小时的极端情况，让 99.9% 的时间都浪费一半的资源，太不划算了！

3. 新方案：Uber 故障转移架构 (UFA)

于是，Uber 设计了一套新的“聪明”系统，叫 UFA。它的核心思想是：分级管理，动态调配。

比喻：医院急诊室与候诊区

想象 Uber 的服务器是一个超级大医院：

• T0/T1 级服务（Always-On）：这是ICU 里的危重病人（比如叫车匹配、支付）。无论发生什么，他们必须随时有床位，随时有医生。
• T3/T5 级服务（Restore-Later）：这是普通感冒或体检（比如内部工具、测试环境、非核心功能）。

UFA 的运作方式：

1. 平时（稳态）：让“感冒病人”占用“备用 ICU 床位”

   • 以前，ICU 的备用床位是空的，谁也不让坐。
   • 现在，UFA 允许那些“感冒病人”（非核心服务）暂时坐在 ICU 的备用床位上。
   • 好处：平时这些床位不浪费，资源利用率从 20% 提升到了 30%。

2. 灾难发生时（故障转移）：快速腾挪

   • 假设 A 城（主医院）着火了，所有病人要转移到 B 城（备用医院）。
   • 第一步（踢人）：B 城里的“感冒病人”（非核心服务）会被瞬间请出去（暂停服务），把宝贵的 ICU 床位让给“危重病人”（核心服务）。
   • 第二步（扩容）：被请出去的“感冒病人”不会消失，他们会被迅速转移到临时搭建的帐篷（云端弹性资源或批处理集群）里继续治疗。
   • 第三步（恢复）：等 A 城修好了，或者 B 城稳定了，再把这些“感冒病人”从帐篷里接回医院，或者等他们恢复健康。

关键的安全网：如何防止“踢人”导致“危重病人”死亡？

这是最 tricky 的地方。如果“感冒病人”（非核心服务）挂了，会不会把“危重病人”（核心服务）也拖死？

• 以前的情况：如果“挂号处”（非核心）坏了，“急诊医生”（核心）可能会因为等不到挂号信息而停摆。这叫“故障传递”。
• UFA 的解决方案：
  • 切断依赖：Uber 开发了一套自动安检系统（静态分析和运行时检测），在代码上线前就检查：如果“挂号处”挂了，“急诊医生”能不能自己独立工作？
  • 强制“故障开放”：如果“急诊医生”依赖“挂号处”，系统会强制要求医生修改代码，改成“即使没有挂号信息，我也先接诊，事后补单”。
  • 结果：即使把“感冒病人”全踢走，ICU 里的危重病人依然能正常运转，互不干扰。

4. 成果与影响

这套系统上线后，效果立竿见影：

• 省钱：直接砍掉了 100 万个 CPU 核心 的闲置资源（相当于省下了一个中型数据中心的电费和维护费）。
• 高效：服务器利用率从 20% 提升到了 30%。
• 安全：在真实的灾难演练中（比如 2026 年 1 月的一次 17 小时故障转移），核心服务的可用性依然保持在 99.97%，用户几乎感觉不到任何变化。
• 速度：从发现故障到完成资源切换，只需要 8 分钟 就能把备用资源全部激活。

总结

这篇论文讲的是 Uber 如何从一个**“为了安全不惜一切代价”的保守派，转变为一个“在确保安全的前提下，极致利用每一分资源”**的聪明派。

他们不再盲目地购买双倍资源，而是通过精细的分级（把服务分三六九等）、智能的调度（平时混用，战时腾挪）和严格的安检（确保踢掉低优先级服务不会误伤高优先级服务），成功地在可靠性和成本之间找到了完美的平衡点。

这就好比一家餐厅，以前为了防万一，雇了双倍厨师；现在他们发现，只要把“切菜工”（非核心）和“主厨”（核心）的依赖关系理顺，平时让切菜工在主厨的备用灶台上帮忙，一旦主厨灶台着火，立刻把切菜工赶到临时灶台，主厨依然能做出顶级大餐，而且餐厅的运营成本直接减半。

技术摘要

Uber 故障转移架构 (UFA) 技术总结

1. 背景与问题 (Background & Problems)

Uber 作为一个全球性的实时平台，其基础设施长期面临可靠性与成本效率之间的张力。

• 传统架构的局限性：

  • 2x 容量模型：为了应对区域级故障，Uber 长期采用“双区域双活”模式，每个区域都具备处理全球 100% 流量的能力。这意味着在稳态（正常运行）下，一半的计算资源处于闲置状态，导致 CPU 利用率仅为 ~20%。
  • 同质化 SLA：所有服务（从核心业务到内部测试工具）都被分配了相同的故障转移保障级别，造成了不必要的资源浪费。
  • 故障转移频率低：数据分析显示，灾难性的“全峰值”区域故障转移每年平均发生不到 20 小时（仅占全年的 0.23%），大部分预留的故障转移缓冲资源长期闲置。

• 核心挑战：

  1. 低 CPU 利用率：巨大的资源冗余导致成本高昂。
  2. 故障关闭（Fail-Close）依赖：关键服务（Critical Services）往往存在对非关键服务（Non-critical Services）的隐式依赖。当非关键服务在故障转移期间被终止或不可用时，关键服务也会随之崩溃，导致级联故障。
  3. 云弹性限制：在超大规模下（数百万核 CPU），依赖公有云按需扩容无法满足秒级/分钟级的故障转移需求，且受限于云厂商的配额限制。

2. 方法论与架构设计 (Methodology & Architecture)

Uber 提出了 Uber 故障转移架构 (UFA)，旨在通过差异化服务等级协议 (SLA) 和 智能资源超卖 (Intelligent Oversubscription) 来解决上述问题。

2.1 核心设计理念

• 差异化 SLA：不再对所有服务一视同仁，而是根据业务关键性将服务分为不同等级（T0-T5），并定义不同的故障转移行为。
• 智能超卖：在稳态下，非关键服务可以“机会主义”地运行在关键服务预留的故障转移缓冲资源中。
• 故障转移时的分级处理：当发生区域故障时，系统会迅速、有选择性地驱逐低优先级服务，释放资源供关键服务使用。

2.2 服务分类与故障转移行为

UFA 将服务分为四类，对应不同的故障转移策略：

1. Always-On (T0, T1)：
   • 行为：故障转移期间永不被驱逐。
   • 策略：原地扩容，利用预留的故障转移 CPU 缓冲处理 2 倍流量。
   • RTO (恢复时间目标)：秒级，无中断。
2. Active-Migrate (T2)：
   • 行为：保持活跃，但需迁移。
   • 策略：在故障转移区域的新集群（Burst Clusters）中启动新实例，流量切换后终止旧实例（Make-Before-Break）。
   • RTO：秒级，无中断。
3. Restore-Later (T3-T5)：
   • 行为：故障转移期间立即终止。
   • 策略：在故障转移期间被驱逐，随后在 1 小时内通过批量集群或云资源恢复（Break-Before-Make）。
   • RTO：允许高达 1 小时的停机。
4. Terminate (非生产环境)：
   • 行为：立即终止，故障转移期间不恢复，直到故障恢复（Failback）后才重启。

2.3 关键组件与流程

• 故障转移编排 (OMG)：自动检测故障模式（峰值/非峰值），协调服务迁移、流量隔离和容量转换。
• 网络隔离：利用 L7 服务网格和安全覆盖层，在故障转移期间阻断对 Restore-Later 和 Terminate 类服务的流量，防止级联故障和惊群效应。
• 快速重部署 (Up)：
  • 利用 BBM (Break-Before-Make) 和 MBB (Make-Before-Break) 策略。
  • 通过 P2P 镜像预取 技术，将数 TB 的镜像数据预先拉取到故障转移区域，将服务启动时间减少 30%。
• 资源分区与超卖 (Compute)：
  • 将主机 CPU 划分为 stateless.cpu（关键服务）和 overcommit.cpu（可抢占服务）。
  • 利用 Linux Cgroups 实现性能隔离，确保关键服务在资源争抢时不受影响。
  • 通过模拟器确定安全的超卖系数（推荐 1.5 倍）。
• 容量转换：
  • 批量集群转换：故障发生时，迅速驱逐批量作业（Batch Jobs），将批量集群转换为“突发”集群（Burst Clusters）以承载被驱逐的服务。
  • 云突发 (Cloud Bursting)：作为最后手段，在内部容量不足时自动向云厂商申请资源（需预先协商配额）。

3. 安全机制与依赖治理 (Safety & Dependency Management)

UFA 成功的关键在于消除“故障关闭”依赖，确保关键服务在非关键服务不可用时仍能正常工作（Fail-Open）。

• 多层级安全策略：
  1. 运行时依赖分析：监控生产环境中的 RPC 流量，识别当被调用方失败时调用方是否也报错的“故障关闭”模式。
  2. 静态代码分析：在代码提交阶段分析 Go/Java 代码，追踪错误传播路径，提前发现潜在依赖问题。
  3. 金丝雀回归门 (Canary Regression Gate)：在部署到金丝雀区域时，自动模拟切断下游非关键服务，验证关键服务是否仍能正常运行。
  4. AI 驱动的端到端验证：结合 GenAI 移动测试平台与故障注入，模拟真实用户场景下的依赖故障。
• 治理成果：通过上述工具，UFA 项目硬化了 4,000+ 个不安全的依赖关系，消除了跨层级的故障传播风险。

4. 实施与验证 (Implementation & Validation)

• 分阶段发布：历时两年，从非生产环境（Terminate 类）开始，逐步扩展到 T3-T5、T2，最终覆盖 T1。每个阶段都经过严格的“就绪审查”和故障转移演练。
• 大规模演练：进行了 40+ 次生产环境演练和 70+ 次预演，验证了从流量隔离、服务终止、资源扩容到故障恢复的全流程。
• 真实故障案例：2026 年 1 月发生的一次持续 17 小时的真实区域故障转移中，UFA 成功将容量从批量集群转换，并在 8 分钟内完成资源准备，核心业务可用性保持在 99.97%。

5. 关键成果与数据 (Key Results)

• 资源利用率提升：
  • 稳态 CPU 利用率从 ~20% 提升至 ~31% (P99 从 30% 提升至 42%)。
  • 稳态容量需求从 2.0x 降低至 1.3x。
• 成本节约：
  • 在约 400 万核 CPU 的基准上，减少了超过 100 万核 CPU (约 1.025M cores)。
  • 其中约 54% 的节省来自 BBM 策略，46% 来自 MBB 策略。
• 可靠性保障：
  • 在故障转移期间，核心业务（T0/T1）可用性未受任何影响，始终维持在 99.97%。
  • 非关键服务在 1 小时内恢复，符合差异化 SLA 承诺。
• 依赖治理：消除了 4,155 个故障关闭依赖违规，显著降低了系统级联故障的风险。

6. 意义与启示 (Significance & Lessons Learned)

• 打破可靠性与效率的零和博弈：UFA 证明了在超大规模微服务架构中，通过数据驱动的洞察（故障转移极其罕见）和精细化的架构设计，可以在不牺牲关键业务可靠性的前提下，大幅降低基础设施成本。
• 社会技术系统的转型：技术挑战（如依赖治理）只是冰山一角，真正的难点在于协调数百个独立工程团队，改变开发习惯，建立跨层级的安全文化。
• 对云原生架构的启示：
  • 超卖是可行的：在具备严格的安全隔离和依赖治理前提下，资源超卖可以成为常态。
  • 混合云策略：完全依赖公有云按需扩容在超大规模下不可行，必须结合私有资源（批量集群转换）和预协商的云容量。
  • 左移安全 (Shift-Left)：将依赖安全检测集成到 CI/CD 和静态分析中，比事后修复更有效。
• 未来方向：
  • 将差异化 SLA 扩展至有状态服务（数据库、缓存）。
  • 利用生成式 AI 自动修复故障关闭依赖。
  • 推动云厂商提供超大规模下的“保证弹性容量”基础设施。

总结：Uber UFA 不仅是一个技术架构的升级，更是一次成功的组织与工程实践变革。它通过智能的资源调度、严格的依赖治理和自动化的故障演练，将原本闲置的冗余资源转化为生产力，为超大规模分布式系统的成本优化与高可用设计提供了宝贵的范本。