流量防控该如何选型？

临近双十一，从 2009 年第一届双十一开始，成交量只有 5000 万，到去年 2019 年，成交量达到了 2684 亿。今年迎来了第十二届双十一，想想都挺激动。

阿里人喜欢将双十一视为 Team Building（团队建设），广为流传的一句话：打仗是最好的团建，没有参加过双十一的叫同事，参加过双十一的叫战友。

上一篇我通过三国故事讲解了服务雪崩和熔断的机制，而且自己造了一个轮子：熔断器。而这一篇会讲解被一线大厂使用的两款流量防控组件：Sentinel 和 Hystrix，以及对它们的横向对比。

本篇主要内容如下：

本文已收录到我的 Github:
https://github.com/Jackson0714/PassJava-Learning
点我 Github 链接

一、熔断&降级&限流&隔离

面对高并发的流量，我们通常会使用四种方式（熔断&降级&限流&隔离）来防止瞬时大流量对系统的冲击。而今天要介绍的这两款流量防卫兵，是专门用在这方面的。下面我先给同学扫个小盲。

• 什么是熔断 ？

关键字：断路保护。比如 A 服务调用 B 服务，由于网络问题或 B 服务宕机了或 B 服务的处理时间长，导致请求的时间超长，如果在一定时间内多次出现这种情况，就可以直接将 B 断路了（A 不再请求B）。而调用 B 服务的请求直接返回降级数据，不必等待 B 服务的执行。因此 B 服务的问题，不会级联影响到 A 服务。

• 什么是降级 ？

关键字：返回降级数据。网站处于流量高峰期，服务器压力剧增，根据当前业务情况及流量，对一些服务和页面进行有策略的降级（停止服务，所有的调用直接返回降级数据）。以此缓解服务器资源的压力，保证核心业务的正常运行，保持了客户和大部分客户得到正确的响应。降级数据可以简单理解为快速返回了一个 false，前端页面告诉用户“服务器当前正忙，请稍后再试。”

• 什么是限流？

  

  对请求的流量进行控制， 只放行部分请求，使服务能够承担不超过自己能力的流量压力。

• 熔断和降级的相同点？

  • 熔断和限流都是为了保证集群大部分服务的可用性和可靠性。防止核心服务崩溃。
  • 给终端用户的感受就是某个功能不可用。

• 熔断和降级的不同点？

  • 熔断是被调用放出现了故障，主动触发的操作。
  • 降级是基于全局考虑，停止某些正常服务，释放资源。

• 什么是隔离？

  • 每个服务看作一个独立运行的系统，即使某一个系统有问题，也不会影响其他服务。

二、Hystrix

Hystrix 是什么

Hystrix：高可用性保障的一个框架。由 Netflix 出品（Netflix可以理解为国内的爱奇艺等视频网站）。

Hystrix 的历史

• 2011 年，其中的 API 团队为了提升系统的可用性和稳定性，发展出了 Hystrix 框架。

• 2012 年，Hystrix 区域比较成熟稳定。其他团队也开始使用 Hystrix。

• 2018 年 11 月，Hystrix在其 Github 主页宣布，不再开放新功能，推荐开发者使用其他仍然活跃的开源项目。但是 Hystrix 价值依旧很大，功能强大，国内很多一线互联网公司在使用。

Hystrix 设计理念

• 阻止服务的雪崩效应。
• 快速失败和快速恢复。
• 优雅降级。
• 使用资源隔离技术，如 bulkhead（舱壁隔离技术）、swimlane（泳道技术）、circuit breaker（断路技术）。
• 近实时的监控、报警及运维操作。

Hystrix 线程池隔离技术

使用线程池隔离，比如说有 3 个服务 A、B、C，每个服务的线程池分配 10，20，30个线程，当 A 服务线程池中的 10 个线程都拿出来使用后，如果调用服务 A 的请求量增加，还想再增加线程是不行的，因为 A 服务分配的线程已经用完了，不会拿其他的服务的线程，这样就不会影响其他服务了。Hystrix 默认使用线程池隔离模式。

