方针

保证系统不因流量过载而挂。

现状：人工限流

正常的微服务限流东西都需求人工配备：支持运用负责人事先配备限流规矩（接口+调用方+限流阈值），流量在阈值以下可以正常照应，超过阈值的流量会快速失利。这种方案存在如下问题：

问题1. 接口多，无法全面掩盖

要想保证系统不因流量过载而挂，那就需求对一切中高频接口进行流量管控，不然恣意接口的流量上升都可能成为“压倒骆驼的最终一根稻草”。假定存在a个运用，按每个运用均匀b个中高频接口, 每个接口对应c个调用方，限流规矩配备那数量为(axbxc)，稍微有点规划的部分这个数量就能上万, 要想全面掩盖靠人工基本不可行。

问题2.限流阈值无法准确点评

其时限流阈值点评主要有2类：

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

问题3. 限流阈值无法长期有效

限流阈值会跟着环境的改动而改动。例如流程中新增了一个依托、或许数据库的数据量增多、热门数据增多、其他接口流量上升占用了更多系统资源、底层的基础设施发生改动等都会导致真实容量降低，限流阈值失效。在这种情况下，继续点评阈值来匹配系统的最新情况根本无法通过人工进行保证。

解决方案：自动限流

针对如上问题解法如下：

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

具体方案如下：

系统资源抵达运用率抵达预警线的时分， 系统自动触发系统进行全面限流， 各接口的限流值依据运用其时的流量情况以及前史的流量情况而定。

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

落地实践：

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

  1. 系统分为正常情况和戒严情况：正常情况下运用人工限流，戒严情况下运用自动限流。
  2. 正常情况下系统运用人工限流，开发人员可以针对要点接口进行限流配备。
  3. 当限流值失效或许未配备限流的时分导致系统资源抵达预警值时，系统进入戒严情况，此刻系统由自动限流接收，并告诉开发人员。
  4. 开发人员收到告诉后进行排查，确认导致资源利用率上升的原因，并针对相关接口进行人工限流值的调整（可以参看抵达瓶颈前的qps），并使系统从头切换到正常情况。

备注

该方案还需更多场景验证，如有疏漏还请指出，欢迎有兴趣的小伙伴一起讨论。

作者：京东零售马坚

来历：京东云开发者社区