从文档中得知，webhook 的超时时间为 60 秒。如果是这样的话，那么我们是否期望开发人员进行异步操作？我的意思是，如果我想要作为 Webhook 的一部分完成的工作需要超过 60 秒怎么办？但是，如果我们将该操作设为异步，并且我想要作为 Webhook 的一部分完成的工作失败，那么我们如何从这种情况中恢复，因为我们已经响应了事件网格 200 OK。那样的话，我们会输掉比赛吗？
最佳答案
在像您这样的场景中，例如事件处理程序处理超过 60 秒，可以基于重试和死信技术实现以下操作:
使用带有重试策略的主事件订阅，并且 死字。绑定(bind)到存储表的订阅者(函数)将处理长时间运行(最多 24 小时)事件处理的状态，并将第一条事件消息转发到存储队列以触发长时间运行的进程。来自该主订阅者的响应将取决于 StorageQueueTrigger 函数的状态。
每条新的重试事件消息都会检查长时间运行的进程的状态，并根据该状态将响应代码(例如 OK(200) 或 Service.Unavailable(503))发送回事件网格。
在上述场景中，重试机制代表一个“看门狗定时器”，用于监视长时间运行的事件消息处理。第二个函数(例如 QueueTrigger 函数)在事件网格和长时间运行的进程之间生成一个进程。
总而言之，您的场景将需要以下内容:
- 具有重试策略和 Webhook 死信功能的 EventSubscriber(EventGridTrigger 或 HttpTrigger 函数)
- EventGridTrigger 或 HttpTrigger 函数
- 储物 table
- 队列触发函数
如果在看门狗计时器期间发生任何异常情况，死信将通过 deadLetterReason 发送到您的容器存储。
请注意，如果您的长时间运行进程超过 5/10 分钟，则需要在应用服务计划中考虑 StorageQueue 触发器或使用自定义工作处理器。
更新:
以下屏幕片段显示了上述带有看门狗定时器的“长时间运行订阅者”的解决方案:
也可以直接使用 StorageQueue 事件处理程序从 EventGrid 中生成长时间运行的进程，但在这种情况下，该函数具有更多职责，例如重试、通知、死信等，请参见以下内容图片:
关于Azure EventGrid Webhook 超时，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51552231/