不是所有服务都值得“双活”：Uber容灾架构的降本哲学
内容提要
Uber为应对年均不足20小时的全区域故障，长期按2倍容量冗余部署，CPU利用率仅约20%。其NSDI'26论文提出UFA架构，按T0～T5业务等级将服务分为Always-On、Active-Migrate、Restore-Later、Terminate四类，低优先级服务日常寄居在容灾缓冲资源中，故障时被安全牺牲。前提是清除核心服务对非核心服务的fail-close依赖，Uber通过运行时分析、静态代码分析和Canary门禁共发现4155个违规依赖。11个月内减少102.5万CPU核，利用率升至31%，核心业务可用率保持99.97%以上。
延伸解读
容灾成本的关键在故障概率而非峰值
Uber的改造依据来自四年故障数据：真正需要全量2倍容量的full-peak故障年均不足20小时，仅占0.23%。这意味着长期按峰值配置资源，等于为极小概率事件支付全年闲置成本。对大规模集群而言，先量化故障时长与影响范围，再决定冗余等级，比默认双活更可能找到成本与可靠性的平衡点。
分级容灾的前提是清除跨层fail-close依赖
UFA允许牺牲低优先级服务，但核心服务若对非核心服务存在fail-close依赖，牺牲就会反噬核心业务。Uber通过运行时分析、静态代码分析和Canary断网门禁，共发现4155个违规依赖。这说明分级容灾不是单纯调整资源池，而是要先系统性地把关键服务改造成fail-open，否则超卖会放大故障面。
超卖系数需要仿真与安全余量
Uber将物理机CPU划分为正常池和超卖池，并用仿真器确定1.5倍超卖系数，低于公式算出的1.66倍理论上限，为系统组件和突发流量留出缓冲。这提示超卖不能只看平均利用率，还要结合内存配比、安全分配系数和故障时的回收速度，否则节省的资源可能以恢复时间为代价。
组织协作比单点技术更难复制
论文坦承依赖分析、容器超卖、故障编排并非全新概念，真正难点是在6000多个微服务、数百个团队间推行分级容灾。Uber为此设立约50人的中心化平台团队，用两年逐层推进并取得利益相关方签字。对其他团队而言，技术方案可借鉴，但跨团队依赖治理和变更协调才是落地成本的主要部分。
Q&A
Uber 为什么决定改造原有的双活容灾架构？
Uber 分析过去四年故障数据发现，真正需要全量 2 倍容量接管的 full-peak 故障平均每年不到 20 小时，仅占全年 0.23%。但为应对这种极端情况，整个机队长期按 2 倍容量冗余部署，导致 CPU 利用率常年只有约 20%，大量资源闲置。这个反直觉的数据成为架构改造的立项依据。
UFA 架构如何对服务进行分级和故障响应分类？
UFA 按业务重要性将服务分为 T0～T5 共 7 个等级，并对应四种故障响应类型：T0/T1 核心服务为 Always-On，原地扩容不被抢占；T2 为 Active-Migrate，提前在别处拉起再切走；T3～T5 为 Restore-Later，立即停机稍后恢复；非生产环境为 Terminate，立即停机不恢复。低优先级服务日常寄居在容灾缓冲资源中，故障时被安全牺牲。
UFA 实施中最大的技术障碍是什么？如何解决？
最大障碍是核心服务对非核心服务的 fail-close 依赖：低优先级服务被牺牲时，核心服务会跟着挂掉。Uber 通过三层安全网系统性清理这些依赖：运行时依赖分析（每天分析数万亿次 RPC）、静态代码分析（扫描 Go/Java 调用链）、Canary 环境自动回归门禁（5 分钟断网测试），共发现 4155 个违规依赖，使核心服务具备 fail-open 能力。
UFA 在资源超卖方面具体是怎么做的？
Uber 在 Kubernetes 层面将每台物理机 CPU 切分为 stateless.cpu（留给 Always-On）和 overcommit.cpu（留给可被抢占负载）两个资源池。例如 100 核物理机对外宣称 150 个可调度核心，其中 50 个进入超卖池。团队通过仿真器确定安全超卖系数为 1.5 倍，理论上限公式算出 1.66 倍，留出余量给系统组件和突发流量。
UFA 改造后取得了哪些实际效果？
在 11 个月滚动部署周期内，Uber 累计减少 102.5 万个 CPU 核心，全局 CPU 利用率从平均 20%（P99 30%）提升到 31%（P99 42%）。核心业务可用率始终维持在 99.97% 以上，即便在一次真实发生的 17 小时区域故障中也没有下降。故障期间 8 分钟内就绪突发容量，承接流量的 Region 峰值 CPU 利用率达 50.2% 但仍在安全阈值内。
Uber 从 UFA 项目中总结了哪些经验教训？
Uber 总结了几点：全球规模问题比预想复杂，分区域灰度时发现机场周边司机响应变慢等预发环境无法模拟的问题；主动故障切换可防灰色故障，检测到异常苗头就主动切换而非等宕机；如果重来，会提前与批处理业务方协调而非一刀切驱逐任务，并更早投入梳理服务间依赖图。此外，跨团队协作是最大难点，专门成立约 50 人团队花两年逐层推进。
