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