消费模式Http触发Azure Function未缩容且Key Vault返回陈旧密钥问题

问题1：为什么消费模式Function App闲置超过20分钟还没缩容？ #

消费计划默认20分钟闲置销毁的规则并不是严格强制执行的，平台为了降低冷启动开销，会根据宿主机负载、函数历史调用频率等因素动态调整实例保留时长，偶尔出现实例保留超过1小时的情况属于正常现象，并不代表无服务器架构逻辑失效。

问题2：返回陈旧密钥的根因 #

你当前的实现逻辑是仅在Startup进程启动阶段一次性从Key Vault拉取密钥，且将存储密钥的IAppConfig注册为全局单例，只要Function App的宿主进程没有被销毁，这个单例对象里的密钥就不会更新，Startup逻辑也不会重复执行。只有手动重启Function App时，进程会完全销毁重建，才会重新触发密钥拉取逻辑拿到最新值，和你对无服务器架构的理解没有偏差，只是依赖实例销毁来更新密钥的方式本身不稳定。

解决方案 #

方案1（最推荐）：使用内置Key Vault引用 #

不用自己写任何Key Vault拉取代码，直接在Function App的应用配置里新增配置项DBConfig:PrimaryKey，值填写为@Microsoft.KeyVault(SecretUri=你的密钥完整URI)，平台会自动帮你完成身份校验、密钥拉取和自动轮询更新，密钥更新后最长几小时内就会自动生效，不需要重启应用也不需要改现有代码逻辑。

方案2：给密钥增加缓存过期逻辑 #

如果要保留自定义拉取密钥的逻辑，不要把密钥固定在单例AppConfig中，可以单独封装一个密钥服务，内部设置15-30分钟的缓存过期时间，每次调用密钥时先判断缓存是否过期，过期就主动重新拉取Key Vault的最新值，不依赖实例销毁更新密钥。

方案3：调整配置的注册生命周期 #

如果密钥刷新时效要求不高，也可以把IAppConfig的注册方式从单例AddSingleton改成作用域AddScoped，每次新请求进来都会重新构建配置拉取最新密钥，缺点是每次请求都会多一次配置初始化的开销，适合调用量不高的场景。

另外你目前使用的Microsoft.Azure.KeyVault属于已废弃的旧SDK，后续维护建议替换为官方最新的Azure.Security.KeyVault.SecretsSDK。

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