1. 课程导论：为什么需要重试与超时联动？核心痛点与解决思路

在微服务与 API 网关架构中，重试与超时是保障系统可靠性的两个基础手段。然而，若二者各自独立配置、缺乏联动，往往会导致“雪崩式”的故障放大。本章将剖析其核心痛点，并给出联动处理的整体解决思路。

1.1 独立配置的陷阱：重试风暴与超时堆积

当上游服务响应缓慢时，网关若仅配置超时而不限制重试，或仅配置重试而不调整超时窗口，会引发以下典型问题：

1.2 模板引擎渲染超时的特殊性

与普通 API 调用不同，模板引擎渲染（如 Thymeleaf、FreeMarker、Velocity）具有以下特征，使得超时与重试的联动更为复杂：

• 状态累积：渲染过程中可能已写入部分响应缓冲区，重试前需要回滚或重置渲染上下文。
• 资源独占：渲染线程持有模板缓存锁、数据源连接等资源，超时后若未释放，重试请求会竞争同一资源。
• 部分成功：渲染超时可能发生在数据获取阶段，也可能发生在模板解析阶段，不同阶段的联动策略不同。

1.3 联动处理的解决思路

要解决上述问题，需要建立一套“超时感知的重试”与“重试感知的超时”双向联动机制。整体架构如下：

1.4 联动处理的核心原则

基于上述架构，我们提炼出以下四条核心原则，作为后续章节实现的基础：

1. 超时预算优先：每次重试前必须检查剩余超时预算，若剩余时间不足以完成一次完整请求，则直接快速失败。
2. 重试次数与超时窗口联动：总超时时间 = 单次超时 × (1 + 重试次数 × 退避因子)，避免重试导致超时无限延长。
3. 渲染状态感知：模板引擎渲染超时后，必须明确当前渲染阶段（数据获取/模板解析/输出缓冲），决定是否允许重试。
4. 幂等性保障：重试请求必须保证下游接口幂等，渲染上下文必须可重置。

1.5 课程路线图

本课程将按照以下路径逐步深入：