Azure EventGrid Webhook超时 [英] Azure EventGrid Webhook timeout

问题描述

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

解决方案

在像您这样的场景中，例如事件处理程序处理了60秒以上，可以基于重试和空字技术来实现以下目的:

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

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

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

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

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

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

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

更新:

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

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

Came to know from the documentation that timeout for webhook is 60 secs. If that's the case then are we expecting developers to do asynchronous operations? I mean what if the work that I want to do as part of the webhook takes more than 60 secs? But if we make that operation asynchronous and the work I want do as part of the webhook fails then how do we recover from that situation because we already responded event grid 200 OK. In that case - would we lose the event?

解决方案

In the scenario like yours such as the event handler processing over 60 seconds, the following can be implemented, based on the retrying and dead-lettering technique:

• use the primary event subscription with a retry policy and dead-lettering. This subscriber (function) with a binding to the storage table will handle a state of the long running (max 24 hrs) event processing and also forwarding the first event message to to the storage queue for triggering a long running process. The response from this primary subscriber will depend from the state of the StorageQueueTrigger function.

• every new retry event message will check the state of the long running process and based on that, the response code (for instance OK(200) or Service.Unavailable(503)) is sent back to the Event Grid.

In the above scenario, the retry mechanism represents a "watchdog timer" for watching a long running event message processing. The second function such as QueueTrigger function is yielding a process between the Event Grid and long running process.

In summary, your scenario will require the following:

• EventSubscriber with retry policy and dead-lettering for Webhook (EventGridTrigger or HttpTrigger function)
• EventGridTrigger or HttpTrigger function
• Storage Table
• QueueTrigger Function

If anything unusually happen during the watchdog timer, the dead-lettering is sent to your container storage with a deadLetterReason.

Note, that in the case if your long running process is over 5/10 minutes, the StorageQueue trigger needs to be considered in the App Service plan or using your custom worker processor.

Update:

The following screen snippet shows the above solution for "long running subscriber" with a Watchdog timer:

also it can be used directly a StorageQueue Event Handler to yield the long running process from the EventGrid, but in this case, the function has a more responsibilities such as retrying, notification, dead-lettering, etc., see the following picture:

这篇关于Azure EventGrid Webhook超时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！