双 11 的狂欢，干了这碗「流量防控」汤
这是悟空的第 67 篇原创文章
作者 | 悟空聊架构
来源 | 悟空聊架构（ID：PassJava666）
临近双十一，从 2009 年第一届双十一开始，成交量只有 5000 万，到去年 2019 年，成交量达到了 2684 亿。今年迎来了第十二届双十一，想想都挺激动。
阿里人喜欢将双十一视为 Team Building（团队建设），广为流传的一句话：打仗是最好的团建，没有参加过双十一的叫同事，参加过双十一的叫战友。
上一篇我通过三国故事讲解了服务雪崩和熔断的机制，而且自己造了一个轮子：熔断器。而这一篇会讲解被一线大厂使用的两款流量防控组件：Sentinel 和 Hystrix，以及对它们的横向对比，以及该如何选型。
本篇主要内容如下：
本文已收录到我的 Github: https://github.com/Jackson0714/PassJava-Learning
一、熔断&降级&限流&隔离
面对高并发的流量，我们通常会使用四种方式（熔断&降级&限流&隔离）来防止瞬时大流量对系统的冲击。而今天要介绍的这两款流量防卫兵，是专门用在这方面的。下面我先给同学扫个小盲。
什么是熔断 ？
关键字：断路保护。比如 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 对比总结
写在最后
有读者问我秒杀系统该怎么设计，在之前的文章中，我已经揭秘了秒杀系统的架构设计，下面我还是总结下秒杀系统关注的八大点：
服务单一职责、独立部署 库存预热、快速扣减 秒杀链接加密 动静分离 恶意请求拦截 流量错峰 限流&熔断&降级 队列削峰
我是悟空，努力变强成为超级赛亚人。
我们下期见！
- END -
点亮，服务器三年不宕机