线程池隔离技术优点

• 依赖的服务都有隔离的线程池，即使自己的此案成池满了，也不会影响任何其他其他的服务调用。
• 线程池的健康状态会上报，可以近实时修改依赖服务的调用配置。
• 线程池具有异步特性，可以构建一层异步调用层。
• 具有超时检测的机制，尤其在服务间调用特别有用。

线程池隔离技术缺点

• 线程池本身就会带来一些问题，比如线程切换，线程管理，无疑增加了 CPU 的开销。
• 如果线程池中的线程利用率很低，则无疑是一种浪费。

Hystrix 信号量隔离技术

如下图所示：简单来说就是一个池子里面放着一定数量的信号量，服务 A 每次调用服务 B 之前，需要从池子里面申请信号量，申请到了，才能去调用 B 服务。

线程池隔离和信号量的场景对比

• 线程池隔离技术 ，适合大部分场景，但需要设置服务的超时时间。
• 信号量隔离技术 ，适合内部比较复杂的业务，不涉及网络请求问题。

三、Sentinel

3.1、Sentinel 是什么

Sentinel：面向分布式服务架构的流量控制组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统负载保护、热点防护等多个维度来帮助开发者保障微服务的稳定性。

3.2、Sentinel 的历史

• 2012 年，Sentinel 诞生，主要功能为入口流量控制。
• 2013-2017 年，Sentinel 在阿里巴巴集团内部迅速发展，成为基础技术模块，覆盖了所有的核心场景。Sentinel 也因此积累了大量的流量归整场景以及生产实践。
• 2018 年，Sentinel 开源，并持续演进。
• 2019 年，Sentinel 朝着多语言扩展的方向不断探索，推出 C++ 原生版本，同时针对 Service Mesh 场景也推出了 Envoy 集群流量控制支持，以解决 Service Mesh 架构下多语言限流的问题。
• 2020 年，推出 Sentinel Go 版本，继续朝着云原生方向演进。

3.3、Sentinel 的特征

• 丰富的应用场景。 支撑阿里的双十一核心场景，如秒杀、消息削峰填谷、集群流量控制、实时熔断下游不可用。
• 完备的实时监控。 可以看到接入应用的单台机器秒级数据，以及集群的汇总情况。
• 广泛的开源生态。 Spring Cloud、Dubbo、gRPC 都可以接入 Sentinel。
• 完善的 SPI 扩展点。 实现扩展接口来快速定制逻辑。

用一张图来总结：

3.4、Sentinel 的组成

• 核心库（Java 客户端）不依赖任何框架/库，能在所有的 Java 运行时环境运行，且对 Spring Cloud、Dubbo 等框架有较好的支持。
• 控制台（Dashboard）基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等应用容器。

3.5、Sentinel 的资源

Sentinel 中的资源是核心概念，可以是 Java 应用程序中的任何内容，可以是提供的服务，甚至是一段代码。

可以通过 Sentinel API 定义的代码，就是资源，能够被 Sentinel保护起来。可以如下几种方式来标识资源：

• 方法签名。
• URL。
• 服务名称等。

3.6、Sentinel 的设计理念

Sentinel 作为一个流量控制器，可以根据需要把随机的请求调整成合适的形状，如下图所示：

四、对比

4.1、隔离设计上对比

• Hystrix

Hystrix 提供两种隔离策略，线程池隔离和信号量隔离。

Hystrix 中最推荐的也是最常用的是线程池隔离。线程池隔离的好处是隔离度很高，不会影响其他资源，但是线程本身也有自己的问题，线程上下文切换时比较耗 CPU 资源的，如果对低延时要求比较高，影响还是挺大的，而且创建线程是需要分配内存的，创建的线程越多，需要分配的内存也会更多。而且如果对每个资源都创建一个线程池，那线程切换会带来更大的损耗。

