限流熔断技术选型：从Hystrix到Sentinel

高可用架构：Hystrix做为你们熟知的容错组件，最近宣布中止开发，不少人对其背景可能了解很少。做为Spring Cloud官方默认的熔断组件，您以为Hystrix是出于哪些缘由中止开发呢？

子衿/宿何：这个事情，我也是以前看媒体报道才了解到的。Hystrix是Netflix的一款开源限流组件，官方宣布中止在开源版本上提供新功能，做为开发者，以为有点惋惜，但仍要感谢Netflix以前以及如今正在为开源作的贡献。

关于Netflix为何会宣布中止在开源版本上提供新功能，目前官方并无给出缘由，只是提供了一些解决方案。但我看到Netflix官方博客的一篇文章，也许能找到技术层面的考量：Netflix 如今正在探索更自动化的熔断方式。因此咱们猜想Netflix内部会逐步再也不使用Hystrix ，没有继续更新的动力；再加上 Hystrix 做为一个熔断降级组件已经很是稳定了，所以中止开发是能够理解的。另外一个是非技术层面，技术的开源是须要业务的增加和完整的技术团队来支撑的，不管是国内仍是国外，开源项目可否持续，依赖于企业在技术上是否能长期投入。博客原文地址[1]。

高可用架构：Hystrix官方推荐使用Resilience4j，大家是怎么看这个项目？

子衿/宿何：resilience4j 是一个比较轻量的熔断降级库。首先 resilience4j 的模块化作的比较好，将每一个功能点（如熔断、限速器、自动重试）都拆成了单独的模块，这样总体结构很清晰，用户也只须要引入相应功能的依赖便可；另外resilience4j 是针对 Java 8 和函数式编程设计的，API 比较简洁优雅。同时与 Hystrix 相比，Resilience4j 增长了简单的限速器和自动重试特性，使用场景更加丰富。Resilience4j 属于一个新兴项目，社区也在蓬勃发展。总的来讲，Resilience4j 是比较轻量的库，在较小较新的项目中使用仍是比较方便的，可是 Resilience4j 只包含限流降级的基本场景，对于很是复杂的企业级服务架构可能没法很好地 cover 住；同时 Resilience4j 缺少生产级别的配套设施（如提供规则管理和实时监控能力的控制台）。

高可用架构：Sentinel今年7月份开源，Github上已经有将近4K的Star，目前发布的最新版本是1.3，可否给高可用架构读者简单介绍一下Sentinel，好比相比于同类项目的优点，设计思想，主要模块以及如何快速接入等。

子衿/宿何：Sentinel 一款面向分布式服务架构的轻量级流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统自适应保护等多个维度来帮助用户保障服务的稳定性。

Sentinel 的核心思想：根据对应资源配置的规则来为资源执行相应的流控/降级/系统保护策略。在 Sentinel 中资源定义和规则配置是分离的。用户先经过 Sentinel API 给对应的业务逻辑定义资源，而后能够在须要的时候动态配置规则。

Sentinel 的优点和特性：

1. 轻量级，核心库无多余依赖，性能损耗小。
2. 方便接入，开源生态普遍。Sentinel 对 Dubbo、Spring Cloud、Web Servlet、gRPC 等经常使用框架提供适配模块，只需引入相应依赖并简单配置便可快速接入；同时针对自定义的场景 Sentinel 还提供低侵入性的注解资源定义方式，方便自定义接入。
3. 丰富的流量控制场景。Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，流控维度包括流控指标、流控效果（塑形）、调用关系、热点、集群等各类维度，针对系统维度也提供自适应的保护机制。
4. 易用的控制台，提供实时监控、机器发现、规则管理等能力。
5. 完善的扩展性设计，提供多样化的 SPI 接口，方便用户根据需求给 Sentinel 添加自定义的逻辑。

Sentinel 与 Hystrix、resilience4j 的对比：（这个对比已经展现在Sentinel的Wiki页面[2]，任何疑问，欢迎发起issue一块儿讨论）

 

 

 

