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

Question

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

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

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

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

后端集成

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

前端/SPA

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

• IP？ （但单个 IP ！= 单个用户会话）
• 浏览器 SessionId？
• Rest 客户端是否能够感知秒杀错误并执行重试？
• 不应该使用秒杀？

欢迎和赞赏任何见解

Answer 1

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