微服务架构-限流、熔断
引言
微服务中的限流与熔断是两种不同的容错机制，虽然目标都是提升系统稳定性，但解决的问题、实现逻辑和应用场景存在本质区别。以下是两者的详细说明对比：
一、核心定义与目标
-
限流（Rate Limiting）
- 定义：通过限制单位时间内的请求量或资源使用量，防止系统因瞬时高并发请求过载而崩溃。
- 目标：控制流量速率，确保系统在可承受范围内处理请求，适用于突发流量或资源竞争场景（如秒杀、抢购）。
-
熔断（Circuit Breaking）
- 定义：当依赖的某个服务持续异常（如响应超时、错误率过高），主动切断对该服务的调用，避免故障扩散引发“雪崩效应”。
- 目标：隔离故障服务，快速失败以释放资源，保障核心链路可用。
二、实现机制对比
| 维度 | 限流 | 熔断 |
|---|---|---|
| 触发条件 | 请求量超过阈值（如QPS、并发数） | 服务异常（如错误率、超时比例达到阈值） |
| 处理方式 | 直接拒绝、排队等待、匀速通过等 | 直接返回错误，停止调用故障服务 |
| 算法 | 令牌桶、漏桶、滑动窗口等 | 断路器状态机（关闭、打开、半开） |
| 作用范围 | 全局或单个服务入口 | 针对特定依赖服务或调用链路 |
三、典型应用场景
-
限流适用场景
- 高并发接口（如支付系统、登录接口）的流量控制。
- 保护数据库连接池、线程池等关键资源不被耗尽。
- 示例：双11期间电商平台限制每秒订单处理量，超出则提示“系统繁忙”。
-
熔断适用场景
- 依赖服务不稳定（如第三方API频繁超时）时快速失败。
- 防止故障级联（如服务A依赖服务B，B异常时熔断A对B的调用）。
- 示例：支付服务连续超时后，熔断器触发，用户下单时直接提示“支付暂不可用”。
四、两者的互补性
限流与熔断常结合使用以构建完整的容错体系：
- 限流为熔断提供前置保护：通过限制流量，降低依赖服务被压垮的风险。
- 熔断为限流减轻压力：当依赖服务不可用时，熔断可减少无效请求的堆积，避免限流策略失效。
五、技术实现工具
- 限流工具：Sentinel（支持QPS/线程数限流）、Nginx（基于漏桶算法）。
- 熔断工具：Hystrix（基于滑动窗口统计错误率）、Resilience4j（支持熔断与重试组合）。
总结
限流和熔断是微服务架构中相辅相成的两种机制：
- 限流是“流量控制”，解决系统过载问题；
- 熔断是“故障隔离”，解决服务不可用问题。
实际场景中需根据业务需求（如用户体验、SLA要求）综合配置两种策略，例如在核心服务中同时设置限流阈值和熔断规则，兼顾稳定性和可用性。