而 Hystrix 的信号量隔离，可以对某个资源调用的并发数进行限制，轻量级的，不用显式创建线程池，但缺点是不能对慢调用进行自动降级，只能等客户端那边超时，还是有可能出现级联阻塞的情形。

• Sentinel

Sentinel 可以通过并发线程数模式的流量控制来提供信号量隔离的功能，而且它还具备响应时间的熔断降级模式，防止过多的慢调用占满并发数而影响整个系统。

4.2、熔断降级的对比

Sentinel 和 Hystrix 都是基于熔断器模式。都支持基于异常比率来进行熔断，但 Sentinel 更强大，可以基于响应时间、异常比率和异常数来进行熔断降级。

4.3、实时统计的对比

Sentinel 和 Hystrix 都是基于滑动窗口进行实时统计，但 Hystrix 是基于 RxJava 的事件驱动模型，在服务调用成功/失败/超时的时候发布响应的事件，通过一系列的变换和聚合最终得到实时的指标统计数据流，可以被熔断器或 Dashboard 消费。而 Sentinel 是基于 LeapArray 的滑动窗口。

五、Sentinel 的突出特性

除了上面提到的 三大对比外，Sentinel 还有一些 Hystrix 不具备的功能。

5.1、流量控制

流量控制： 其原理是监控应用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。

Sentinel 可以基于QPS/并发数进行流量控制，也可以基于调用关系进行流量控制。

基于 QPS 进行流量控制有以下几种方式：

• 直接拒绝： 当QPS 超过一定阈值时，直接拒绝。适用于对系统处理能力确切已知的情况。
• 慢启动预热： 当系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮。

• 匀速排队： 请求以均匀的速度通过，对应的是漏桶算法。

基于调用关系的流量控制：

• 根据调用方限流。
• 根据调用链路入口限流：链路限流。
• 根据具有关系的资源流量限流：关联流量限流。

5.2、系统自适应限流

Sentinel 系统自适应限流从整体维度对应用入口流量进行控制，借助 TCP BBR 思想，结合应用的 Load、CPU 使用率、总体平均 RT、入口 QPS 和并发线程数等几个维度的监控指标，通过自适应的流控策略，让系统的入口流量和系统的负载达到一个平衡，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。

我们把系统处理请求的过程想象为一个水管，到来的请求是往这个水管灌水，当系统处理顺畅的时候，请求不需要排队，直接从水管中穿过，这个请求的RT是最短的；反之，当请求堆积的时候，那么处理请求的时间则会变为：排队时间 + 最短处理时间。

• 推论一: 如果我们能够保证水管里的水量，能够让水顺畅的流动，则不会增加排队的请求；也就是说，这个时候的系统负载不会进一步恶化。

• 推论二:　当保持入口的流量是水管出来的流量的最大的值的时候，可以最大利用水管的处理能力。

5.3、 实时监控和控制面板

Sentinel 提供一个轻量级的开源控制台，它提供机器发现以及健康情况管理、监控（单机和集群），规则管理和推送的功能。

5.4、 发展及生态

Sentinel 针对 Spring Cloud、Dubbo、gRPC 都进行了适配，引入依赖和简单的配置即可快速接入 Sentinel，相信 Sentinel 将是未来流量防控的一大利器。我比较看好 Sentinel。

5.5、 Sentinel 和 Hystrix 对比总结

写在最后

有读者问我秒杀系统该怎么设计，在之前的文章中，我已经揭秘了秒杀系统的架构设计，下面我还是总结下秒杀系统的关注的八大点：

• 服务单一职责、独立部署
• 库存预热、快速扣减
• 秒杀链接加密
• 动静分离
• 恶意请求拦截
• 流量错峰
• 限流&熔断&降级
• 队列削峰

我是悟空，努力变强成为超级赛亚人。

我们下期见！