Azure Function Event Hub触发器未使用可用主机实例扩缩容异常

这个异常是Python版Event Hub触发Azure Function的典型负载均衡失效问题，核心诱因有三个：

• 运行时版本bug：当前使用的Event Hub扩展版本存在已知缺陷，当配置VNET集成+用户分配托管标识访问关联存储账户时，新启动实例的Event Processor Host初始化阶段如果遇到托管标识令牌获取的瞬时失败，会直接终止分区认领流程且不会自动重试，只有全应用重启时所有实例同时发起初始化，才能暂时绕过这个鉴权时序问题，这也是重启可以临时恢复的原因。
• 分区租约配置不合理：默认配置下分区所有权（ownership）的过期时间长达2分钟，当已经持有分区的2台实例CPU跑满100%时，Python工作进程的事件循环被业务逻辑阻塞，既无法及时处理拉取到的消息，也无法向存储上报租约心跳，但因为租约过期时间长，其余空闲实例会判定分区仍被占用，不会发起抢注，最终存储里只会保留最开始2个实例的所有权记录。
• 扩缩容逻辑断层：ASP Premium Plan默认的扩缩容规则只感知虚拟机层面的平均CPU、内存指标，会按照阈值拉起新实例，但完全不感知Event Hub触发器的分区所有权分配状态，拉起的新实例拿不到分区就不会执行业务代码，自然会出现“实例数拉到10台但只有2台跑负载”的现象。

按以下顺序操作即可彻底解决问题，不需要定期重启：

1. 升级基础运行时组件
   • 将Azure Function Host版本升级到4.28.1及以上，Python环境下的azure-functions-eventhub扩展包升级到5.12.0及以上，该版本修复了托管标识鉴权瞬时失败时分区认领不重试的问题，同时优化了多实例下的分区负载均衡逻辑。
   • 在函数应用配置中添加FUNCTIONS_WORKER_PROCESS_COUNT参数，值设置为单实例vCPU核数（Premium Plan默认单实例2核，设为2即可），避免单Python进程被业务逻辑占满后阻塞租约续期、消息处理等后台操作。
2. 优化Event Hub触发器参数
   修改函数应用根目录下的host.json文件，调整Event Hub扩展的租约和负载均衡配置，缩短租约过期周期，加快异常场景下的分区接管速度：

   {
     "extensions": {
       "eventHubs": {
         "maxEventBatchSize": 100,
         "prefetchCount": 300,
         "leaseDuration": "00:00:30",
         "renewInterval": "00:00:10",
         "partitionOwnershipExpirationInterval": "00:01:00",
         "loadBalancingUpdateInterval": "00:00:10"
       }
     }
   }
   

3. 修正扩缩容判定规则
   不要仅使用平均CPU作为扩容触发条件，调整扩缩容逻辑匹配Event Hub的工作特性：
   • 开启函数运行时缩放监控（Runtime Scale Monitoring），让缩放控制器直接读取触发器的分区负载、消息积压数据做决策，而不是仅依赖虚拟机层面的资源指标
   • 新增Event Hub未处理消息数作为扩容触发阈值，建议设置为单分区积压超过1000条时触发扩容
   • 将函数最大实例数设置为不超过Event Hub分区数（即32），避免拉起超过分区上限的无效空闲实例
4. 配置实例健康检查
   给函数应用开启健康检查，设置判定阈值为：实例连续5分钟未持有任何分区、无消息处理流量时标记为不健康，自动触发实例替换，避免异常空闲实例长期占用资源配额。

配置完成后执行一次全量重启即可生效，压测验证时可直接查看关联存储账户中的所有权记录数，记录数会随着消息负载上升自动增长，和实际运行的业务实例数匹配，不会再出现少数实例CPU跑满、其余实例空转的问题。

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