Azure EventGrid Webhook超时

Question

从文档中知道Webhook的超时时间为60秒。如果是这样，那么我们是否期望开发人员执行异步操作？我的意思是，如果我想作为网络挂钩的一部分工作花费超过60秒的时间怎么办？但是，如果我们使该操作异步进行，并且作为webhook的一部分我想做的工作失败了，那么我们如何从这种情况中恢复，因为我们已经响应了事件网格200 OK。在这种情况下-我们会输掉比赛吗？

Answer 1

在像您这样的场景中，例如事件处理程序处理了60秒以上，可以基于重试和死信技术实现以下内容：

• 使用具有重试策略的主事件订阅，并 死字法。具有绑定到存储表的订户（功能）将处理长时间运行（最多24小时）事件的状态，还将第一事件消息转发到存储队列以触发长时间运行的过程。来自此主订户的响应将取决于StorageQueueTrigger函数的状态。

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

在上述情况下，重试机制表示用于监视长时间运行的事件消息处理的“看门狗计时器”。诸如QueueTrigger函数之类的第二个函数是在事件网格和长时间运行的过程之间产生一个过程。

总而言之，您的方案将需要以下条件：

• 具有重试策略的EventSubscriber和Webhook的死字母标记（EventGridTrigger或HttpTrigger函数）
• EventGridTrigger或HttpTrigger函数
• 存储表
• QueueTrigger函数

如果在看门狗定时器中发生任何异常情况，则死信将通过deadLetterReason发送到您的容器存储中。

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

更新：

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

它也可以直接用于StorageQueue事件处理程序以从EventGrid产生长时间运行的进程，但是在这种情况下，该函数承担更多的责任，例如重试，通知，死信等，请参阅以下内容图片：