微服务接口限流的设计与思考.docx

微服务接口限流的设计与思考 限流中的“流”字该如何解读呢？要限制的目标到底是什么？不同的场景对“流”的定义也是不同的，可以是网络流量，带宽，每秒处理的事务数 (TPS)，每秒恳求数 (hits per second)，并发恳求数，甚至还可能是业务上的某个目标，比如用户在某段时间内允许的最多恳求短信验证码次数。 从保证系统稳定可用的角度考量，对于微服务系统来说，最好的一个限流目标是：并发恳求数。通过限制并发处理的恳求数目，可以限制任何时辰都不会有过多的恳求在消耗资源，比如：我们通过配置 web 容器中 servlet worker 线程数目为 200，则任何时辰最多都只要 200 个恳求在处理，超过的恳求都会被堵塞排队。 上一节讲到，我们为了处理调用方对服务资源的过度争用问题，还需要针对不同调用方甚至不同接口做细粒度限流，所以，我们除了需要对系统全体的并发恳求数做限制之外，还需要对每个调用方甚至不同接口的并发恳求数做限制。但是，要想合理的设置某个调用方的最大允许并发数是比较困难的，这个值很难通过监控统计来猎取，太小简约误宰，太大又起不了作用。所以我们还需要其他限流目标。 对比 TPS 和 hits per second 的两个目标，我们选择使用 hits per second 作为限流目标。由于，对 TPS 的限流实际上是无法做的，TPS 表示每秒处理事务数，事务的开头是接收到接口恳求，事务的结束是处理完成前往，所以有肯定的时间跨度，假如事务开头限流计数器加一，事务结束限流计数器减一，则就等同于并发限流。而假如把事务恳求接收作为计数时间点，则就退化为依据 hits per second 来做限流，而假如把事务结束作为计数时间点，则计数器的数值并不能代表系统当下以及接下来的系统访问压力。 对 hits per second 的限流能否是一个有效的限流目标呢？答案是确定的，这个值是可观看可统计的，所以便利配置限流规章，而且这个值在肯定程度上反应系统当前和接下来的功能压力，对于这一目标的限流的确也可以达到限制对系统资源的使用。 有了流的定义之后，我们接下来看几种常用的限流算法：固定时间窗口，滑动时间窗口，令牌桶算法，漏桶算法以及他们的改进版本。 固定、滑动时间窗口限流算法 基于固定时间窗口的限流算法是格外简约的。首先需要选定一个时间起点，之后每次接口恳求到来都累加计数器，假如在当前时间窗口内，依据限流规章（比如每秒钟最大允许 100 次接口恳求），累加访问次数超过限流值，则限流熔断拒绝接口恳求。当进入下一个时间窗口之后，计数器清零重新计数。 这种基于固定时间窗口的限流算法的缺点在于：限流策略过于粗略，无法应对两个时间窗口临界时间内的突发流量。我们举一个例子：假设我们限流规章为每秒钟不超过 100 次接口恳求，第一个 1s 时间窗口内，100 次接口恳求都集中在最终的 10ms 内，在其次个 1s 的时间窗口内，100 次接口恳求都集中在最开头的 10ms 内，虽然两个时间窗口内流量都符合限流要求 (=100 个恳求)，但在两个时间窗口临界的 20ms 内会集中有 200 次接口恳求，假如不做限流，集中在这 20ms 内的 200 次恳求就有可能压垮系统，如图 -1： 滑动时间窗口算法是对固定时间窗口算法的一种改进，流量经过滑动时间窗口算法整形之后，可以保证任意时间窗口内，都不会超过最大允许的限流值，从流量曲线上来看会愈加平滑，可以部分处理上面提到的临界突发流量问题。对比固定时间窗口限流算法，滑动时间窗口限流算法的时间窗口是持续滑动的，并且除了需要一个计数器来记录时间窗口内接口恳求次数之外，还需要记录在时间窗口内每个接口恳求到达的时间点，对内存的占用会比较多。滑动时间窗口的算法模型如下： 滑动窗口记录的时间点 list = (t_1, t_2, …t_k)，时间窗口大小为 1 秒，起点是 list 中最小的时间点。当 t_m 时辰新的恳求到来时，我们通过以下步骤来更新滑动时间窗口并推断能否限流熔断： STEP 1: 检查接口恳求的时间 t_m 能否在当前的时间窗口 [t_start, t_start+1 秒) 内。假如是，则跳转到 STEP 3，否则跳转到 STEP 2. STEP 2: 向后滑动时间窗口，将时间窗口的起点 t_start 更新为 list 中的其次小时间点，并将最小的时间点从 list 中删除。然后，跳转到 STEP 1。 STEP 3: 推断当前时间窗口内的接口恳求数能否小于最大允许的接口恳求限流值，即推断: list.size max_hits_limit，假如小于，则说明没有超过限流值，允许接口恳求，并将此接口恳求的访问时间放入到时间窗口内，否则直接执行限流熔断。 滑动时间窗口限流算法可以部分处理固定时间窗口的