我正在使用 Microsoft Graph API 来处理来自外部客户端/系统的事件。因此，系统中发生变化，事件被发送到队列，我正在处理的代码从队列中获取这些事件，以 20 个为一组进行批处理，在 Graph 生态系统中执行下游操作。这些操作实际上可以是任何内容，但我正在处理的最简单的场景是更新 SharePoint 列表项中的某些字段值。
因此，更改再次发生在外部系统中，进入队列，我的代码使用该队列中的事件，以 20 个请求为一组对它们进行批处理，每个请求都是一个 POST，用于更新 SharePoint 列表项的字段。
从技术上来说，你可以说一切都运行良好。我已经考虑了批处理/限制指南（Microsoft Graph 限制指南），因此，代码通过等待
MAX(RETRY_AFTER)RETRY_AFTER这是许多事件驱动系统中非常常见的场景。当事件以低速率生成时，一切正常。即使有几千个事件排队，追上也不会花太长时间。然而，当生产者速率激增，或者说，数以万计的事件排队时，吞吐量开始显着降低，导致受限制的请求数量开始增加。
我还采取了必要的步骤来防止解决方案的消费者端以并行图形请求的数量可能淹没图形 API 的方式进行扩展。我最多与 5 个并行消费者/批次合作。
我还阅读了有关 Graph（Microsoft Graph 服务特定的限制）和 SharePoint（避免在 SharePoint Online 中受到限制或阻止）的请求限制，以及 5 年前的帖子 Microsoft Graph API -节流.
我在测试中看到的是，由于限制，消费率低至每秒 10 个请求。
我的问题是：
在对图表应用更改时，还有其他什么可以增加吞吐量吗？或者应该在最大范围内考虑 10 请求/秒左右，仅此而已？
PS：我正在寻找可以改进处理尖峰的解决方案的东西。理想情况下，基础设施或许可证不会增加一倍、三倍或乘以 X 因素。理想情况下，这就像在短时间内（几分钟）扩展系统，然后再缩小。
如果您的问题和改进有任何更新，我们将不胜感激。