Fallback Pattern

在微服务架构中，服务形成分布式网络调用的网络。虽然这允许团队独立构建和扩展服务，但这也意味着系统的整体可靠性取决于其最薄弱的环节。如果关键服务出现故障或变得无响应，则可能会触发级联故障，从而中断整个应用程序。 当单个依赖项失败时，向用户返回通用的“500 内部服务器错误”或空白页面是一种糟糕的用户体验。相反，弹性系统是为了在出现问题时优雅地降级而构建的。 这就是 后备模式 的用武之地。通过在主服务调用失败时定义安全的替代执行路径，您可以保持应用程序正常运行 - 即使在降级状态下也是如此。 在本指南中，我们将探讨回退模式、实现它的常见策略、它如何与其他弹性模式交互，以及如何用 Java (Resilience4j) 和 Go 编写回退逻辑。 现实世界的类比：咖啡店后备计划 想象一下您走进当地一家咖啡店买一杯拿铁咖啡。咖啡师输入您的订单，但当您刷卡时，支付终端会显示连接错误 - 商店的互联网提供商遇到中断。 咖啡店是否立即关灯、锁门并送所有顾客回家？ 当然不是。他们实施了后备策略： 如果他们手头有现金，他们会询问您是否可以用现金支付。 如果您是常客，咖啡师可能会将您的姓名和订单记在账本上，并要求您在下次光顾时付款。 他们可能会使用离线读卡器，在本地存储卡令牌，并在互联网恢复后处理付款。 在软件设计中： 咖啡订单是客户请求。 卡终端是主要下游服务（例如支付网关 API）。 互联网中断是网络超时或服务崩溃。 Ledger / Offline Reader 是后备执行路径。 常见的后备策略 根据业务逻辑和失败服务的严重性，您可以从多种后备策略中进行选择： 1. 静态默认值 最简单的策略是返回一个安全的、预先配置的静态值。这对于可以接受显示空白或默认数据的非关键功能非常有效。 示例：如果个人资料个性化服务失败，则返回默认头像图像和通用问候语。 示例：如果推荐服务失败，则返回空列表或通用畅销书的硬编码列表，而不是抛出错误。 2. 缓存响应（Stale-While-Revalidate） 如果实时数据不可用，您可以回退到本地缓存或快速分布式内存存储（如 Redis）中的只读、陈旧数据。 示例：如果产品库存服务出现故障，则显示 5 分钟前缓存的库存数量，并显示一条微妙的 UI 消息，指示数据可能不是完全最新的。 示例：如果用户设置服务失败，请加载缓存的用户配置文件，而不是阻止其登录流程。 3.替代服务（多提供商） 当执行必须成功的关键操作时，您可以配置辅助服务提供商作为备份。