Azure EventGrid Webhook超时

从文档中了解到webhook的超时是60秒。如果是这样，那么我们是否期望开发人员执行异步操作？我的意思是，如果作为webhook的一部分，我想做的工作需要超过60秒怎么办？但是，如果我们使该操作异步，并且我希望作为webhook的一部分所做的工作失败，那么我们如何从这种情况中恢复，因为我们已经响应了事件网格200 OK。那样的话，我们会输掉比赛吗

在类似您的场景中，例如事件处理程序处理时间超过60秒，可以基于重试和死信技术实现以下功能：

• 将主事件订阅与重试策略一起使用，然后 死字。此绑定到存储表的订阅服务器（功能）将处理长时间运行（最多24小时）事件处理的状态，并将第一条事件消息转发到存储队列以触发长时间运行的进程。此主订阅服务器的响应将取决于StorageQueueTrigger函数的状态

• 每个新的重试事件消息都将检查长时间运行的进程的状态，并在此基础上，将响应代码（例如OK（200）或Service.Unavailable（503））发送回事件网格

在上述场景中，重试机制表示一个“看门狗定时器”，用于监视长时间运行的事件消息处理。第二个函数（如QueueTrigger函数）在事件网格和长时间运行的进程之间生成一个进程

总之，您的场景将需要以下内容：

• 具有重试策略和Webhook死信的EventSubscriber（EventGridTrigger或HttpTrigger函数）
• EventGridTrigger或HttpTrigger函数
• 储物台
• 队列触发函数

如果在看门狗定时器期间发生任何异常情况，死信将被发送到您的容器存储器，并带有死信原因

请注意，如果长时间运行的进程超过5/10分钟，则需要在应用程序服务计划中考虑StorageQueue触发器，或使用自定义工作处理器

更新：

下面的屏幕片段显示了上述带有看门狗定时器的“长时间运行的订户”解决方案：

它还可以直接用于StorageQueue事件处理程序，以从EventGrid生成长时间运行的进程，但在这种情况下，该函数有更多的职责，如重试、通知、死信等，请参见下图：