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

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

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

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

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

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

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

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

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

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

大概的架构如下：

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

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

在开源框架Sentinel中也有这么一个自适应限流的功能，感兴趣的可以去学习下：https://github.com/alibaba/Sentinel/wiki/%E7%B3%BB%E7%BB%9F%E8%87%AA%E9%80%82%E5%BA%94%E9%99%90%E6%B5%81

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

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

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

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