Azure Durable Function+Service Bus：消息未被函数应用处理但逻辑仍执行

一、是否存在函数应用在别处运行的可能？ #

是的，这是核心怀疑点之一，常见场景包括：

• 重复部署的实例：同一订阅或其他订阅下，可能存在另一个Function App使用相同的Service Bus连接字符串监听目标队列，即使你停止当前应用，该实例仍会持续消费消息。
• 遗留测试实例：之前用于测试的Function App未被删除，或是CI/CD流程意外触发了多环境部署，生成了额外运行实例。

二、其他可能的原因 #

• 连接字符串泄露：如果Service Bus连接字符串不慎泄露，第三方服务或未授权应用可能在消费队列消息，并执行了和你代码一致的重调度逻辑。
• 预取消息的异常处理：Service Bus Trigger默认会预取一批消息到内存，若函数进程被强制终止（如意外崩溃、实例回收），预取的消息不会立刻回退队列，而是在锁过期后重新可用。但你的场景中消息被主动重调度到下周，说明有代码执行了该逻辑，除非预取消息在崩溃前已走到重调度步骤，但日志未正常输出。
• Durable Functions后台任务泄漏：极端情况下，Orchestrator或Activity函数中未正确清理的后台线程/任务，可能在函数应用停止后短暂继续运行，但Azure Functions沙箱机制通常会强制终止进程，此概率较低。

三、阻止问题的落地步骤 #

1. 排查并清理重复实例 #

• 在Azure门户的「所有资源」中搜索Function App名称，检查不同资源组、订阅下是否存在同名或类似实例。
• 检查CI/CD管道（如GitHub Actions、Azure DevOps）配置，确认是否存在自动部署到多环境的错误逻辑。
• 立刻在Service Bus门户的共享访问策略中重新生成连接字符串，并更新当前Function App的对应配置项，切断其他非法实例的连接。

2. 追踪Service Bus消息流转 #

• 在Service Bus队列概览页查看「活跃消息数」「已完成消息数」「死信消息数」，观察消息的整体流转趋势。
• 使用门户内置的Service Bus Explorer查看消息属性，重点关注Lock Owner字段，确认消费消息的实例标识。

3. 确保函数应用完全停止 #

• 停止Function App后，前往对应的应用服务计划页面，查看「实例」标签，确认所有实例已被释放（消耗计划停止后无运行实例，专用计划实例状态为停止）。
• 登录Kudu控制台，删除D:\home\site\wwwroot下的临时文件，避免残留进程或任务继续执行。

4. 强化日志追踪 #

• 在重调度逻辑的前后添加详细日志，包含消息ID、当前实例ID、时间戳等关键信息，即使无触发日志，也能通过消息ID追踪是否有代码执行了重调度操作。
• 启用Application Insights的详细追踪功能，查看依赖项调用记录，排查异常执行路径。

5. 收紧队列访问权限 #

• 为当前Function App创建专属的Service Bus访问策略，仅授予「监听」权限，避免使用具有全权限的默认策略。

四、确保仅当前函数应用运行的措施 #

• 使用专属连接字符串：为当前Function App分配唯一的Service Bus连接字符串，定期轮换，降低泄露风险。
• 资源组隔离：将Function App与Service Bus放在专属资源组中，配置严格的RBAC权限，禁止无关人员创建或修改资源。
• 禁用自动部署：若无持续部署需求，关闭Function App的自动部署功能，避免意外触发多实例部署。
• 定期资源审计：每周审计订阅下的Function App资源，确认仅存在预期运行的实例。

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