APIGEE Spike Arrest 前端集成的最佳实践/实用用法

Question

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

但是 Spike Arrest 的实施方式有点狡猾，例如 10 tps的spike逮捕表示每100ms收到超过1个请求时将返回触发spike逮捕限制异常。

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

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

后端集成

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

前端/SPA

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

• IP ? （但单个 IP ！= 单个用户会话）
• 浏览器 SessionId ?
• 让客户端知道尖峰抑制错误并执行重试？
• 不应使用尖峰制动？

欢迎和赞赏任何见解

Answer 1

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