基于App Service Plan的Service Bus队列触发Azure函数唤醒异常咨询

一、唤醒不稳定的原因与机制 #

基础版App Service Plan的函数应用，在无活动（无函数执行、无HTTP请求）的情况下，默认会在20分钟左右进入休眠状态——作业主机会停止运行，释放部分资源。

Service Bus触发器的唤醒逻辑分两种情况：

• 当函数处于休眠时，并不是函数本身在监听队列，而是由Azure的Scale Controller负责定期扫描队列状态。这个扫描有固定的时间间隔（通常是数分钟级别），如果消息刚好在扫描窗口内进入队列，就能触发Scale Controller唤醒函数主机；如果消息进入后，Scale Controller还没轮到扫描这个队列，就会出现延迟，甚至在极端情况下，因为触发器注册信息过期，导致暂时无法触发唤醒。
• 当函数处于运行状态时，触发器由函数主机直接监听队列，消息进来就能立即处理，不会有延迟。

这就是为什么会出现“有时能唤醒、有时不能”的现象——完全依赖Scale Controller的扫描时机，无法保证实时性。

二、Always On的作用、原因与后果 #

• 必须开启的原因：开启Always On后，App Service会强制保持函数的作业主机持续运行，不会进入休眠状态。此时Service Bus触发器由函数主机自身持续监听队列，消息到达即可立即处理，不再依赖Scale Controller的间隔扫描，从根源上解决唤醒不稳定的问题。
• 不开启的后果：除了唤醒延迟或失败，还可能导致消息积压、超时（如果队列消息设置了过期时间），甚至因为多次唤醒失败触发Service Bus的重试机制，造成重复处理或消息丢失。

三、Always On不影响计费却允许关闭的原因及适用场景 #

基础版App Service Plan是按实例运行时间计费的，不管函数是否休眠，实例本身始终处于部署运行状态，所以开启或关闭Always On不会改变计费金额。允许关闭的原因和适用场景包括：

• 非实时低优先级任务：比如每日定时执行的批处理任务、每月才会有几条消息的队列，休眠后的唤醒延迟完全在可接受范围内，不需要保持主机持续运行。
• 测试/开发环境：开发阶段函数不需要全天候待命，关闭Always On符合“不用则停”的直觉操作，虽然不省钱，但能避免不必要的资源占用（比如主机持续运行可能会产生冗余日志、占用内存等）。
• 操作习惯延续：这种设置延续了共享计划中的操作逻辑，部分用户更倾向于在非核心场景下关闭该功能，保持资源使用的“感知可控”。

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