关于自动限流的思考 _自动限流

目标保证系统不因流量过载而挂。
现状：人工限流【关于自动限流的思考】正常的微服务限流工具都需要人工配置：支持应用负责人事先配置限流规则（接口+调用方+限流阈值），流量在阈值以下可以正常响应，超过阈值的流量会快速失败。这种方案存在如下问题：
问题1. 接口多，无法全面覆盖要想保证系统不因流量过载而挂，那就需要对所有中高频接口进行流量管控，不然任意接口的流量上升都可能成为“压倒骆驼的最后一根稻草” 。假设存在a个应用，按每个应用平均b个中高频接口, 每个接口对应c个调用方，限流规则配置那数量为(axbxc)，稍微有点规模的部门这个数量就能上万, 要想全面覆盖靠人工基本不可行。
问题2.限流阈值无法准确评估当前限流阈值评估主要有2类：

历史流量峰值：比如近7天系统正常提供服务的流量峰值。但是这个值偏低，容易产生误杀。
压测：通过压测演练得出接口的容量上限。但是压测的方式很难模拟真实的线上环境，无论是数据质量，流量的参数质量，依赖方的性能，亦或同应用内不同接口的流量分布都很难与真实环境保持一致。

问题3. 限流阈值无法长期有效限流阈值会随着环境的变化而变化。例如流程中新增了一个依赖、或者数据库的数据量增多、热点数据增多、其他接口流量上升占用了更多系统资源、底层的基础设施发生变化等都会导致真实容量降低，限流阈值失效。在这种情况下，持续评估阈值来匹配系统的最新状态根本无法通过人工进行保证。
解决方案：自动限流针对如上问题解法如下：

问题1. 接口多，无法全面覆盖
解：系统自动配置
问题2.限流阈值无法准确评估
解：系统自动评估
问题3. 限流阈值无法长期有效
解：系统动态调整

具体方案如下：系统资源到达使用率到达预警线的时候，系统自动触发系统进行全面限流，各接口的限流值根据应用当前的流量状态以及历史的流量状态而定。

什么时候限流：应用的容量取决于系统的资源瓶颈，当资源的使用率到达某一水平的时候才需要限流。资源包括数据库、缓存、应用服务器等。
谁来限：系统自动
限哪些接口：由于同一个应用不同接口都共享了数据库、缓存等、应用服务器等资源，接口之间的容量会相互影响，所以需要全部接口都限制才能保证资源的使用率不再上升。
各接口限多少？在资源使用率到达瓶颈的时候，所有的接口性能都会下降，对应的限流阈值也应该下调。具体的限流计算有两种方式：
1. 可以把系统在当前状态下各接口能够正常完成的请求量作为限流的参考值，来保证资源利用率不在上升。比如接口A接受到的请求速率为100，其中50排队，20报错，30正常完成，那么该接口限流值可以参考30（为排除正常抖动，具体的值可以通过滑动窗口进行平滑）。
2. 可以把上一同比周期的同时间（比如昨天的同一时间）的各接口的请求量作为限流的参考值。可以看着一种回滚：我不知道问题出在哪个接口，但是按照上个周期同时刻的流量来是没问题的。

落地实践：为防止自动限流的不可控性，可同时使用自动限流和人工限流两种方式，具体方法如下：