流量治理最大的痛点-资源利用率上不去

大家好,我是架构摆渡人,这是流量治理系列的第9篇原创文章,如果有收获,还请分享给更多的朋友。

曾经有人问过我,限流有痛点吗?我当时的回答是:限流阀值不太好评估以及限流降低了用户的体验,这是我认为的痛点。

限流阀值到底怎么评估还是得有压测的动作,特别是现在电商平台,在大促前都会进行全链路压测,将问题暴露出来,看能承受多少流量的请求。然后再根据业务预期,就知道要不要扩容,以及流控的指标了,说难也不难,就是需要多种手段进行佐证。

降低用户体验这个是限流必须经历的,用户正在下单,然后收到的提示就是服务器当前太拥挤,网络异常,请重试等等提示,说简单点就是降低了用户的体验,因为用户需要反复操作。说的严重点就是影响了下单的转换率,所以这也是为什么电商平台大促前要压测的原因。不是说直接限流到很低的水位就行,就是用户体验和系统复杂度要权衡。

其实还有一个更痛的点就是:资源利用率上不去。

当我们经过压测后,评估单节点的性能最大值时,流控的阀值在70%是比较稳妥的做法。比如你单机压到1000 QPS, 然后CPU和内存都在50%左右,那么直接就流控 1000 即可。

这1000里面可能还会细分接口,不同的接口限流的值也不同。比如你某个接口配置了500限流,只要这个接口的请求量超过了500那么必定会限流,但是有可能这个时候只有这个接口的访问量比较多,其他的都没什么访问量,机器的CPU,内存什么的还很低,包括数据库的响应也很快。此时好像不限流也没关系,但是因为限流配置的是固定的值,只能限制了。

面对这种情况,一种新的限流方式就诞生了,就是自适应限流。自适应限流就是没有固定的限流阀值,限流的阀值会变化,变化的因素就是依赖的资源是否足够,比如CPU,内存等资源。

自适应限流还是比较复杂的,复杂点在于需要实时采集各种数据,然后通过大量的计算,再提取出决策,这个决策就是是否要限流,并且计算速度还得快。

大概的架构如下:

流量治理最大的痛点-资源利用率上不去

当然这个计算是单独的服务,还是内嵌在当前的应用中都是可以的,取决于性能影响以及是否集群流控。

有了自适应限流,资源的利用率将被大大提升。因为不用在设置一个比较稳妥的固定的值了,而是根据资源的使用情况来决定是否限流,最大程序利用资源。

在开源框架Sentinel中也有这么一个自适应限流的功能,感兴趣的可以去学习下:https://github.com/alibaba/Sentinel/wiki/系统自适应限流

自适应限流的好处一个是能够提高资源的利用率,还有就是能否适应不确定的因素带来的影响。相比于静态的限流配置,我们一定是基于压测后的结果来配置,即使是压测后,到了真正大流量来袭的时候,也无法保证跟压测时的结果一模一样。万一有突发情况,一条慢Sql把数据库的CPU打满了,你限流的阀值还是那么多QPS, 慢SQL增加几百倍,这个限流此时就失去了作用。

通过自适应限流,根据实时计算的结果决定是否要流控,保证系统稳定性。同时也避免了繁琐的人工配置过程,系统自动调节。

再举一个例子:下单接口限流值为1000,订单详情为500。如果按照固定的值做限流,下单超过1000就会被限制,如果下单的请求量大于订单详情的量,那么自适应限流是否可以先满足业务价值更高的流量,让这部分流量先通过,如果此时有其他流量来是否可以自动先限制住。这部分的价值不用我多说,大家都明白。

所以自适应限流能做很多东西,主要是智能,智能提现在算法层面,有点人工智能的意思哈。

上一篇:ssm整合


下一篇:SQLITE_ERROR - table sap_capire_bookshop_books has no column named currency