高可用架构：做为流控的重要一环，可否简单介绍一下Sentinel内部是如何实现熔断的？可否给个简单的熔断器使用实例？

子衿/宿何：Sentinel 内部熔断的实现其实就是熔断器的思想。Sentinel 底层会经过优化的滑动窗口数据结构来实时统计全部资源的调用数据（经过 QPS、限流 QPS、异常数、RT 等）。若资源配置了熔断降级规则，那么调用时就会取出当前时刻的统计数据进行判断。当达到熔断阈值时会将熔断器置为开启状态，切断全部的请求，直到过了降级时间窗口后再重置熔断器，继续容许请求经过。

Sentinel 熔断降级支持如下几种指标：平均响应时间、秒级异常比率、分钟级异常数。在 Sentinel 中，咱们通常将熔断降级与并发线程数限流相结合来对不稳定的服务调用进行熔断，防止出现级联错误。

因为Sentinel 的资源定义和规则配置是相分离的，所以只须要对资源配置熔断降级规则便可。好比咱们定义了以下资源：

 

 

 

那么只须要配置以下规则：

 

 

 

 

若是接入了Sentinel 控制台，那么能够直接在 Sentinel 控制台上进行配置，更加方便：

 

 

 

高可用架构：限流相对比较麻烦，尤为是弹性伸缩的架构中，首先得知道系统的承载量，其次，若是横向伸缩了服务器，原有的限流策略未必适用。Sentinel的限流是怎么作的？有没有可能无需配置，自动感知，动态限流？Sentinel支持自定义限流策略，可否给个简单的使用实例？

子衿/宿何：通常来讲，咱们须要经过全链路压测来了解系统的容量，从而能够为限流规则的配置提供参考。Sentinel 支持多个维度的流量控制策略，能够覆盖不一样的流量场景：

• 根据不一样指标：QPS, 并发线程数等
• 根据调用关系：按调用来源限流、按调用链路限流、关联限流等
• 流量塑形控制效果：直接拒绝、冷启动模式、匀速器模式、预热排队模式等
• 不一样的资源维度：服务接口、服务方法、热点参数、自定义资源
• 集群维度的分布式流量控制（即将发布）

流量具备实时性和不肯定性，很难准确地进行预测。如何根据实时流量和系统指标来自适应地限流一直是Sentinel 在不断研究的方向。Sentinel 从 2016 年开始就在不断的探索智能化、自适应限流的可能性，目前开放出来的算法有基于 TCP BBR 的系统保护算法。系统自适应保护能够结合 load 等实时指标，自动探测当前系统水位是否超过系统的最大容量，只有在超出系统处理能力的时候才会发生限流。将来 Sentinel 还会推出更加智能化的自适应限流策略。

限流的使用同上面的降级同样简单，只需配置限流规则便可。如下是一个简单的示例，限制资源每秒的调用QPS 为 20：

 

 

 

高可用架构：Sentinel有基于Spring Boot实现的监控系统，支持哪些metric呢？监控数据是Sentinel主动上报吗？采样率是多少？上报时间间隔是多少？metric数据如何存储？时序数据库吗？可否把监控数据快速集成到现有的监控系统上，好比Zabbix或者Prometheus等等？是否支持自定义metric？可否给个简单的例子？

子衿/宿何：Sentinel 目前的监控支持 QPS、响应时间、限流数、异常数等几种指标。Sentinel 客户端每秒会把秒级的监控数据存储至本地日志，Sentinel 控制台进行拉取和聚合。在生产环境中，因为秒级监控数据的量很是大，咱们通常将 metric 数据存储于列数据库或时序数据库中，并经过一些策略进行优化来保证监控存储和聚合的性能。

Sentinel 正在进行指标与监控标准化的相关工做，在完成标准化，抽出通用的 metric 接口后，便可快速对接 Zabbix 和 Prometheus 等监控系统，同时用户也能够方便地对接其它监控系统。

高可用架构：除了上面提到的功能外，Sentinel还有哪些有意思的特性值得读者了解？

