阿里巴巴Sentinel的实践与优化

阿里巴巴Sentinel的实践与优化

概述背景

       笔者目前负责一个APP的内容运营平台的研发，其相关业务为APP首页提供展示数据，包括标题、跳转链接、图标等内容。其APP平台日访问PV超过2亿，其中APP首页有50%的数据来源于内部关联系统。在工作日高峰时间段，访问关联方的QPS超过2w。在营销活动时间点前后APP平台的流量是日常的流量的2.5倍左右。跟常见的高并发系统一样，平台主要的问题有雪崩和突增的流量。所以我们引入了Sentinel，并进行改进解决了以上问题。

一、雪崩：在活动营销日，关联方系统的不稳定极其容易影响APP平台正常服务。如果某个接口查询Redis缓存时间变长，耗时变长，导致系统的吞吐量下降，同时客户端都阻塞在该接口上，影响了客户端的其他请求，即雪崩现象。

如上图，当业务系统C出现异常的情况，会导致业务系统B访问业务系统C超时，业务对象长时间无法回收会耗尽内存等资源。同理业务系统B的异常有可能会导致业务系统A出现奔溃的现象。最终会导致整个上下游的关联系统全部无法提供服务，即系统雪崩。因此我们需要每个组件都要有对上游系统的接口进行熔断的机制。当上游系统C的接口出现异常，那么系统B不在请求业务系统C了，保证了自身应用还可以继续对外提供其他接口的服务。

二、限流：对于营销活动日，我们可以采用限流的方法可以避免活动页面带来的流量的冲击，影响其他页面的展示，所以需要对活动页进行限流，以保证系统不会被活动带来的高并发流量冲垮。

因此我们引入了开源的Sentinel，并进行个性化的业务开发。

集中式的Dashboard

开源Sentinel的dashboard是应用和dashboard直接网络通讯，网络交互较复杂，需要每个团队都部署一个dashboard应用。增加使用成本，目前我们部门采取集中式的Dashboard部署，无需其他团队部署Dashboard。

集中式的dashboard如上图，只部署一个dashboard应用，所有的应用把监控的数据发送到MQ，然后dashboard从MQ广播方式的消费数据，即可以避免复杂的网络交互，减少运维成本。降低每个团队使用Sentinel Dashboard的成本 

熔断算法的改进

字段

说明

默认值

resource

资源名称，限流规则的作用对象

count

限流阈值

grade

限流类型。0-平均时延，取值范围 0-RT[0-4900]；1-异常比例；2-异常数量

0-平均时延

timeWindow

降级时间（单位秒）

熔断降级的配置

    

上表是降级熔断的规则说明。熔断降级提供了从资源（接口）的时延、异常数量和异常比例的维度对接口进行判断是否需要熔断降级。当一个接口的时延达到了阈值，那么将会停止请求关联方接口一个周期，过了一个周期后会恢复请求关联方。以保证关联方接口出现异常，不会级联影响调用方的应用。

如上图，绿色的曲线代表是通过的QPS，蓝色的代表拒绝的QPS。当全部的流量访问到关联方接口，关联方系统的时延增加达到阈值，Sentinel立马熔断关联方接口。一个周期后恢复访问关联方，从而周期性的访问关联方。因此我们总结发现，熔断配置的周期是无法匹配关联方恢复的时间，关联方接口有可能需要一段时间后恢复，也有可能立马恢复。所以，我们研发了自动限流熔断的算法。

字段

说明

默认值

resource

资源名称（字符串），限流规则的作用对象。

count

RT阈值（ms）;异常比例（取值范围[0-1]）；异常数量（0以上）

1000

grade

阈值类型（预留），取值范围 0-RT[0-4900]；1-异常比例；2-异常数量

0

timeWindow

检查阈值的周期，每个周期进行阈值的更新，包括减少和增加类型（单位MS）

1000

growStep

恢复步长。限流后参考拥塞避免算法对阈值增加的步长。取值范围[0-1]

0.03

reduceStep

限流步长，即触发限流时，会根据当前的QPS计算出QPS阈值。取值范围[-1-0]

-0.03

type

步长的类型 1-按比例；2-按绝对值

1

自动熔断会计算出时延达到阈值的QPS，然后客户端会在该QPS以下访问关联方。相比开源的降级熔断，自动熔断能降低熔断比例，能够适配关联方系统的性能，降低业务影响。

自动熔断可以自动适配上游系统接口的性能，即设定一个接口的时延RT，如果请求这个接口的时延达到设置的阈值，那么将会减少对这个接口的请求。保证目标接口的时延在正常的范围以内，不影响自身应用和上游系统的运行。

自动熔断比开源的熔断使用的场景更丰富，如下图假设关联方的系统只能处理60QPS左右，那么对于客户端就要把超过60QPS的请求都熔断掉。保证尽可能的多访问关联方，同时不影响关联方系统。相比开源Sentinel的熔断，熔断时间可以跟关联方接口恢复的时间保持一致，即能快速熔断关联方接口，又能快速的恢复。

