从 MS Graph API 获取消息时出现错误 504（网关超时）

Question

504, Gateway Timeout在过去一周左右的时间里，我们在从 MS Graph API 获取电子邮件时遇到了错误。在此之前的一个多月的运行中，同一应用程序没有遇到该错误，至少没有出现任何显着的频率。

• 我们正在使用 MS Graph API V1.0

• 我们的查询相当简单：

$top=100&$orderBy=lastModifiedDateTime desc&$filter=lastModifiedDateTime lt 2019-09-09T19:27:55Z and parentFolderId ne 'JunkEmail'

• 我们为拥有大量数据（> 100K 电子邮件）的用户设置超时，但偶尔也会为数据量较小（大约 18K 电子邮件）的用户设置超时。从系统工作时到现在我们看到很多超时，音量没有太大变化。

• 我们尝试过简化查询、减少我们请求的消息数量等，但这似乎只产生有限且间歇性的影响。

我的问题- 我们可以采取什么措施来消除/显着降低从 MS Graph API 获取 504、网关超时错误的可能性？

我怀疑，由于我们在没有文件夹过滤器的情况下请求消息，因此我们可能会给查询引擎带来压力。只是一种预感，如果有人真正了解 MS Graph API，我很想知道这是否可能。此外，任何有助于我们更好地了解幕后情况的信息将不胜感激。

更新 1（2019-09-13 15:44:00 EST） - 这是应用程序在 12 小时内（大约）发出的一组提取请求的可视化。粉红色条是成功获取的数量，浅蓝色条是失败的请求（全部都有 504、网关超时作为失败代码）。正如您所看到的，当应用程序启动时，它会出现许多故障，这些故障最终会减少并消失。然后从凌晨 4:30 到上午 9:30 左右，出现了多次故障，但最终都平息下来。几乎所有失败都发生在为一个用户提取消息时，该用户拥有一个非常大的邮箱（> 220K 消息）。我意识到这是一个很小的数据集，如果有帮助的话，我很乐意生成一个运行更长时间的数据集。此外，相关应用程序正在我们的 Azure 租户上运行，作为 Azure Function 应用程序的一部分，位于“美国东部”位置。

更新 2（2019 年 9 月 16 日，美国东部标准时间 09:32:00） - 我们在过去 3 天运行了系统，这里是应用程序在此期间发出的提取请求的可视化。蓝色条表示提取成功，粉红色条表示提取失败（均以 504、网关超时作为失败代码）。总结是，除了第一晚晚上 11 点到凌晨 2 点的一个小窗口外，对于拥有大邮箱的这个特定用户来说，没有任何请求成功。实际上，这意味着尽管有重试逻辑等，我们仍无法处理该用户的数据。

Answer 1

Microsoft Graph 有时会很慢，并且偶尔会受到限制。

我建议您让 Graph SDK 来完成艰苦的工作，这样您就不必自己编写代码来处理所有这些事情。

使用 Microsoft Graph 客户端库版本 1.17.0+，因为它引入了针对 504 错误的自动重试功能。当它们发生时，它也会处理节流（代码 429）。

我想说的是，当您自己收到 504 或 429 时，您可以重试，或者将此类责任委托给 SDK