分布式系统中如何避免备胎方案

# Avoiding Fallback in Distributed Systems

作者：Jacob Gabrielson（Amazon Web Services高级工程师）

来源：Amazon Builders' Library（AWS Builder Center）

原文：AWS Builder Center 相关技术文档（英文原文）

背景

分布式系统在现代云计算和微服务架构中广泛应用，任何服务都不可避免地会面临各种故障——从网络瞬时波动到服务依赖链中的下游错误，再到资源耗尽等系统级问题。传统上，工程师倾向于为这些“关键错误”（critical failures）设计恢复策略，包括重试、主动重试、故障转移（failover）和 fallback（回退）。然而，AWS 在长期实践中发现，fallback 策略往往带来更多风险而非可靠保障，尤其在实时响应场景中。它会引入复杂性、潜在的 bug 以及灾难性放大效应，导致整个系统行为从“可预测”转向“混乱”。本文基于 Amazon 内部微服务平台、EC2、ECS 等核心服务的设计经验，系统性分析了 fallback 的问题，并阐述了 AWS 优先采用的替代方法，以确保服务在故障下仍保持一致性和可用性。

核心内容

第一部分：单机应用中的 fallback 问题
在单机应用中，fallback 似乎是合理的处理方式。例如，C 语言中常见的内存分配示例：

pixel_ranges = malloc(image_size);  // 分配内存
if (pixel_ranges == NULL) {
    pixel_ranges = malloc2(image_size);  // fallback 版本
}
for (i = 0; i < image_size; i++) {
    pixel_ranges[i] = xform(original_image[i]);
}

表面上看，fallback 解决了错误。然而，问题在于：

• 难以测试：生产环境中的内存错误多由 OOM（内存耗尽）或资源不足引起，而测试时无法精准模拟（即使在 Docker 中，也难以匹配生产条件）。
• fallback 自身可能失效：malloc2 也可能失败，最终仍导致程序崩溃。
• 放大问题：若 fallback 采用更慢的 SSD 存储，客户可能面临“双倍慢”（应用慢 + 机器慢），同时干扰其他子系统资源。
• 意外负载：简单日志操作若在高频错误触发下，会突然转为 I/O 密集型，导致 CPU 应用崩溃。
• 潜在 bug：fallback 很少在生产中激活，bug 极难发现和修复（可能间隔数月至数年）。Amazon 经验表明，提升主路径可靠性通常比投资 fallback 更有效。

对单机关键应用，AWS 推荐预分配所有堆内存（heap pre-allocation），彻底避免 malloc 依赖。这种“命运共享”（fate-sharing）策略让应用与机器行为一致，出错时整个机器会崩溃，符合期望。

第二部分：分布式系统中的 fallback 问题（更严重）
分布式系统缺少单机应用的“命运共享”属性：服务运行在独立机器上，客户端不直接与服务机器共存，因此预期不同。理论上，fallback 可提升可用性，但实际问题更多：

• 测试难度极高：涉及多机、多服务下游的组合场景，测试空间爆炸式增长。即使模拟单机错误，也无法捕捉分布式触发条件。
• 改善概率而非保证：fallback 仅降低总错误率，而非消除。
• 放大中断范围和恢复时间：经验显示，fallback 会扩大故障影响面，延长恢复周期。
• 不值得风险：若 fallback 本身更可靠，为什么不直接优化主路径？引入 fallback 意味着引入新妥协点。
• 潜在 bug：类似单机场景，激活概率低，bug 埋得深。

真实案例：2001 年左右 Amazon 零售网站出现大规模中断。系统架构为两层：Web 服务器直接查询数据库（因流量大而超载）。开发了缓存层（类似 Memcached），并添加 fallback：若缓存失败，则回退到直接查数据库：

if (cache_healthy) {
    shipping_speed = get_speed_via_cache(sku);
} else {
    shipping_speed = get_speed_from_database(sku);
}

初始阶段运行良好数月。但后来所有缓存同时失效（概率极低），所有 Web 服务器同时直连数据库，导致数据库瞬间过载。整个网站无法加载页面，进而影响全球配送中心。结果：从“仅无法显示物流速度”（局部）变成“网站完全瘫痪”（全局）+ 后端连锁中断。问题在于：

• 测试不充分（无法复现多机同时失效）。
• fallback 放大问题（而非缓解）。
• 逻辑不合理（若数据库更可靠，为什么还用缓存？）。
• 潜在 bug（延迟数月发现）。

这凸显分布式环境下的致命性：fallback 引入的“新模式”在混乱时刻触发，破坏可预测性。

第三部分：AWS 的避坑策略
AWS 几乎不依赖 fallback，优先以下替代路径（直接针对分布式实时服务）：

1. 提升主路径可靠性：通过更高可用数据库（如 DynamoDB）、预缩容等方式强化主逻辑，而非 fallback。例如，Prime Day 期间 DynamoDB 为 Amazon 提供支撑。
2. 让调用方（SDK）处理错误：AWS SDK 已内置重试逻辑，推荐将错误处理下放到调用方，尤其主路径已高度可靠时。
3. 主动发送数据：减少远程调用依赖。例如，IAM 角色凭证在 EC2 启动时主动下发给实例，避免运行时调用失败。
4. 将 fallback 转化为 failover 并持续演练：若必须保留 fallback，转为主动/被动 failover，并定期在生产中随机测试两者（确保两者行为一致、可预测）。
5. 避免重试/超时成为隐形 fallback：监控重试率，避免它们在罕见场景下触发。推荐“主动重试”（hedging/平行请求），尤其读写 Quorum 场景下始终并行请求以维持工作负载。

结论：AWS 避免 fallback 是因为它引入不可预测的“故障模式”、难以测试且在灾难时加剧混乱。相反，持续强化主路径、让系统自然处理错误、主动设计数据流，并对任何必要逻辑保持生产级演练，可实现更可预测的可用性。

关键要点

• 单机 fallback 问题：测试困难、自身可能失效、放大资源争抢、引入意外负载、潜在 bug。
• 分布式 fallback 问题（远甚于单机）：测试复杂度爆炸、放大故障范围、恢复时间延长、不值得风险、长期潜在 bug。
• 典型破坏案例：Amazon 2001 年物流查询网站——缓存 fallback 失效时引发数据库雪崩，导致全局中断。
• AWS 核心策略：提升主路径可靠性；让 SDK/调用方处理错误；主动推送依赖数据；将 fallback 转为可演练的 failover。
• 重试/超时注意事项：监控并警惕它们成为隐形 fallback；采用平行请求（hedging）维持高可用。
• 最终原则：优先“已持续演练、主路径可控”的设计，而非“在失败时兜底”的 fallback。

意义与影响

在分布式系统中，fallback 看似是“稳妥”的保险，但实际往往是隐藏的陷阱。它会制造新的单点故障、破坏系统可预测性，并放大灾难影响（正如 Amazon 案例所示）。AWS 的实践证明，通过舍弃 fallback 并强化主路径、主动架构与演练，可显著提升服务的可靠性和可用性。这对全球云厂商、微服务架构师及 SRE 团队具有普适指导意义：它颠覆了“错误时回退”的直觉，强调“从设计之初就避免依赖”，从而减少长期运维负担和意外中断风险。未来，随着系统规模扩大，此原则将成为构建真正“命运共享”、在故障下仍一致行为的分布式系统的核心规范。