Существует множество причин для создания длительно выполняемых служб, такие как:
Обработка данных с большим объемом ЦП.
поочередная работа с рабочими элементами в фоновом режиме;
выполнение операции ограниченное время по расписанию.
Работа фоновых служб обычно не требует пользовательского интерфейса, но пользовательские интерфейсы для них их можно создать. В первые дни с платформа .NET Framework разработчики Windows могут создавать службы Windows для этих целей. Теперь с .NET можно использовать BackgroundServiceреализацию IHostedServiceили реализовать собственную.
В .NET вы больше не ограничены средой Windows. Можно разрабатывать кроссплатформенные фоновые службы. Размещенные службы позволяют реализовать журналирование, конфигурирование и внедрение зависимостей. Они являются частью набора расширений библиотек, что означает, что они являются фундаментальными для всех рабочих нагрузок .NET, работающих с универсальным узлом.
Важно!
Установка пакета SDK для .NET также устанавливает Microsoft.NET.Sdk.Worker и шаблон рабочей роли. Другими словами, после установки пакета SDK для .NET можно создать рабочую роль с помощью команды dotnet new worker . Если вы используете Visual Studio, шаблон скрыт до установки необязательной ASP.NET и рабочей нагрузки веб-разработки.
Терминология
Существует множество терминов, которые по ошибке используются как синонимы. Этот раздел определяет некоторые из этих терминов, чтобы сделать их намерение в этой статье более очевидным.
Вызывает Run в экземпляре host, который запускает приложение.
Параметры шаблона по умолчанию
Шаблон рабочей роли не включает сборку мусора сервера (GC) по умолчанию, так как существуют многочисленные факторы, которые играют роль в определении ее необходимости. Все сценарии, требующие длительных служб, должны учитывать последствия производительности этого по умолчанию. Чтобы включить серверную сборку, добавьте узел в ServerGarbageCollection файл проекта:
Эффективное управление памятью: автоматически освобождает неиспользуемую память, чтобы предотвратить утечку памяти и оптимизировать использование ресурсов.
Улучшенная производительность в режиме реального времени: избегает потенциальных пауз или прерываний, вызванных сборкой мусора в приложениях с учетом задержки.
Долгосрочная стабильность: помогает поддерживать стабильную производительность в длительных службах, управляя памятью в течение длительных периодов.
Эффективность ресурсов: может сохранять ресурсы ЦП и памяти в средах с ограниченными ресурсами.
Сокращенное обслуживание: сводит к минимуму потребность в управлении памятью вручную, упрощая обслуживание.
Управление памятью вручную: обеспечивает точное управление памятью для специализированных приложений.
Прогнозируемое поведение: способствует согласованному и предсказуемому поведению приложения.
Подходит для кратковременных процессов: сводит к минимуму затраты на сборку мусора для кратковременных или временных процессов.
Дополнительные сведения о рекомендациях по производительности см. в разделе "Серверная сборка данных". Дополнительные сведения о настройке GC сервера см . в примерах конфигурации сервера GC.
Рабочий класс
Как и для Worker, шаблон предоставляет простую реализацию.
Приложение на основе шаблона рабочей роли использует Microsoft.NET.Sdk.Worker пакет SDK и имеет явную ссылку на пакет Microsoft.Extensions.Hosting .
Контейнеры и облачная адаптация
В большинстве современных рабочих нагрузок .NET контейнеры являются приемлемым вариантом. При создании длительной службы из шаблона рабочей роли в Visual Studio можно выбрать поддержку Docker. Это создает Dockerfile , который контейнеризирует приложение .NET. Dockerfile — это набор инструкций для создания образа. В приложениях .NET Dockerfile обычно находится в корне каталога рядом с файлом решения.
# 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"]
Для Dockerfile предусмотрены следующие этапы.
Установка базового образа из mcr.microsoft.com/dotnet/runtime:8.0 в качестве псевдонима base.
Изменение рабочего каталога на /app.
Установка псевдонима build из образа mcr.microsoft.com/dotnet/sdk:8.0.
Изменение рабочего каталога на /src.
Копирование содержимого и публикация приложения .NET:
Приложение публикуется с помощью команды dotnet publish.
Смена уровня образа пакета SDK для .NET из mcr.microsoft.com/dotnet/runtime:8.0 (псевдоним base).
Копирование опубликованных выходных данных сборки из каталога /publish.
MCR в mcr.microsoft.com означает "Microsoft Container Registry", а также является каталогом для выобъединенного контейнера Майкрософт из официального центра Docker. Дополнительные сведения см. в статье Объединение каталога контейнеров Microsoft.
При целевом использовании Docker в качестве стратегии развертывания для службы рабочей роли .NET в файле проекта есть несколько рекомендаций.
В предыдущем файле проекта элемент <DockerDefaultTargetOS> указывает Linux в качестве целевого объекта. Чтобы выбрать контейнеры Windows, используйте Windows вместо этого. Microsoft.VisualStudio.Azure.Containers.Tools.TargetsПакет NuGet автоматически добавляется в качестве ссылки на пакет, если в шаблоне выбрана поддержка Docker.
Если вы хотите использовать секреты пользователей с шаблоном рабочей роли, необходимо явно ссылаться на Microsoft.Extensions.Configuration.UserSecrets пакет NuGet.
Эти два метода служат в качестве методов жизненного цикла — они вызываются во время событий запуска и останова узла, соответственно.
Примечание
При переопределении методов StartAsync или StopAsync вы должны вызвать метод класса baseи выполнить await, чтобы обеспечить правильный запуск и (или) завершение работы службы.
Важно!
Интерфейс выступает в качестве ограничения параметра универсального типа для метода расширения AddHostedService<THostedService>(IServiceCollection), что означает, что разрешены только реализации. Вы можете использовать интерфейс, предоставленный BackgroundService с подклассом, или полностью реализовать собственный интерфейс.
Завершение сигнала
В большинстве распространенных сценариев не нужно явно сигнализировать о завершении размещенной службы. Когда узел запускает службы, они предназначены для запуска до остановки узла. Однако в некоторых сценариях может потребоваться сигнал о завершении всего ведущего приложения после завершения службы. Чтобы сигнализировать о завершении, рассмотрите следующий Worker класс:
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();
}
}
Источник этого содержимого можно найти на GitHub, где также можно создавать и просматривать проблемы и запросы на вытягивание. Дополнительные сведения см. в нашем руководстве для участников.
Отзыв о .NET
.NET — это проект с открытым исходным кодом. Выберите ссылку, чтобы оставить отзыв:
Изучите и реализуйте внедрение зависимостей в приложении ASP.NET Core. Используйте встроенный контейнер службы Core ASP.NET для управления зависимостями. Зарегистрируйте службы в контейнере службы.