Serviços de trabalho no .NET

Existem inúmeras razões para a criação de serviços de longa duração, tais como:

• Processamento de dados com uso intensivo de CPU.
• Enfileiramento de itens de trabalho em segundo plano.
• Executar uma operação baseada no tempo em um cronograma.

O processamento de serviço em segundo plano geralmente não envolve uma interface do usuário (UI), mas as interfaces do usuário podem ser criadas em torno delas. Nos primórdios do .NET Framework, os desenvolvedores do Windows podiam criar os Serviços do Windows para esses fins. Agora, com o .NET, você pode usar o , que é uma implementação do IHostedService, ou implementar o BackgroundServiceseu próprio.

Com o .NET, você não está mais restrito ao Windows. Você pode desenvolver serviços em segundo plano entre plataformas. Os serviços hospedados estão prontos para registro, configuração e injeção de dependência (DI). Eles fazem parte do conjunto de extensões de bibliotecas, o que significa que são fundamentais para todas as cargas de trabalho do .NET que funcionam com o host genérico.

Terminologia

Muitos termos são erroneamente usados como sinônimos. Esta seção define alguns desses termos para tornar sua intenção neste artigo mais aparente.

• Serviço em segundo plano: O BackgroundService tipo.
• Serviço Hospedado: Implementações de IHostedService, ou o IHostedService próprio.
• Serviço de longa duração: qualquer serviço executado continuamente.
• Serviço Windows: A infraestrutura de Serviço do Windows, originalmente centrada no .NET Framework, mas agora acessível via .NET.
• Serviço do Trabalhador: O modelo do Serviço do Trabalhador.

Modelo de Serviço do Trabalhador

O modelo Worker Service está disponível na CLI do .NET e no Visual Studio. Para obter mais informações, consulte .NET CLI, dotnet new worker - template. O modelo consiste em uma Program classe e Worker .

using App.WorkerService;

HostApplicationBuilder builder = Host.CreateApplicationBuilder(args);
builder.Services.AddHostedService<Worker>();

IHost host = builder.Build();
host.Run();

A classe anterior Program :

• Cria um HostApplicationBuilderarquivo .
• Chamadas AddHostedService para registrar o Worker como um serviço hospedado.
• Constrói um IHost a partir do construtor.
• Chama Run a host instância, que executa o aplicativo.

Padrões de modelo

O modelo Worker não habilita a coleta de lixo do servidor (GC) por padrão, pois há vários fatores que desempenham um papel na determinação de sua necessidade. Todos os cenários que exigem serviços de longa execução devem considerar as implicações de desempenho desse padrão. Para habilitar o GC do servidor, adicione o ServerGarbageCollection nó ao arquivo de projeto:

<PropertyGroup>
    <ServerGarbageCollection>true</ServerGarbageCollection>
</PropertyGroup>

Compensações e considerações

Para obter mais informações sobre considerações de desempenho, consulte GC do servidor. Para obter mais informações sobre como configurar o GC do servidor, consulte Exemplos de configuração do GC do servidor.

Classe operária

Quanto ao Worker, o modelo fornece uma implementação simples.

namespace App.WorkerService;

public sealed class Worker(ILogger<Worker> logger) : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            logger.LogInformation("Worker running at: {time}", DateTimeOffset.Now);
            await Task.Delay(1_000, stoppingToken);
        }
    }
}

A classe anterior Worker é uma subclasse de BackgroundService, que implementa IHostedService. O BackgroundService é um abstract class e requer a subclasse para implementar BackgroundService.ExecuteAsync(CancellationToken). Na implementação do modelo, os ExecuteAsync loops uma vez por segundo, registrando a data e hora atuais até que o processo seja sinalizado para cancelar.

O arquivo de projeto

O modelo de trabalho depende do seguinte arquivo de Sdkprojeto:

<Project Sdk="Microsoft.NET.Sdk.Worker">

Para obter mais informações, consulte SDKs de projeto .NET.

Pacote NuGet

Um aplicativo baseado no modelo Worker usa o Microsoft.NET.Sdk.Worker SDK e tem uma referência explícita de pacote ao pacote Microsoft.Extensions.Hosting .

Contentores e adaptabilidade à nuvem

Com a maioria das cargas de trabalho .NET modernas, os contêineres são uma opção viável. Ao criar um serviço de longa execução a partir do modelo Worker no Visual Studio, você pode optar pelo suporte ao Docker. Isso cria um Dockerfile que conteineriza seu aplicativo .NET. Um Dockerfile é um conjunto de instruções para criar uma imagem. Para aplicativos .NET, o Dockerfile geralmente fica na raiz do diretório ao lado de um arquivo de solução.

