临近双十一，从 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 对比总结
写在最后
有读者问我秒杀系统该怎么设计，在之前的文章中，我已经揭秘了秒杀系统的架构设计，下面我还是总结下秒杀系统的关注的八大点：
- 服务单一职责、独立部署
- 库存预热、快速扣减
- 秒杀链接加密
- 动静分离
- 恶意请求拦截
- 流量错峰
- 限流&熔断&降级
- 队列削峰
我是悟空，努力变强成为超级赛亚人。
我们下期见！