流量控制

对于应用服务器来说，任意时间到来的请求往往是随机不可控的，而系统的处理能力是有限，比如CPU、磁盘IO、内存资源都是有限的。我们需要根据业务系统的处理性能对流量进行控制。Sentinel提供了流量整形的功能。可以支持按照资源的调用关系、比如调用链路、资源与资源之间的关系；支持按照QPS、并发数量进行控制；支持直接限流、匀速、冷启动的效果对应用服务进行流量控制。其中Sentinel的限流使用了活动窗口算法，匀速限流则使用了漏桶算法，相关算法如下：

滑动窗口算法。滑动窗口算法是将时间周期分为N个小周期，分别记录每个小周期内访问次数，并且根据时间滑动删除过期的小周期。如下图，把一个时间周期划分为5个周期（比如每个周期200ms），计算最近1S的次数，就计算最近5个窗口的计数。

漏桶算法。漏桶算法可以消除“突刺现象”，如右图类似于漏斗有一个容器，所有的请求都先进入到容器中，然后漏桶以固定的速率释放请求通过。

漏桶实现可以用一个队列来存放请求，另一个线程定时的从队列中获取请求，并执行。

这种算法存在一个缺陷，无法在短时间内响应突发的流量。

全局兜底的限流熔断规则

作为APP平台，或者叫业务网关，我们的数据主要来源关联方，目前有120多个接口，而且未来还会持续增加，而且未来随着需求的增加还会持续增加。配置限流熔断的规则会成为一个日常的工作，容易出现遗漏的问题。改进后的Sentinel提供了兜底的配置，即如果某一个接口已经配置自动限流熔断或者限流的规则，优先使用自动限流熔断或者限流的规则。如果没有找到规则，就查找兜底的配置，并更具兜底的阈值，动态生成一个限流或者熔断的规则。可以覆盖全部的接口，又可以减少配置工作量。

字段

说明

默认值

count

RT阈值（ms）;异常比例（取值范围[0-1]）；异常数量（0以上）

1000

grade

阈值类型（预留），取值范围 0-RT[0-4900]；1-异常比例；2-异常数量

0

timeWindow

检查阈值的周期，每个周期进行阈值的更新，包括减少和增加类型（单位MS）

1000

growStep

恢复步长。限流后参考拥塞避免算法对阈值增加的步长。取值范围[0-1]

0.03

reduceStep

限流步长，即触发限流时，会根据当前的QPS计算出QPS阈值。取值范围[-1-0]

-0.03

type

步长的类型 1-按比例；2-按绝对值

1

如上表，兜底的自动限流熔断跟单个接口的自动限流熔断规则就差了一个resource字段，其中resource字段是动态的内容，比如ESA的名称和HTTP接口的path。

思考和总结

    熔断阈值的思考。使用熔断降级和自动限流熔断时，会疑惑怎样选取接口的时延作为熔断的阈值。性能测试真实的演示了日常运营到营销活动时的流量变化。

阶段一、并发数量缓慢的从0开始增加到常态负载阶段时，随着并发数量增加QPS快速的增加，而接口响应时延变化没那么明显。此阶段应用服务器的各项资源使用率不超过45%。当再增加并发数量时，QPS和时延都在增加，服务接口的平均响应时延增加较大，此时有小部分接口的响应时间较长。

阶段二、当并发数达到一定数量时，即应用系统某一项资源使用率达到100%时，此时应用能够对外提供服务的吞吐量，也是在性能测试中QPS的峰值，即瓶颈性能。

阶段三、在应用服务某一个资源使用率达到100%后，再增加并发数量，此时QPS下降，但是应用服务器接口的响应时间快速增加。所以，我们在熔断维度选择接口RT，其阈值应该考虑达到瓶颈性能时的时延。

此外，从负载测试曲线可以从接口的时延可以间接判断出应用的某个资源使用率是否达到了100%。即上游系统的某个资源达到了瓶颈，一般都会有体现接口耗时的增加。比如常见的性能问题：1.CPU使用率增加会导致系统负载增加，更多的线程等待处理；2.磁盘的IOPS等指标达到了瓶颈也会导致读写磁盘的请求都在等待；3.内存使用率上升可能会引发JVM的GC，随着GC的次数和时间增加，可能导致业务接口时延增加。

总结：限流熔断基本解决了APP平台的雪崩问题，保证的系统的高可用性。其中自动熔断能友好熔断上游系统的接口，避免上游系统异常时带来的影响，能够自动适应关联方接口的性能，降低熔断比例，减少业务影响。另外，日常生产运维的角度都是优先判断应用整体接口的响应时间、CPU使用率、系统负载、内存使用率（GC情况）、IOPS，从而判断出问题所在，所以系统保护能更好地从运维人员的角度来保护应用。