SpringCloud之Hystrix
SpringCloud之Hystrix
推荐参考：https://www.springcloud.cc/spring-cloud-dalston.html#_circuit_breaker_hystrix_clients
1. 什么是Hystrix ？
Spring Cloud Hystrix 是 Netflix 开源的容错库，用于解决分布式系统中的服务雪崩问题。它通过熔断、降级、限流等机制提升系统的弹性和稳定性。
分布式系统中通常很多复杂业务存在很长的链路调用，当分布式系统中多个服务之间调用的时候，如 服务A 调用 服务B 和 服务C，服务B 和 微服务C 又调用其他的微服务，如果链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统的崩溃，这就是所谓的“雪崩效应”，而Hystrix 就是为了解决这个问题。
2. Hystrix 的核心作用
- 服务熔断（Circuit Breaking）
当某个服务的失败率超过阈值（如 10 秒内 20 次请求且失败率 > 50%），熔断器会自动进入 Open 状态，后续请求直接短路，不再调用故障服务。
熔断后经过设定时间（如 5 秒）进入 Half-Open 状态，尝试部分请求，成功则恢复 Closed 状态。
- 服务降级（Fallback）
当服务调用超时、异常或熔断触发时，执行预设的降级逻辑（如返回默认值、缓存数据），避免用户感知故障。
- 服务隔离（Isolation）
通过线程池或信号量隔离资源，防止单个服务的故障耗尽系统资源（如 Tomcat 线程），避免级联失败。
- 限流与监控
控制并发请求量，防止突发流量压垮服务；提供 Dashboard 实时监控熔断器状态。
3. 熔断和降级的区别
1. 图表对比：
.
| 维度 | 服务熔断 | 服务降级 |
|---|---|---|
| 本质 | 全局性防护（针对整个服务） | 单次请求的补偿（针对单次调用） |
| 触发条件 | 依赖统计指标（如错误率 > 50%） | 单次请求异常（超时、报错、熔断已触发） |
| 作用范围 | 后续所有请求都会被拦截 | 仅对当前请求生效 |
| 目标 | 防止故障扩散，快速释放系统资源 | 保证单次请求的“有损可用性” |
| 类比举例 | 开关跳闸（切断电路） | 停电时用手电筒（临时替代方案） |
2. 服务熔断（Circuit Breaking）
流程：
监控服务调用：统计窗口期（如 10 秒）内的失败率和请求量。触发熔断：当失败率超过阈值（如 50%）且请求量达到下限（如 20 次），熔断器进入 Open 状态。拦截请求：熔断期间所有对该服务的调用直接拒绝，不再发起真实请求。尝试恢复：经过冷却时间（如 5 秒）后进入 Half-Open 状态，放行少量请求探测，成功则关闭熔断。
效果：
⚡️ 保护下游服务：避免故障服务被持续调用，防止资源耗尽。⚡️ 快速失败：减少无意义的等待（如超时阻塞）。
3. 服务降级（Fallback）
流程：
当单次请求出现超时、异常或熔断已开启时，触发降级。执行预设的降级逻辑（如返回默认值、缓存数据、友好提示）。请求结束，不阻断后续请求。
效果：
🌟 用户体验保障：用户不会看到错误页面，而是获得兜底响应（如“功能繁忙，请稍后重试”）。🌟 部分功能可用：核心流程可降级运行（如查询订单详情时，若库存服务不可用，仅隐藏库存信息）。
4. 举例分析熔断与降级：
.
电商支付场景
-
正常流程：
订单服务 → 调用 → 支付服务 → 返回支付结果。 -
异常场景：
支付服务响应缓慢（如数据库压力大）：
降级触发：订单服务调用支付接口超时 → 返回降级结果：“支付处理中，稍后查看结果”。熔断未触发：因未达到错误率阈值。支付服务完全宕机：
订单服务连续调用失败 → 熔断触发（错误率 > 50%）。后续所有支付请求被熔断器拦截 → 每次拦截都触发降级 → 统一返回“支付系统维护中”。
4. Hystrix 应用场景
-
微服务调用链保护
如：订单服务依赖支付服务，若支付服务超时，Hystrix 触发熔断，订单服务返回“支付繁忙”提示，避免线程阻塞。
-
高并发流量控制
通过信号量限制用户查询接口的并发数，防止数据库崩溃。
-
第三方服务不可靠时
调用外部 API 失败时，返回本地缓存数据。
5. 总结
Hystrix 本质是分布式系统的“保险丝”，通过 快速熔断故障服务 + 优雅降级 保障核心链路可用性。尽管Hystrix 已停止更新（Netflix 进入维护模式），但其容错设计思想（如熔断状态机、资源隔离）仍深刻影响微服务架构。