正文
目标
保证系统不因流量过载而挂。
现状：人工限流
正常的微服务限流工具都需要人工配置：支持应用负责人事先配置限流规则（接口 + 调用方 + 限流阈值），流量在阈值以下可以正常响应，超过阈值的流量会快速失败。这种方案存在如下问题：
问题 1. 接口多，无法全面覆盖
要想保证系统不因流量过载而挂，那就需要对所有中高频接口进行流量管控，不然任意接口的流量上升都可能成为 “压倒骆驼的最后一根稻草”。假设存在 a 个应用，按每个应用平均 b 个中高频接口，每个接口对应 c 个调用方，限流规则配置那数量为 (axbxc)，稍微有点规模的部门这个数量就能上万，要想全面覆盖靠人工基本不可行。
问题 2. 限流阈值无法准确评估
当前限流阈值评估主要有 2 类：
- 历史流量峰值：比如近 7 天系统正常提供服务的流量峰值。但是这个值偏低，容易产生误杀。
- 压测：通过压测演练得出接口的容量上限。但是压测的方式很难模拟真实的线上环境，无论是数据质量，流量的参数质量，依赖方的性能，亦或同应用内不同接口的流量分布都很难与真实环境保持一致。
问题 3. 限流阈值无法长期有效
限流阈值会随着环境的变化而变化。例如流程中新增了一个依赖、或者数据库的数据量增多、热点数据增多、其他接口流量上升占用了更多系统资源、底层的基础设施发生变化等都会导致真实容量降低，限流阈值失效。在这种情况下，持续评估阈值来匹配系统的最新状态根本无法通过人工进行保证。
解决方案：自动限流
针对如上问题解法如下：
- 问题 1. 接口多，无法全面覆盖
- 解：系统自动配置
- 问题 2. 限流阈值无法准确评估
- 解：系统自动评估
- 问题 3. 限流阈值无法长期有效
- 解：系统动态调整
具体方案如下：
系统资源到达使用率到达预警线的时候， 系统自动触发系统进行全面限流， 各接口的限流值根据应用当前的流量状态以及历史的流量状态而定。
- 什么时候限流：应用的容量取决于系统的资源瓶颈，当资源的使用率到达某一水平的时候才需要限流。资源包括数据库、缓存、应用服务器等。
- 谁来限：系统自动
- 限哪些接口：由于同一个应用不同接口都共享了数据库、缓存等、应用服务器等资源，接口之间的容量会相互影响，所以需要全部接口都限制才能保证资源的使用率不再上升。
- 各接口限多少？在资源使用率到达瓶颈的时候，所有的接口性能都会下降，对应的限流阈值也应该下调。具体的限流计算有两种方式：
- 可以把系统在当前状态下各接口能够正常完成的请求量作为限流的参考值，来保证资源利用率不在上升。比如接口 A 接受到的请求速率为 100，其中 50 排队，20 报错，30 正常完成，那么该接口限流值可以参考 30（为排除正常抖动，具体的值可以通过滑动窗口进行平滑）。
- 可以把上一同比周期的同时间（比如昨天的同一时间）的各接口的请求量作为限流的参考值。 可以看着一种回滚：我不知道问题出在哪个接口，但是按照上个周期同时刻的流量来是没问题的。
落地实践：
为防止自动限流的不可控性，可同时使用自动限流和人工限流两种方式，具体方法如下：
- 系统分为正常状态和戒严状态：正常状态下使用人工限流，戒严状态下使用自动限流。
- 正常情况下系统使用人工限流，开发人员可以针对重点接口进行限流配置。
- 当限流值失效或者未配置限流的时候导致系统资源到达预警值时，系统进入戒严状态，此时系统由自动限流接管，并通知开发人员。
- 开发人员收到通知后进行排查，确定导致资源利用率上升的原因，并针对相关接口进行人工限流值的调整（可以参考到达瓶颈前的 qps），并使系统重新切换到正常状态。
备注
该方案还需更多场景验证，如有疏漏还请指出，欢迎有兴趣的小伙伴共同探讨。
作者：京东零售 马坚
来源：京东云开发者社区
