Sentinel 与 Hystrix 的区别是什么？
- 标签：Spring Cloud、微服务、后端、Hystrix
🏛 业务架构师
Sentinel 与 Hystrix 的区别，我按五个维度对比，最后给出现实结论：
| 维度 | Hystrix（已退役） | Sentinel（现役主流） |
|---|---|---|
| 隔离方式 | 线程池隔离（默认）：每个依赖独立线程池 | 信号量隔离（并发线程数计数），无线程切换开销 |
| 熔断策略 | 异常比例 | 异常比例/异常数/慢调用比例（RT 阈值） |
| 限流能力 | 无独立限流（只能靠线程池大小兜） | 一等公民：QPS/并发线程数、 Warm Up、匀速排队、热点参数限流 |
| 流控效果 | 快速失败 | 快速失败/预热/排队削峰 |
| 规则与控制 | 注解+配置，规则静态、无控制台生态 | 动态规则源（Nacos）+ 控制台：实时改规则、监控、簇链路 |
| 状态 | 2018 年起维护模式，Spring Cloud 已移除 | 持续迭代，Spring Cloud Alibaba 成员 |
架构师视角的深层差异：
- 线程池 vs 信号量的哲学：Hystrix 用线程池隔离，隔离彻底但线程切换开销大、线程数爆炸难运维；Sentinel 信号量 + 按并发数限流，轻量到可以细粒度铺开——工程上"能普及的方案"胜过"更彻底的方案"；
- 治理产品化差距：Hystrix 把决策交给代码和仪表盘；Sentinel 把规则做成运营资产（控制台改阈值秒级生效）——故障应对速度从"改代码发版"变成"控制台点一下"，这是运营能力的代差；
- 慢调用比例熔断是 Sentinel 的重要补强：很多故障不是抛异常而是"变慢"，Hystrix 对此无感，慢调用照样拖垮线程池。
选型结论：Hystrix 只出现在遗留系统；新项目 Sentinel（国内）或 Resilience4j（国际化轻量团队），K8s 重度用户还可以评估服务网格层的能力。
🏗 系统架构师
| 维度 | Hystrix | Sentinel |
|---|---|---|
| 状态 | 2018 停止开发，维护模式 | 阿里开源，社区活跃 |
| 隔离 | 线程池隔离为主（重） | 并发线程数计数（轻） |
| 熔断 | 异常比例 | 慢调用比例/异常比例/异常数 |
| 限流 | 无 | 核心：QPS/并发/热点参数/集群流控 |
| 系统自适应 | 无 | 有（按 Load/RT 动态） |
| 控制台 | 弱 | 实时监控加规则推送 |
| 规则持久化 | 配置文件 | 数据源（Nacos/ZK） |
架构分析：
- Hystrix 的线程池隔离是真正的舱壁（不同依赖独立池，故障物理隔离），代价是线程切换开销与池管理成本；Sentinel 用「并发线程数限制」近似隔离——轻量但隔离语义弱于独立池（Resilience4j 的 Bulkhead 模块保留了正统舱壁）；
- 我的现代组合：Sentinel 做流量治理（限流、热点、自适应）加 Resilience4j Bulkhead 做依赖隔离，或全 Sentinel 加关键依赖手动线程池隔离；
- 迁移经验：Hystrix 退役系统的迁移不是注解一一对应，而是「熔断规则翻译加隔离模型重设计」的工程。
💻 全栈开发专家
| 维度 | Hystrix | Sentinel |
|---|---|---|
| 状态 | 停止维护（2018 起维护模式） | 阿里活跃维护 |
| 隔离方式 | 线程池隔离为主：每依赖一线程池，隔离彻底但线程开销大 | 并发线程数限流（信号量思路），轻量无新线程开销 |
| 熔断策略 | 异常比例/异常数 | 异常比例/异常数/慢调用比例（更贴近真实故障形态） |
| 流控能力 | 无独立流控 | 完整流控：QPS/并发/热点参数/匀速排队/Warm Up |
| 系统自适应保护 | 无 | 有（SystemSlot 按 Load/RT 综合保护） |
| 规则管理 | 代码/配置，动态弱 | Dashboard 实时推送 + 数据源持久化 |
技术本质一句话：Hystrix 用"线程池隔离 + 熔断"防雪崩，重而彻底；Sentinel 用"滑动窗口 + 多维度规则"统一流控熔断，轻而灵活。
实践注脚：Hystrix 存量还不少（金融老系统），迁移是长期工程；新项目基本 Sentinel/Resilience4j 二选一——纯 Spring 体系要轻量选 Resilience4j（函数式无控制台），要控制台和规则中心选 Sentinel。