.Net 核心托管服务保证完成 [英] .Net core Hosted Services guaranteed to complete

问题描述

我正在查看 .Net-Core 2.1 新功能 托管服务，我看到它们非常相似地建模为 QueueBackgroundWorkItem

I'm looking at .Net-Core 2.1 new feature Hosted Services, I see that they are very similarly modelled to QueueBackgroundWorkItem

队列后台工作项似乎有一个限制，即任务必须在 90 秒内执行

The Queue Background work item seems to have a limitation that the task must execute within 90 seconds

AppDomain 关闭只能延迟 90 秒(实际上是 HttpRuntimeSection.ShutdownTimeout 和 processModel shutdownTimeLimit 中的最小值).如果排队的项目太多以至于无法在 90 秒内完成，ASP.NET 运行时将卸载 AppDomain，而无需等待工作项目完成.

The AppDomain shutdown can only be delayed 90 seconds (It’s actually the minimum of HttpRuntimeSection.ShutdownTimeout and processModel shutdownTimeLimit). If you have so many items queued that they can’t be completed in 90 seconds, the ASP.NET runtime will unload the AppDomain without waiting for the work items to finish.

托管服务是否有不同的行为或此限制是否仍然适用?

Do hosted services have different behaviors or does this limitation still apply?

我担心如果我在我的托管服务上排队，如果它是一个非常长时间运行的任务，它是否仍能保证完成?

I'm worried that if I queue something on my hosted service, if it's a really long running task, is it still guaranteed to complete?

推荐答案

作为尝试正常关闭 Web 主机的一部分，结合配置的 ShutdownTimeout

As part of trying to gracefully shut down the web host builds a cancellation token in combination with the configured ShutdownTimeout

var timeoutToken = new CancellationTokenSource(Options.ShutdownTimeout).Token;
if (!cancellationToken.CanBeCanceled)
{
    cancellationToken = timeoutToken;
}
else
{
    cancellationToken = CancellationTokenSource.CreateLinkedTokenSource(cancellationToken, timeoutToken).Token;
}

来源

这成为停止托管服务时的关闭令牌

This becomes the shut down token when stopping hosted services

// Fire the IHostedService.Stop
if (_hostedServiceExecutor != null)
{
    await _hostedServiceExecutor.StopAsync(cancellationToken).ConfigureAwait(false);
}

在研究托管服务的潜在问题时，我从官方文档中了解到以下内容.

In researching the potential issues with hosted services I came across the following from official documentation.

部署注意事项和要点

请务必注意，您部署 ASP.NET Core WebHost 或 .NET Core Host 的方式可能会影响最终解决方案.例如，如果您在 IIS 或常规 Azure 应用服务上部署您的 WebHost，您的主机可能会因为应用池回收而关闭.但是，如果您将主机作为容器部署到 Kubernetes 或 Service Fabric 等编排器中，则可以控制主机的有保证的活动实例数量.此外，您可以考虑云中专门针对这些场景设计的其他方法，例如 Azure Functions.

It is important to note that the way you deploy your ASP.NET Core WebHost or .NET Core Host might impact the final solution. For instance, if you deploy your WebHost on IIS or a regular Azure App Service, your host can be shut down because of app pool recycles. But if you are deploying your host as a container into an orchestrator like Kubernetes or Service Fabric, you can control the assured number of live instances of your host. In addition, you could consider other approaches in the cloud especially made for these scenarios, like Azure Functions.

但即使对于部署到应用程序池中的 WebHost，也存在重新填充或刷新应用程序的内存缓存等场景，这仍然适用.

But even for a WebHost deployed into an app pool, there are scenarios like repopulating or flushing application’s in-memory cache, that would be still applicable.

IHostedService 接口提供了一种在 ASP.NET Core Web 应用程序(在 .NET Core 2.0 中)或任何进程/主机(从 .NET Core 2.1 和 IHost 开始)中启动后台任务的便捷方法.它的主要好处是您有机会在主机本身关闭时优雅地取消清理后台任务的代码.

The IHostedService interface provides a convenient way to start background tasks in an ASP.NET Core web application (in .NET Core 2.0) or in any process/host (starting in .NET Core 2.1 with IHost). Its main benefit is the opportunity you get with the graceful cancellation to clean-up code of your background tasks when the host itself is shutting down.

现在根据您的担忧，我认为不能保证您的长期运行的任务会完成，但它们可能有机会根据托管环境正常取消，如上面引用的声明中所述.

Now from this based on your concerns I would gather that there is no guarantee that your long running tasks will complete, but they may be given the opportunity for a graceful cancellation based on the hosting environment as explained in the quoted statement above.

这篇关于.Net 核心托管服务保证完成的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！