用于租户隔离的API流量整形/节流策略

首先，我将提供一些关于我们正在做什么和我们面临的问题的背景

• 我们目前正在构建一个SaaS（托管在AmazonAWS上），它由几个微服务组成，这些微服务位于API网关后面（我们正在使用Kong）
• 网关处理身份验证（通过具有API密钥的消费者），并公开我提到的这些微服务的API，所有这些服务都是无状态的（没有会话、cookie或类似的）
• 每个服务都使用ECS服务（一台或多台EC2机器上运行的每个服务一个或多个docker容器）进行部署，并使用Amazon应用程序负载平衡器（ALB）进行负载平衡
• 所有租户（客户机）共享相同的环境，即相同的机器和资源。考虑到我们的商业模式，我们希望（一开始）只有“大”租户
• 在请求期间，对这些服务的大多数请求都会导致大量资源使用（主要是CPU）。服务一个请求所需的时间在2-10秒之间（不像传统的“web式”应用程序那样需要毫秒）。这意味着我们每分钟处理相对较少的请求，其中每个请求都需要一段时间来处理（后台或批处理不是一个选项）

目前，我们没有一个策略来限制或限制租户在给定时间段内可以发出的请求量。考虑到上面的最后两个考虑因素，很容易看出这是一个问题，因为租户发出的请求超出了我们的处理能力，这几乎是微不足道的，这会导致服务质量下降（即使对于其他租户，由于共享资源的方法）

我们正在考虑限制/限制策略，或者总体上准备系统以“隔离”租户，这样一个租户就不能通过提出超出我们处理能力的请求来降低其他租户的性能：

• 速率限制：定义租户可以发出的最大请求数/m。如果有更多的请求到达，请丢弃它们。Kong甚至有一个插件。遗憾的是，我们使用“按请求付费”的定价模式，业务部门不允许我们使用这种策略，因为我们希望尽可能多地服务请求，以便获得付款。如果多余的请求对承租人来说需要更多的时间，那没关系
• 租户隔离：为每个租户创建一个隔离的环境。这一个也被丢弃了，因为它使维护更加困难，并导致资源使用率降低和成本升高
• 自动缩放：启动更多机器以吸收爆发。根据我们的经验，亚马逊ECS在这方面做得不是很快，到这些新机器准备好的时候，可能已经太晚了
• 请求“节流”：在API网关级别使用诸如泄漏桶或令牌桶之类的算法，以确保请求以我们已知的速度命中服务

现在，我们倾向于选择4。我们希望以这样一种方式实现请求节流（流量整形），即在先前与租户商定的速率内（通过合同强制执行）发出的所有请求都将毫不延迟地传递给服务。由于我们提前知道每个租户每分钟将发出多少请求（至少估计），因此我们可以相应地调整基础设施的大小（加上安全裕度）

如果突发到达，多余的请求将排队（达到一定限制），然后以固定速率释放（使用泄漏桶或类似算法）。这将确保租户不会影响其他租户的性能，因为请求将以预定义的速率命中服务。理想情况下，允许的请求速率应该是“动态的”，这样租户就可以使用未使用它们的其他租户的一些“每分钟请求”（在安全限制内）。我相信这就是所谓的“动态速率漏桶”算法。目标是最大限度地利用资源

我的问题是：

• 提议的策略是可行的吗？您知道这个用例还有其他可行的策略吗
• 是否有开源、商业或SaaS服务可以提供这种流量整形功能？据我所知，Kong或Tyk不支持这种功能，因此。。。还有其他API网关可以吗
• 如果Kong不支持这一点，那么实现我所描述的插件有多难？我们必须考虑到，当我们使用多个Kong实例（用于负载平衡和高可用性）时，它需要一些共享状态（例如使用Redis）

多谢各位，

---

Mikel.

在网关端管理请求队列确实是一件棘手的事情，可能它没有在这个网关中实现的主要原因是很难做到正确。您需要处理所有分布式系统案例，此外，这很难保证它的“安全”，因为“慢”客户端很快就会消耗机器资源

这种模式通常被卸载到客户端库中，所以当客户端达到速率限制状态代码时，它使用类似smth的指数退避技术来重试请求。它更易于扩展和实现

不能说是香港，但在本例中，Tyk提供了两个您可以控制的基本数字，配额-客户端在给定时间段内可以发出的最大请求数，以及速率限制-安全保护。您可以为每个“策略”设置速率限制1），例如为一组消费者设置速率限制（例如，如果您的服务有多个层次，具有不同的允许使用率/速率限制），2）为每个密钥设置速率限制3）为API设置全局速率限制（与密钥速率限制一起工作）。例如，您可以设置一些中等的客户端速率限制，并使用全局API设置来限制总速率限制

如果需要完全动态的方案，请根据集群负载重新计算限制