Azure Logic App崩溃时如何避免请求丢失？基础设施级方案咨询

针对你提到的Logic App完全崩溃后无法向调用方返回结果的问题，以下是基于Azure原生基础设施的低复杂度解决方案，无需大量自定义开发：

1. 跨区域部署备用Logic App实现故障转移 #

• 在另一个Azure区域部署同配置的Logic App，作为主Logic App的灾难恢复端点。
• 给Event Grid订阅添加两个端点：主区域Logic App设置为高优先级，备用区域Logic App设置为低优先级。当主Logic App完全崩溃无法响应时，Event Grid自动将事件路由到备用端点。
• 结合Event Grid的TTL配置，即使备用电端点也故障，事件会在重试耗尽后触发死信，同时通过Azure原生告警通知调用方返回“失败”，确保结果不丢失。

2. 配置Event Grid死信队列+原生告警兜底 #

• 为Event Grid订阅配置死信队列（关联Azure Storage Account的队列或容器），当Logic App完全崩溃导致事件无法被处理时，事件在达到重试次数/TTL后自动进入死信队列。
• 配置Azure Monitor告警规则，监控死信队列的消息新增量，一旦触发告警，直接通过Webhook/邮件等方式通知调用方返回“失败”。
• 后续可从死信队列中恢复事件，待Logic App恢复后重新处理，完全依赖Azure原生服务，无需额外代码开发。

3. 启用Logic App的区域冗余/多实例高可用 #

• 对于消耗型Logic App：启用区域冗余选项，让Logic App实例分布在同一区域的多个可用区，避免单个可用区故障导致服务完全崩溃。
• 对于标准型Logic App：部署多实例并启用自动缩放，配合App Service的健康检查，单个实例崩溃时其他实例可继续处理Event Grid事件，原有超时机制依然有效，能正常返回结果。

关于你提到的自定义方案的补充说明 #

• 独立定时器方案：不属于基础设施级机制，需要自定义开发调度逻辑，且定时器本身存在故障风险，可靠性不如Azure原生故障转移。
• Function App监控状态方案：需要额外开发状态记录、监控和重试逻辑，复杂度高于原生方案，仅建议在有特殊业务流程需求时使用。

内容的提问来源于stack exchange，提问作者Toby Yoo