Azure Function如何实现多环境隔离执行的依赖注入方案？

问题背景 #

当前部署的Azure Function应用通过FunctionsStartup特性实现依赖注入，原有功能运行正常，后续收到多环境运行适配需求：测试团队认为向7个不同环境分别部署应用的流程过于繁琐，要求调整函数结构，支持通过循环逻辑覆盖所有环境执行，核心要求是同时支持7套独立的IConfiguration配置，以及7组相互隔离的服务IOC注册。

现存问题 #

目前找不到无需大幅重构抽象解析逻辑的实现方案：即便通过循环完成服务注册、注入服务的IEnumerable实例，容器在解析子依赖时也只会返回最后一次注册的实现，无法匹配当前循环迭代项对应的实例。
当前使用Autofac编写的无效实现示例如下：

服务注册代码 #

foreach (var configuration in configurations)
{
    containerBuilder.Register<ICosmosDbService<AccountUsage>>(sp =>
    {
        var dBConfig = CosmosDBHelper.GetProjectDatabaseConfig(configuration.Value, Project.Jupiter);
        return CosmosClientInitializer<AccountUsage>.Initialize(dBConfig);
    }).As<ICosmosDbService<AccountUsage>>();
}

服务调用代码 #

private readonly IEnumerable<IAccountUsageService> _accountUsageService;

public JobScheduler(IEnumerable<IAccountUsageService> accountUsageService)
{
    _accountUsageService = accountUsageService;
}
    
[FunctionName("JobScheduler")]
public async Task Run([TimerTrigger("0 */2 * * * *")] TimerInfo myTimer, ILogger log)
{
    log.LogInformation($"Job Scheduler Timer trigger function executed at: {DateTime.Now}");

    try
    {
        foreach (var usageService in _accountUsageService)
        {
            var logs = await usageService.GetCurrentAccountUsage("gfkjdsasjfa");
            // ...
        }
    }

上述DI使用方式不符合容器注册逻辑，实际无法正常运行。

核心疑问：是否存在可行的Azure Function结构设计方案，能够以隔离的方式支持不同配置下的逻辑执行？还是该需求本身违背了这个技术栈的设计初衷？

可行解决方案 #

这个需求不违背Azure Function的设计初衷，不需要大幅重构现有逻辑，核心问题是默认DI注册逻辑下，无标识的同接口重复注册会被最后一次注册覆盖，直接注入IEnumerable拿到的实例，其内部子依赖的构建逻辑没有和环境做绑定，自然会串到最后一次注册的配置。两种最小改动的落地方式可选：

• 方式1：Autofac命名注册配合解析上下文
  注册阶段给每个环境的服务绑定唯一名称标识，不要直接注册为As<ICosmosDbService<AccountUsage>>()，而是用Named<ICosmosDbService<AccountUsage>>($"env_{envName}")注册，所有同环境的依赖都绑定同一个命名标识。再额外注册一个根级的环境服务工厂，工厂内部持有所有环境的配置列表和IComponentContext解析上下文，调用时按环境名解析对应命名的服务实例即可，不会出现注册覆盖的问题。
• 方式2：独立子容器隔离（推荐，改动最小）
  为每个环境创建独立的Autofac子容器/生命周期作用域，每个子容器单独完成该环境下的配置加载、服务注册，完全和其他环境的注册隔离。根容器只注册一个多环境执行器，用来管理所有子容器的生命周期，执行循环时直接从对应环境的子容器解析完整服务链，子依赖不会串环境。这种方式对原有服务的注册逻辑改动最小，原有单环境的注册代码可以原封不动放到每个子容器的初始化逻辑里，只需要传入对应环境的配置实例即可，后续如果切回单环境部署也不需要改业务代码。

不要试图让DI容器直接返回一组带独立子依赖的同接口实例，DI容器的注册是和作用域绑定的，没有上下文标识的情况下无法自动区分你要哪个环境的依赖链，上述两种方案都不需要修改原有业务服务的抽象定义，只需要在外层加一层环境隔离的包装逻辑即可。

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