Azure Service Fabric服务中IoC容器配置位置及销毁时机问询

兄弟，你说得对，把IoC容器配置塞到RunAsync里确实不太合适——那地方是服务启动后跑业务逻辑的，容器配置属于初始化阶段的核心工作，混在一起不仅职责不清，还容易导致容器没初始化完成就开始处理请求，踩各种坑。下面结合Azure Service Fabric的服务模型，给你讲讲约定俗成的配置位置，以及销毁方法的正确调用时机，用Simple Injector举例子，其他容器逻辑也差不多。

一、IoC容器配置的约定位置 #

Azure Service Fabric的无状态/有状态服务都有明确的初始化入口，这才是配置IoC容器的正确舞台：

1. 无状态服务（StatelessService） #

优先在服务的构造函数里完成容器注册，或者抽个单独的ConfigureContainer方法封装配置逻辑，保持代码清爽。毕竟构造函数是服务实例创建时第一个执行的地方，刚好适合做依赖注入的初始化。

给你整个Simple Injector的实操例子：

public class MyStatelessService : StatelessService
{
    private readonly Container _container;

    public MyStatelessService(StatelessServiceContext context) : base(context)
    {
        // 初始化Simple Injector容器
        _container = new Container();
        // 封装配置逻辑，避免构造函数太臃肿
        ConfigureContainer(_container);
        // 必须验证容器配置！提前揪出依赖注册错误，别等运行时崩了才发现
        _container.Verify();
    }

    private void ConfigureContainer(Container container)
    {
        // 按业务需求注册依赖：比如单例、作用域、瞬时
        container.Register<IMyBusinessService, MyBusinessService>(Lifestyle.Scoped);
        container.Register<IMyRepository, MyRepository>(Lifestyle.Singleton);
        // 如果是Web服务，还能集成ASP.NET Core的管道，把容器塞进去
        // container.RegisterMvcControllers(Assembly.GetExecutingAssembly());
    }

    protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
    {
        return new[] {
            new ServiceInstanceListener(context =>
                new KestrelCommunicationListener(context, "ServiceEndpoint", (url, listener) =>
                {
                    return new WebHostBuilder()
                        .UseKestrel()
                        // 把我们的IoC容器注册到ASP.NET Core的服务集合里
                        .ConfigureServices(services => services.AddSingleton(_container))
                        .UseContentRoot(Directory.GetCurrentDirectory())
                        .UseStartup<Startup>()
                        .UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)
                        .UseUrls(url)
                        .Build();
                }))
        };
    }
}

2. 有状态服务（StatefulService） #

逻辑和无状态服务一致，在构造函数或者CreateServiceReplicaListeners之前完成容器配置。需要注意的是，有状态服务有多副本，Singleton依赖要确保全局唯一（容器本身是每个服务实例一个，所以Singleton是实例级的，符合SF的模型），Scoped依赖则要根据请求或操作范围来管理。

二、容器销毁方法的调用时机 #

IoC容器的销毁（比如释放所有实现了IDisposable的实例）必须和服务的生命周期绑定，Azure Service Fabric提供了两个关键的回调方法：

1. 正常关闭：重写OnCloseAsync #

当服务被正常关闭（比如升级、缩放）时，SF会触发OnCloseAsync，这时候就可以调用容器的销毁逻辑：

protected override async Task OnCloseAsync(CancellationToken cancellationToken)
{
    // 释放容器，清理所有Disposable实例
    _container.Dispose();
    // 别忘了调用基类的方法，完成SF的内置清理逻辑
    await base.OnCloseAsync(cancellationToken);
}

2. 强制终止：重写OnAbort #

如果服务遇到节点故障、强制重启等情况，SF会触发OnAbort，这里也要做紧急清理：

protected override void OnAbort()
{
    _container.Dispose();
    base.OnAbort();
}

额外避坑提示 #

• Scope管理要到位：如果是处理HTTP请求的Web服务，一定要给每个请求创建独立的Scope，请求结束后释放。比如在ASP.NET Core里，可以用container.BeginLifetimeScope()手动创建，或者集成中间件自动管理Scope生命周期。
• 别重复注册：容器配置只需要在服务实例初始化时执行一次，绝对不能放到RunAsync里循环执行，否则会导致重复注册、资源泄漏。
• 容器验证不能省：container.Verify()一定要加，服务启动时就验证所有依赖是否注册正确，避免运行时出现“无法解析类型”的崩溃。

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