重试风暴历来会影响业务运营和品牌信任。虽然重试配置调优和重试预算在服务层面提供了有意义的缓解，但它们是手动配置的，并且缺乏对由深层依赖链和扇出模式引起的跨服务放大效应的可见性。因此，很难保护基础设施免受由堆栈深处单个服务故障引发的多米诺骨牌效应的影响。

一个关键原因是，如今的重试行为不具备上下文感知能力。虽然我们可以控制发生多少次重试，但无法精确控制它们何时发生。这源于可靠区分服务自身产生的错误与仅通过服务传播的错误这一挑战。因此，重试是统一应用的，而非有条件地应用。这种方法适用于瞬态或低速率故障。然而，在中等或严重降级期间，它会适得其反。

对已经苦苦挣扎的服务进行激进重试会增加负载、加速故障，并在上游依赖中放大重试流量。最初只是局部故障，可能迅速升级为全堆栈事件——最终降低，或在最坏情况下完全破坏终端用户体验。

有人可能会争辩说，来自下游服务的错误代码可以在上游进行转换，以为重试提供上下文。虽然理论上可行，但由于Uber存在大量扇入和扇出、不断演变的调用流程以及频繁自适应变更的需求，这种方法在Uber无法扩展。因此，我们在共享基础设施中开发了一种上下文感知机制，以更高效地处理错误。本博客解释了该机制。