1

最近在处理 APIGEE 网关开发，发现 Spike Arrest 的使用非常受限于某些集成（仅限后端）。根据 APIGEE 的建议，我们应该避免在此处使用并发速率限制，并可能将其替换为尖峰停止。

但是 Spike Arrest 的实现方式有点狡猾，例如 10 tps 的尖峰停止表示当它每 100 毫秒收到超过 1 个请求时，它将返回触发尖峰停止限制异常。

有了这种行为，看起来速率控制必须在客户端进行控制。绝对可以从客户端后端进行，但是那些直接从前端使用的 API 呢？

想了解在不同情况下推荐的尖峰制动标识符是什么

后端集成

  • 可能通过 API 密钥或身份验证令牌通过每个客户端 ID

前端/SPA

很难，因为与后端不同，考虑到多个用户多个选项卡，无法控制来自浏览器的请求率，但是，我已经考虑过

  • 知识产权？（但单个 IP ！= 单个用户会话）
  • 浏览器 SessionId ?
  • 让客户端知道秒杀错误并执行重试？
  • 不应该用秒杀？

欢迎和赞赏任何见解

4

1 回答 1

1

我相信你对这个空间的思考是正确的。有用的快速参考：https ://docs.apigee.com/api-platform/develop/comparing-quota-spike-arrest-and-concurrent-rate-limit-policies 正如您所提到的，ConcurrentRateLimit 策略已被弃用，但在配额策略（通过调用分配）和 SpikeArrest（由速率控制）之间，您可以轻松控制服务的负载。这两种策略都允许您指定一个属性，以便根据您为该属性设置的值维护单独的计数器或速率计算。这为您的前端用例提供了许多选项，通过配额或普通费率可能会更好。我认为费率是一种更原始​​的保护，而配额是更多的产品管理类型，但其中任何一种（或两者）都可以奏效。考虑基于 SessionID 的配额策略和设置非常高的安全网 SpikeArrest 策略，作为防止服务过载的第二层保护。无论如何，是的，您的客户端应该能够识别 HTTP-429 并知道如何重试。

于 2020-11-30T20:06:17.453 回答