限流、降级、熔断、隔离？

在微服务架构中，服务限流、降级、熔断和隔离是保障系统高可用性的核心手段，但它们解决的问题和应用场景不同。以下是它们的区别、解决方案和实际案例的详细说明：

一、服务限流（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	资源竞争严重或关键服务保护