# See https://aka.ms/containerfastmode to understand how Visual Studio uses this
# Dockerfile to build your images for faster debugging.

FROM mcr.microsoft.com/dotnet/runtime:8.0@sha256:e6b552fd7a0302e4db30661b16537f7efcdc0b67790a47dbf67a5e798582d3a5 AS base
WORKDIR /app

FROM mcr.microsoft.com/dotnet/sdk:8.0@sha256:35792ea4ad1db051981f62b313f1be3b46b1f45cadbaa3c288cd0d3056eefb83 AS build
WORKDIR /src
COPY ["background-service/App.WorkerService.csproj", "background-service/"]
RUN dotnet restore "background-service/App.WorkerService.csproj"
COPY . .
WORKDIR "/src/background-service"
RUN dotnet build "App.WorkerService.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "App.WorkerService.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "App.WorkerService.dll"]

As etapas anteriores do Dockerfile incluem:

• Definindo a imagem base como mcr.microsoft.com/dotnet/runtime:8.0 o alias base.
• Alterando o diretório de trabalho para /app.
• Definindo o build alias da mcr.microsoft.com/dotnet/sdk:8.0 imagem.
• Alterando o diretório de trabalho para /src.
• Copiando o conteúdo e publicando o aplicativo .NET:
  • O aplicativo é publicado usando o dotnet publish comando.
• Retransmissão da imagem do SDK do .NET a partir de mcr.microsoft.com/dotnet/runtime:8.0 (o base alias).
• Copiando a saída de compilação publicada do /publish.
• Definindo o ponto de entrada, que delega ao dotnet App.BackgroundService.dll.

Quando você direciona o Docker como uma estratégia de implantação para seu .NET Worker Service, há algumas considerações no arquivo de projeto:

<Project Sdk="Microsoft.NET.Sdk.Worker">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>true</ImplicitUsings>
    <RootNamespace>App.WorkerService</RootNamespace>
    <DockerDefaultTargetOS>Linux</DockerDefaultTargetOS>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Extensions.Hosting" Version="8.0.1" />
    <PackageReference Include="Microsoft.VisualStudio.Azure.Containers.Tools.Targets" Version="1.21.0" />
  </ItemGroup>
</Project>

No arquivo de projeto anterior, o <DockerDefaultTargetOS> elemento especifica Linux como seu destino. Para direcionar contêineres do Windows, use Windows em vez disso. O Microsoft.VisualStudio.Azure.Containers.Tools.Targets pacote NuGet é adicionado automaticamente como uma referência de pacote quando o suporte ao Docker é selecionado no modelo.

Para obter mais informações sobre o Docker com .NET, consulte Tutorial: Containerize a .NET app. Para obter mais informações sobre como implantar no Azure, consulte Tutorial: Implantar um serviço de trabalho no Azure.

Extensibilidade do serviço hospedado

A IHostedService interface define dois métodos:

• IHostedService.StartAsync(CancellationToken)
• IHostedService.StopAsync(CancellationToken)

Esses dois métodos servem como métodos de ciclo de vida - eles são chamados durante os eventos de início e parada do host, respectivamente.

Conclusão do sinal

Na maioria dos cenários comuns, você não precisa sinalizar explicitamente a conclusão de um serviço hospedado. Quando o host inicia os serviços, eles são projetados para serem executados até que o host seja interrompido. Em alguns cenários, no entanto, talvez seja necessário sinalizar a conclusão de todo o aplicativo host quando o serviço for concluído. Para sinalizar a conclusão, considere a seguinte Worker classe:

namespace App.SignalCompletionService;

public sealed class Worker(
    IHostApplicationLifetime hostApplicationLifetime,
    ILogger<Worker> logger) : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        // TODO: implement single execution logic here.
        logger.LogInformation(
            "Worker running at: {Time}", DateTimeOffset.Now);

        await Task.Delay(1_000, stoppingToken);

        // When completed, the entire app host will stop.
        hostApplicationLifetime.StopApplication();
    }
}

No código anterior, o ExecuteAsync método não faz loop e, quando está concluído, chama IHostApplicationLifetime.StopApplication().

Para obter mais informações, consulte:

• Host genérico .NET: IHostApplicationLifetime
• Host Genérico .NET: Desligamento do Host
• Host Genérico .NET: Processo de desligamento da hospedagem

Consulte também

• BackgroundService Tutoriais de subclasses:
  • Criar um serviço de fila no .NET
  • Usar serviços com escopo em um BackgroundService .NET
  • Criar um serviço do Windows usando BackgroundService o .NET
• Implementação personalizada IHostedService :
  • Implementar a IHostedService interface no .NET