又拍云张聪：OpenResty 动态流控的几种姿势

2019 年 1 月 12 日，由又拍云、OpenResty 中国社区主办的 OpenResty × Open Talk 全国巡回沙龙·深圳站圆满结束，又拍云首席架构师张聪在活动上做了《 OpenResty 动态流控的几种姿势 》的分享。 
OpenResty x Open Talk 全国巡回沙龙是由 OpenResty 社区、又拍云发起的，为促进 OpenResty 在技术圈的发展，增进 OpenResty 使用者的交流与学习的系列活动，活动将会陆续在深圳、北京、上海、广州、杭州、成都、武汉等地举办，欢迎大家关注。
张聪，又拍云首席架构师，多年 CDN 行业产品设计、技术开发和团队管理相关经验，个人技术方向集中在 Nginx、OpenResty 等高性能 Web 服务器方面，国内 OpenResty 技术早期推广者之一；目前担任又拍云内容加速部技术负责人，主导又拍云 CDN 技术平台的建设和发展。

以下是分享全文：

大家下午好，今天我主要和大家分享“在 OpenResty 上如何做动态的流量控制”，将会从以下几个方面来介绍：

• Nginx 如何做流控，介绍几种经典的速率和流量控制的指令和方法；
• OpenResty 如何动态化做流控；
• OpenResty 动态流控在又拍云的业务应用。

又拍云与 OpenResty 结缘

我目前在又拍云负责 CDN 的架构设计和开发工作，又拍云早在 2012 年就开始接触 OpenResty ，当时我们做调研选型，部分项目考虑用 Lua 来实现，在此之前是基于 Nginx C 模块来做业务开发，一个防盗链模块就好几千行代码，改成 Lua 之后大量减少了代码，并且整个开发的效率、维护的复杂度都降低了。此外我们通过测试和性能对比，几乎没有多的损耗，因为在这一层主要是字符串的处理，甚至在 LuaJIT 加速的情况下有很多的调用，比我们原先用 C 写的函数还高效得多。

目前又拍云整个 CDN 代理层系统、对外开放的 API 系统、数据中心的网关系统、分布式云存储代理层、逻辑层全部用 ngx_lua 进行了深度的改造，又拍云内部几个不同业务的团队都在 OpenResty 技术栈上有多年的实践和经验积累。

又拍云开放了一个 upyun-resty 的仓库（https://github.com/upyun/upyun-resty），我们内部孵化的开源项目以及对社区的补丁修复等都会发布在这个仓库。大家如果对又拍云这块的工作感兴趣可以关注这个仓库，我们今年还会陆续把内部使用非常成熟的一些库放出来，包括今天讲的两个与限速有关的 Lua 库也已经开源出来了。

什么是流控以及为什么要做流控

1、什么是流控

今天的主题，首先是针对应用层，尤其是 7 层的 HTTP 层，在业务流量进来的时候如何做流量的疏导和控制。我个人对“流控”的理解（针对应用层）：

（1） 流控通常意义下是通过一些合理的技术手段对入口请求或流量进行有效地疏导和控制，从而使得有限资源的上游服务和整个系统能始终在健康的设计负荷下工作，同时在不影响绝大多数用户体验的情况下，整个系统的“利益”最大化。

因为后端资源有限，无论考虑成本、机器或者系统本身的瓶颈，不可能要求上游系统能够承受突发的流量，而需要在前面做好流量的控制和管理。

有时候我们不得不牺牲少数的用户体验，拒绝部分请求来保证绝大多数的请求正常地服务，其实没有完美能够解决所有问题的方案，所以这个在流量控制中要结合我们对业务的理解需要学会做取舍。

（2） 流控有时候也是在考虑安全和成本时的一个手段。

除了上面的通用场景，流控也在安全和成本上做控制。比如敏感账号的登录页面，密码失败次数多了就禁掉它，不允许反复暴力尝试；比如我们的上游带宽有限，需要确保传输的带宽在较低的水平中进行，不要把线路跑满，因为跑满有可能涉及到一些成本超支的问题等。

2、为什么要流控

针对上面的描述，下面介绍一些流控跟速率限制的方法。

（1）为了业务数据安全，针对关键密码认证请求进行有限次数限制，避免他人通过字典攻击暴力破解。

为了数据安全，我们会对一些敏感的请求尝试访问做累计次数的限制，比如一定时间内你输错了三次密码，接下来的几个小时内就不让你来尝试了，这是一种很常见的手段。如果没有这样的保护，攻击者会不断试你的密码，调用这个敏感的接口，最终可能会让他试出来，所以这是需要保护的。

（2）在保障正常用户请求频率的同时，限制非正常速率的恶意 DDoS 攻击请求，拒绝非人类访问。

我们需要保障一个 API 服务正常的请求流量，但是拒绝完全恶意的 DDoS 的攻击、大量非人类访问。这也是在最前面这层需要做的事情，否则这些请求串进上游，很多后端的服务器肯定是抗不住的。

（3）控制上游应用在同一时刻处理的用户请求数量，以免出现并发资源竞争导致体验下降。

我们需要控制上游只能同时并发处理几个任务或几个请求，此时关心的是“同时”，因为它可能有内部的资源竞争，或者有一些冲突，必须保证这个服务“同时”只能满足几个用户的处理。

（4）上游业务处理能力有限，如果某一时刻累计未完成任务超过设计最大容量，会导致整体系统出现不稳定甚至持续恶化，需要时刻保持在安全负荷下工作。

当我们整个上游系统的弹性伸缩能力还不错，它会有一个设计好的最大容量空间，即最多累计能够承受多大量的请求流入。如果超过它最大可处理范围性能就会下降。例如一个任务系统每小时能够完成 10 万个任务，如果一个小时内任务没有堆积超过 10 万，它都能够正常处理；但某一个小时出现了 20 万请求，那它处理能力就会下降，它原本一小时能处理 10 万，此时可能只能处理 5 万或 2 万甚至更少，性能变得很差，持续恶化，甚至最终导致崩溃。

因此，我们需要对这样的流量进行疏导，确保后端系统能够健康地运行，如果它每小时最多只能跑 10 万的任务，那么无论多大的任务量，每小时最多都应只让它跑 10 万的量，而不是因为量超过了，反而最后连 10 万都跑不到。

（5）集群模式下，负载均衡也是流控最基础的一个环节，当然也有些业务无法精确进行前置负载均衡，例如图片处理等场景就容易出现单点资源瓶颈，此时需要根据上游节点实时负载情况进行主动调度。

在做流量管理时，负载均衡是很基础的。如果一个集群基本负载均衡都没做好，流量还是偏的，上游某个节点很容易在集群中出现单点，这时去做流量控制就有点不合适。流量控制，首先在集群模式下要先做好负载均衡，在流量均衡的情况下再去做流量控制，识别恶意的流量。而不要前面的负载均衡都没做好，流量都集中在某一台机器上，那你在这一台上去做控制，