Retry Pattern

在微服务架构中，服务通过网络而不是内存中的调用进行通信。虽然这种解耦可以实现大规模水平扩展和独立部署，但它也引入了一个主要漏洞：网络不可靠。 下游服务随时可能会遇到短暂的网络故障、临时的 CPU 峰值、快速的数据库锁定争用或滚动更新重启。这些临时故障称为“暂时性故障”。 如果您的服务在下游调用失败时立即抛出错误并导致请求失败，则会造成脆弱的用户体验。相反，许多暂时性错误可以通过等待片刻并重试来自动解决。这就是 重试模式 的用武之地。 在本指南中，我们将探讨重试模式、它的幕后工作原理、简单实现的危险，以及如何在 Java (Resilience4j) 和 Go 中正确实现它。 现实世界的类比：重拨占线的线路 想象一下您正在尝试给朋友打电话。您拨打他们的号码，但收到忙音，因为他们当前正在通话。 您是否会立即放弃，删除他们的联系方式，并认为您永远无法再与他们交谈？当然不是。您挂断电话，稍等一下，然后再次拨打他们的号码。如果他们仍然很忙，您可以等待五分钟再重试。 最终，他们的通话结束，您的重试成功。 在微服务中： Call 是对下游服务的 API 请求。 忙信号是暂时性网络错误或 503 Service Unavailable 响应。 重拨 是重试尝试。 等待时间 是退避持续时间。 危险：天真的重试和“重试风暴” 乍一看，实现重试机制似乎微不足道：只需将 HTTP 调用包装在 for 循环中，然后继续尝试，直到成功为止。然而，天真的重试实现很容易将一个小问题演变成灾难性的系统范围中断。 想象一下下游服务在流量突然激增的情况下陷入困境。其数据库以 99% 的 CPU 利用率运行，并且请求开始超时。 如果 100 个客户端服务都检测到超时并立即重试 3 次而无需等待，它们将突然使已经陷入困境的下游服务的流量增加三倍。这种流量的突然放大被称为“重试风暴”（或“Thundering Herd”问题）。 您的重试不但不会帮助下游服务恢复，反而会不断将其推低，使其无法跟上。 解决方案：退避和抖动 为了防止重试风暴，弹性系统必须利用两个基本策略：退避和抖动。