子衿/宿何：Sentinel 的 专业流量控制[3] 相关的特性都值得你们关注，包括流量塑形[3]、系统自适应保护[4]、调用链路统计[5]、热点限流[6]。关于这些特性，咱们也给出了连接，你们感兴趣的话去能够去对应的页面了解。

高可用架构：Sentinel目前有哪些案例，他们使用场景及效果可否简单介绍一下？

子衿/宿何：Sentinel源于阿里巴巴自身的生产实践，适用场景很是丰富，包括：

• 双十一零点持续峰值：限流、慢调用降级
• 秒杀（脉冲流量）：限流、慢调用降级
• 消息队列削峰填谷：MQ 消费端可能会出现大批量的消息同时到达，若瞬时请求全部消息会致使系统负载太高。咱们利用匀速器模式将消息突刺均摊到一段时间内，让系统负载保持在处理能力水位的同时尽量地处理更多消息，从而起到“削峰填谷”的效果。
• 冷启动：当流量忽然增大的时候，咱们但愿系统从空闲状态到繁忙状态的切换的时间长一些，即若是系统在此以前长期处于空闲的状态，咱们但愿处理请求的速率缓慢增长，通过预期的时间之后，到达系统处理请求速率的设定值；
• 热点商品自动探测、防御：自动统计访问频次最高的热点参数并进行流量控制；
• 集群流量不均匀：经过集群限流来解决集群各个机器的流量不均致使总体限流效果不精确的问题；

咱们在10月30日上线了GA版本，目前已有很多企业用户在使用开源版本和云上版本的Sentinel，包括顺丰、vivo、每日优鲜、拼多多、易企秀等，咱们也在社区发起了“who is using Sentinel”[7]的issue，能够去这个页面了解各家企业的使用场景。

高可用架构：Sentinel做为Spring Cloud Alibaba重要的开源组件，先后大概投入了多少人力成本呢？是否有专门的团队进行长期维护？将来有什么样的规划？

子衿/宿何：Sentinel 之因此能开源，而且提供稳定的限流降级功能，是由于站在了巨人的肩膀上，离不开阿里历届高可用架构团队的共同努力。2014年，高可用架构团队因实现了全链路压测，得到了当年的集团CTO大奖。

 

 

 

2014年获奖照片

Sentinel在开源过程当中，对原有代码进行大量的重构、规范化，对模块结构进行了优化，加强了扩展性。目前，咱们有专门的开源团队，对开源项目进行长期的维护和演进。

近期，Sentinel 推出了集群限流版本 1.4.0，提供了独有的灵活、高性能的集群限流模块。集群限流主要针对须要限制整个集群流量总量，可是因为单机流量不均匀而没法精确地限制整体流量的问题。用户能够利用 Sentinel 集群限流模块，结合自动化的管控策略来保障集群流量的稳定。自适应动态限流也是保障稳定性的重要一环。Sentinel 目前提供了基于 BBR 算法的系统自适应保护策略。

将来Sentinel 会继续在无规则容量保护的路上探索，提供更多自适应限流策略，更好地结合系统容量来进行流量控制。另外，Sentinel 也会支持更普遍的开源生态，适配 RxJava、Spring WebFlux 等 reactive 的组件；同时会抽出标准的指标和监控接口，方便对接 Prometheus 等经常使用的监控系统。最后，Sentinel 也会朝着 Cloud Native 的方向演进，引入多语言集群限流客户端支持，同时提供对 Service Mesh 的支持。

文中连接：

[1] https://medium.com/@NetflixTechBlog/performance-under-load-3e6fa9a60581

[2] https://github.com/alibaba/Sentinel/wiki/Guideline:-从-Hystrix-迁移到-Sentinel

[3] https://github.com/alibaba/Sentinel/wiki/流量控制

[4] https://github.com/alibaba/Sentinel/wiki/系统自适应限流

[5] https://github.com/alibaba/Sentinel/wiki/Sentinel工做主流程

[6] https://github.com/alibaba/Sentinel/wiki/热点参数限流

[7] https://github.com/alibaba/Sentinel/issues/18