标签：流控 压测 痛点 流量 适应 限流 利用率 阀值 1000

大家好，我是架构摆渡人，这是流量治理系列的第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就会被限制，如果下单的请求量大于订单详情的量，那么自适应限流是否可以先满足业务价值更高的流量，让这部分流量先通过，如果此时有其他流量来是否可以自动先限制住。这部分的价值不用我多说，大家都明白。

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

标签：流控,压测,痛点,流量,适应,限流,利用率,阀值,1000
来源： https://www.cnblogs.com/jiagoubaiduren/p/15549337.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。