从文档中得知,webhook 的超时时间为 60 秒。如果是这样的话,那么我们是否期望开发人员进行异步操作?我的意思是,如果我想要作为 Webhook 的一部分完成的工作需要超过 60 秒怎么办?但是,如果我们将该操作设为异步,并且我想要作为 webhook 的一部分完成的工作失败,那么我们如何从这种情况中恢复,因为我们已经响应了事件网格 200 OK。那样的话,我们会输掉比赛吗?
在像您这样的场景中,例如事件处理程序处理超过 60 秒,可以基于重试和死信技术实现以下操作:
使用带有重试策略的主事件订阅,并且
死字。绑定到存储表的订阅者(函数)将处理长时间运行(最多 24 小时)事件处理的状态,并将第一条事件消息转发到存储队列以触发长时间运行的进程。来自该主订阅者的响应将取决于 StorageQueueTrigger 函数的状态。
每个新的重试事件消息都将检查长时间运行的进程的状态,并基于此将响应代码(例如 OK(200) 或 Service.Unavailable(503))发送回事件网格。
在上述场景中,重试机制代表“看门狗定时器”,用于监视长时间运行的事件消息处理。第二个函数(例如 QueueTrigger 函数)在事件网格和长时间运行的进程之间生成一个进程。
总之,您的场景将需要以下内容:
- 具有重试策略和 Webhook 死信的 EventSubscriber(EventGridTrigger 或 HttpTrigger 函数)
- EventGridTrigger 或 HttpTrigger 函数
- 储物桌
- 队列触发函数
如果看门狗定时器期间发生任何异常情况,死信将连同死信原因一起发送到您的容器存储中。
请注意,如果长时间运行的进程超过 5/10 分钟,则需要在应用服务计划中考虑存储队列触发器或使用自定义工作处理器。
Update:
以下屏幕片段显示了上述带有看门狗定时器的“长时间运行订阅者”的解决方案:
也可以直接使用 StorageQueue 事件处理程序从 EventGrid 中生成长时间运行的进程,但在这种情况下,该函数具有更多职责,例如重试、通知、死信等,请参见下图:
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)