1. 课程导学与项目背景：为什么需要限流与熔断？
在微服务架构与高并发业务场景下，单个接口的突发流量往往会导致整个系统的连锁崩溃。本章作为课程的开篇，将深入剖析雪崩效应的成因，并引出限流与熔断作为系统自我保护的核心手段。
1.1 高并发场景下的典型困境
假设你负责一个电商平台的“秒杀”接口，平时 QPS 约为 500。在促销活动开始时，流量瞬间飙升至 5000 QPS。此时，如果系统没有保护机制，会发生什么？
- 数据库连接池耗尽：大量请求等待数据库连接，导致连接超时。
- CPU 与内存飙升：服务线程被阻塞，GC 频繁，响应时间从 10ms 暴涨到 10s。
- 上游服务被拖垮：调用该接口的网关、用户服务、订单服务因等待响应而堆积请求，最终导致级联故障。
核心结论：没有限流与熔断的系统，在高并发下如同没有保险丝的电路，随时可能烧毁整个机房。
1.2 雪崩效应：从单点故障到系统瘫痪
雪崩效应是指系统中某个微服务因过载或故障，导致依赖它的其他服务也相继崩溃，最终引发整个系统不可用的现象。其传播路径通常遵循以下步骤：
- 服务 A 过载：响应时间从 50ms 增加到 5s。
- 服务 B 等待：服务 B 调用服务 A 的线程被阻塞，线程池迅速占满。
- 服务 B 拒绝新请求：线程池满后，新请求被拒绝或排队，导致服务 B 自身也开始变慢。
- 级联扩散：依赖服务 B 的服务 C、D 相继出现线程阻塞和资源耗尽。
- 系统雪崩：整个调用链上的服务全部不可用，业务彻底中断。
1.3 系统自我保护机制：限流与熔断
为了应对雪崩效应，业界总结出两种核心的自我保护手段：限流（Rate Limiting）和熔断（Circuit Breaker）。它们虽然目标一致，但作用层次和实现逻辑不同。
| 对比维度 | 限流 (Rate Limiting) | 熔断 (Circuit Breaker) |
|---|---|---|
| 核心目标 | 控制请求进入的速率，防止系统过载 | 快速失败，防止故障扩散 |
| 触发条件 | 基于 QPS、并发数、令牌桶等指标 | 基于错误率、超时比例、慢调用次数 |
| 动作结果 | 直接拒绝或排队等待 | 断开调用链路，返回降级响应 |
| 恢复方式 | 流量下降后自动恢复 | 半开状态探测，成功后自动闭合 |
| 典型算法 | 令牌桶、漏桶、滑动窗口 | 状态机（关闭/打开/半开） |
| Go 实现代表 | rate.Limiter、uber/ratelimit | hystrix-go、go-resilience |
实践建议：限流应部署在网关层或入口层，熔断应部署在服务调用层（RPC 客户端）。两者结合使用，可以构建从入口到服务调用的完整防护体系。
1.4 限流与熔断的协同工作流程
在一个典型的 Go 微服务项目中，限流与熔断通常按照以下流程协同工作：
1.5 本章课程目标与项目背景
本课程将基于一个真实的 Go 电商项目，从零到一落地限流与熔断机制。你将学到：
- 限流算法实战：在 Go 中实现令牌桶、漏桶、滑动窗口算法，并对比性能差异。
- 熔断器模式：基于状态机实现熔断器，支持自定义错误阈值和半开探测。
- 项目集成：将限流与熔断集成到 Gin 框架中间件和 gRPC 拦截器中。
- 监控与告警：使用 Prometheus 指标暴露限流与熔断状态，配合 Grafana 可视化。
前置要求：你需要具备 Go 语言基础（goroutine、channel、interface），了解 HTTP 和 gRPC 的基本概念。课程代码基于 Go 1.21+ 编写。