服务限流组件
背景
业务痛点
- 业务和依赖不断演进，压测频率赶不上发版频率
- 活动流量超出预估，意外情况时有发生
- 限流、降级、压测等方法都已用上，仍担心其他隐患
如何让系统更稳定
事前预防
| 措施 | 说明 |
|---|---|
| 回归测试 | 出问题前做足功课，尽量少出问题 |
| 容量压测 | 提前验证系统承载能力 |
| 限流熔断配置（Sentinel） | 预先配置保护策略 |
事后应对
| 措施 | 说明 |
|---|---|
| 自动降级 | 牺牲部分效果和能力，保护最核心的功能 |
| 自动限流 | 牺牲部分流量，保护能够提供的服务能力 |
| 自动扩容 | 负载高时通过扩容主动降低负载 |
| 切换流量 | 发生灾难后将流量切往其他单元 |
使用
引入 Sentinel 的 JAR 包，在管理端对服务中的接口等资源动态配置限流参数，实时生效。
Sentinel vs Hystrix
Sentinel 和 Hystrix 都是微服务架构中用于提升系统稳定性的核心组件，但在设计理念、功能侧重和实现方式上有显著不同。
核心对比
| 对比维度 | Netflix Hystrix | Alibaba Sentinel |
|---|---|---|
| 核心定位 | 服务容错专家（熔断、隔离、降级），防止服务雪崩 | 流量治理平台，从流量控制、熔断降级、系统负载保护等多维度保障稳定性 |
| 隔离策略 | 默认线程池隔离，隔离彻底但资源开销大 | 默认信号量隔离，轻量级、性能损耗小，也支持线程池隔离 |
| 熔断降级 | 基于异常比率或失败比率触发熔断 | 支持基于异常比率、异常数、平均响应时间的熔断，维度更丰富 |
| 流量控制 | 能力较弱，主要通过线程池满实现间接限流 | 功能强大，支持 QPS/并发数限流、预热、匀速排队、集群限流等 |
| 规则配置 | 主要静态配置（代码/文件），动态调整较复杂 | 支持动态配置（控制台、Nacos 等），规则实时生效 |
| 实时监控 | Hystrix Dashboard，功能相对简单 | 功能强大的实时监控控制台，集成度更高 |
| 性能开销 | 较高（线程池模式） | 较低（信号量模式） |
| 生态与社区 | Netflix 开源，已进入维护模式 | 阿里巴巴开源，持续活跃开发，与 Spring Cloud Alibaba 等云原生生态集成好 |
核心差异详解
设计理念的根本不同
- Hystrix：像一个专注电路安全的保险丝。当某个服务故障过多时，果断熔断以保护整个系统不被拖垮
- Sentinel：更像一个智能的交通指挥系统。不仅在路口故障时进行管制（熔断），更擅长在平时控制不同方向的车流量（流量控制）、根据道路状况动态调整信号灯（系统自适应保护）
隔离策略的选择
- Hystrix 线程池隔离：给每个依赖服务分配独立的线程池，隔离性最好，但管理成本（线程切换、内存占用）很高
- Sentinel 信号量隔离：在服务中心入口设置并发接待数限制，轻量高效。对于需要完全切断执行环境影响的场景，也提供了线程池隔离作为可选方案
流量控制能力
Sentinel 提供了丰富的流量整形策略：
- 预热模式：系统在启动低水位时缓慢增加流量，避免冷系统被瞬间压垮
- 匀速排队：以恒定间隔处理请求，应对突发流量，像漏桶一样让流量更加平滑
如何选择
优先选择 Sentinel
- 全新的云原生项目，特别是采用 Spring Cloud Alibaba 技术栈
- 需要精细化的流量控制（如秒杀、限流、API 网关等场景）
- 非常关注性能开销，期望更高吞吐量和更低延迟
- 需要动态规则配置和强大的实时监控仪表板
考虑使用 Hystrix
- 维护现有的、基于 Netflix OSS 的旧系统，且没有强烈的流量控制需求
- 项目主要需求是基本的熔断和隔离，且团队对 Hystrix 非常熟悉
Hystrix 是服务容错领域的开创者和经典，但在当前技术环境下，Sentinel 凭借更全面的功能、更优的性能和活跃的生态，已成为大多数新项目的首选。