1. 课程导学
在微服务架构中，一个业务接口往往需要串联多个下游服务才能完成。例如，订单创建接口需要调用用户服务、库存服务、支付服务和通知服务。这种跨服务调用模式引入了两个核心问题：调用方应该等待多久？ 以及 失败后是否应该再试一次？
本课程将围绕这两个问题，系统性地讲解超时与重试机制的设计、实现与最佳实践。
1.1 为什么跨服务调用必须设置超时？
没有超时控制的跨服务调用，本质上是一个“无限等待”的陷阱。以下表格列出了无超时调用带来的典型风险：
| 风险场景 | 具体表现 | 后果 |
|---|---|---|
| 下游服务挂死 | 服务进程崩溃或死锁，不返回响应 | 调用方 Goroutine 永久阻塞，内存泄漏 |
| 网络分区 | 网络设备故障，请求包丢失 | TCP 连接超时前（通常 30s-120s）无任何反馈 |
| 慢响应堆积 | 下游响应变慢（如 10s），大量请求排队 | 调用方线程池/连接池耗尽，引发级联故障 |
| 资源泄露 | HTTP 连接、数据库连接无法释放 | 系统资源耗尽，最终宕机 |
核心结论：超时是分布式系统的“安全阀”。没有超时，一个慢服务就能拖垮整个调用链。
1.2 为什么需要重试机制？
超时解决了“等待多久”的问题，但超时后直接返回失败，对用户体验和系统可用性并不友好。网络抖动、服务临时过载、GC 停顿等瞬时故障，往往在几毫秒后就能自行恢复。此时，重试 是提升成功率最直接的手段。
重试机制需要区分两类故障：
- 可重试故障：网络超时、HTTP 503（Service Unavailable）、连接池耗尽、数据库死锁（超时后自动回滚）。这类故障在重试时大概率能成功。
- 不可重试故障：HTTP 400（Bad Request）、401（Unauthorized）、403（Forbidden）、404（Not Found）、数据校验失败。这类故障重试多少次都不会成功，反而浪费资源。
注意：重试不是万能的。不加控制的重试会引发“重试风暴”，导致下游服务雪崩。本课程后续章节会详细讲解退避策略、熔断与限流如何与重试配合。
1.3 超时与重试的协同关系
超时和重试不是独立配置的，它们需要协同工作。下图展示了在一次跨服务调用中，超时与重试的完整生命周期：
从流程图中可以看出：超时是重试的触发条件，重试是超时后的补救措施。两者结合，才能构建健壮的跨服务调用。
1.4 课程目标
完成本课程后，你将能够：
- 理解原理：掌握超时与重试的核心概念、常见算法（固定退避、指数退避、抖动退避）及其适用场景。
- Go 语言实现：使用
context.Context、net/http.Client、time.Timer等标准库实现超时控制；使用循环+退避算法实现重试逻辑。 - 框架集成：在 gRPC、HTTP 客户端、数据库连接池等场景中配置超时与重试。
- 生产级实践：结合熔断器（Circuit Breaker）、限流器（Rate Limiter）和链路追踪，构建完整的容错体系。
- 避坑指南：识别幂等性缺失、重试风暴、超时穿透等常见陷阱，并给出解决方案。
1.5 学习路径
本课程共 30 章，分为五个阶段：
| 阶段 | 章节范围 | 核心内容 |
|---|---|---|
| 基础篇 | 第 1-5 章 | 超时与重试原理、Go 标准库实现、context 超时传递 |
| 进阶篇 | 第 6-12 章 | 退避算法、重试策略、幂等性设计、重试风暴防护 |
| 框架篇 | 第 13-20 章 | gRPC 拦截器、HTTP 客户端中间件、数据库重试、消息队列重试 |
| 实战篇 | 第 21-26 章 | 熔断器集成、限流配合、链路追踪、全链路超时传递 |
| 总结篇 | 第 27-30 章 | 项目实战：构建可配置的跨服务调用客户端、性能压测、生产部署 |
学习建议：基础篇和进阶篇建议按顺序学习，框架篇和实战篇可以根据实际工作场景跳跃式阅读。每章末尾都配有可运行的 Go 代码示例，建议动手运行并修改参数观察效果。
1.6 前置知识
学习本课程需要具备以下基础：
- 熟悉 Go 语言基础语法（goroutine、channel、interface）
- 了解 HTTP 协议基础（请求/响应模型、状态码）
- 了解 gRPC 基础概念（proto 定义、一元调用）
- 有基本的分布式系统概念（服务注册发现、负载均衡）
如果你对上述内容不熟悉，建议先阅读 Go 官方文档或相关入门教程。本课程会在涉及关键概念时提供简要回顾，但不会从头讲解基础语法。