我即将开始开发一个 API，该 API 会同时从 0 RPS 上升到数十万 HTTP RPS，并以该速率运行约 2 分钟。这 3000 万个请求的所有处理必须在 2 分钟时间结束前完成。这种情况每周会发生 7 次。
在消费计划托管模式下使用 Azure Functions 实现无服务器听起来很有吸引力。 This document描述了存在一个缩放 Controller 来协调应用程序实例，但并没有真正讨论我对 HTTP 触发器的期望。我找不到任何表明秤 Controller 能够在我需要的时间范围内做出响应的信息。
我能找到的最好信息是this info说他的测试花了近 8 分钟来扩大规模。
对于消费模式下的 Azure Functions 来说，这是一个糟糕的用例吗？
显然，建立一个能够在 2 分钟内发出 3000 万个请求的测试工具本身就是一项任务，而且是一项昂贵的任务。我想向其他已经这样做的人学习。
最佳答案
根据我的经验，消费计划没有正确涵盖这种情况。它们可以扩展到许多实例，但速度不是很快。 2 分钟太快了，无法依靠。
我主要使用队列，而不是 HTTP，但由于扩展速度慢，导致延迟长达 40 分钟。
如果您可以预测哪 2 分钟将是重负载，那么最好的选择可能是使用脚本(或其他函数)来配置容量。
关于azure - 在消耗模式下运行的 Azure Functions 是否适合变化巨大但时间关键的负载？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45558305/