限流、降级、熔断、隔离？
在微服务架构中，服务限流、降级、熔断和隔离是保障系统高可用性的核心手段，但它们解决的问题和应用场景不同。以下是它们的区别、解决方案和实际案例的详细说明：
一、服务限流（Rate Limiting）
定义：通过限制单位时间内的请求数量，防止系统因突发流量过载。
核心区别：主动防御，从入口控制流量。
解决方案：
• 计数器算法：简单计数，超过阈值拒绝请求。
• 滑动窗口算法：更精准的时间窗口计数（如 Redis + Lua）。
• 漏桶算法：恒定速率处理请求（如 Apache Guava 的 RateLimiter）。
• 令牌桶算法：允许突发流量（如 Nginx 的 limit_req 模块）。
实际例子：
• 电商秒杀场景：商品库存仅 1000 件，通过令牌桶算法限制每秒最多处理 500 个请求，超出部分直接返回“活动太火爆，请稍后再试”。
• API 网关：某第三方地图服务对免费用户限制每秒 10 次调用，防止资源滥用。
二、服务降级（Fallback）
定义：在系统压力过大时，暂时关闭非核心功能，释放资源给核心流程。
核心区别：功能取舍，优先保障核心业务。
解决方案：
• 手动降级：运维通过配置中心（如 Nacos）动态关闭非核心功能。
• 自动降级：基于监控指标（如 CPU >80%）触发降级策略。
• 默认返回值：直接返回缓存数据或静态页面（如 Hystrix 的 fallbackMethod）。
实际例子：
• 双十一大促：关闭商品评价、推荐算法等非核心功能，确保下单、支付链路畅通。
• 天气服务故障：降级时返回默认天气数据（如北京默认 25°C），而非直接报错。
三、熔断（Circuit Breaking）
定义：当服务调用失败率超过阈值时，暂时停止访问故障服务，避免雪崩效应。
核心区别：快速失败，防止故障扩散。
解决方案：
• 熔断器模式：Hystrix、Resilience4j、Sentinel 等框架支持熔断策略。
• 状态机：关闭（直接拒绝请求）、半开（尝试探测恢复）、打开（允许部分请求通过）。
实际例子：
• 支付服务超时：若连续 5 次调用支付接口超时，熔断 30 秒，期间直接返回“系统繁忙，请稍后支付”。
• 数据库访问异常：当 SQL 失败率超过 50% 时，熔断数据库访问，改用缓存数据响应。
四、隔离（Isolation）
定义：通过资源隔离，避免单一服务故障影响整个系统。
核心区别：资源划分，减少故障影响范围。
解决方案：
• 线程池隔离：为不同服务分配独立线程池（如 Hystrix 的 THREAD 隔离模式）。
• 信号量隔离：限制并发请求数（sentinel）。
• 物理隔离：不同服务部署到独立的容器或 VM（如 Kubernetes 的 Namespace）。
实际例子：
• 用户服务与订单服务隔离：用户认证服务使用独立线程池，即使认证接口卡顿，也不会阻塞订单生成。
• CPU 密集型任务隔离：将图像处理服务部署到独立容器，避免占用 API 服务的 CPU 资源。
五、协同使用场景示例
电商系统故障处理流程：
- 限流：网关限制秒杀入口每秒 1000 个请求。
- 隔离：秒杀服务使用独立线程池，与普通商品查询服务资源隔离。
- 熔断：若库存服务响应超时 3 次，熔断 10 秒，期间直接返回“库存更新中”。
- 降级：熔断触发后，降级推荐服务，返回静态热门商品列表。
六、常用技术栈对比
| 手段 | 常用工具/框架 | 适用场景 |
|---|---|---|
| 限流 | Nginx、Sentinel、Guava | API 网关、秒杀活动 |
| 降级 | Hystrix、Sentinel、Nacos | 大促期间非核心功能关闭 |
| 熔断 | Hystrix、Resilience4j | 依赖服务频繁超时或报错 |
| 隔离 | Docker、Kubernetes、Hystrix | 资源竞争严重或关键服务保护 |
总结
• 限流是流量入口的“阀门”，控制请求数量。
• 降级是功能维度的“止损”，优先保障核心业务。
• 熔断是故障服务的“保险丝”，快速切断故障源。
• 隔离是资源层面的“屏障”，缩小故障影响范围。
实际系统中，这些手段通常结合使用：例如通过 Sentinel 同时实现限流和熔断，配合 Kubernetes 资源隔离，再通过 Nacos 动态下发降级策略，形成完整的弹性防护体系。