.NET Conf

Współczesne aplikacje .NET coraz częściej wymagają wykonywania zadań w tle, które działają niezależnie od głównego wątku aplikacji. Worker Service oraz IHostedService to kluczowe mechanizmy umożliwiające tworzenie długotrwałych usług, zadań okresowych i przetwarzania w tle.

Spis treści [odkryj]

Technologie te zapewniają zaawansowane rozwiązania dla ciągłego monitorowania, przetwarzania danych i operacji zaplanowanych w czasie, pozostając jednocześnie w pełni zintegrowane z dependency injection, logowaniem i konfiguracją platformy .NET.

Architektura zadań w tle w .NET

Współczesne zadania w tle w .NET opierają się na zunifikowanej architekturze Generic Host, która obsługuje zarówno konfigurację, dependency injection, jak i logowanie, umożliwiając wygodne zarządzanie cyklem życia aplikacji na Windows, Linux i macOS.

Podstawowe wzorce i terminologia

W celu prawidłowego stosowania usług w tle warto rozróżnić główne terminy:

  • BackgroundService – klasa wysokopoziomowa implementująca IHostedService, zaprojektowana specjalnie dla długotrwałych zadań w tle;
  • Hosted Service – ogólna kategoria usług zarządzanych przez hosta aplikacji, zarówno implementacje interfejsu, jak i jego pochodne;
  • Long-running Service – każda usługa, która działa nieprzerwanie przez dłuższy czas, niezależnie od sposobu implementacji;
  • Windows Service – klasyczne usługi typowe dla środowiska Windows, teraz dostępne także w .NET Core i .NET z dedykowanymi bibliotekami;
  • Worker Service template – szablon dostępny w CLI i Visual Studio, stanowiący bazę do budowy nowoczesnych usług w tle.

Wybór implementacji zależy od potrzeb: BackgroundService to dobry wybór dla prostych scenariuszy, natomiast czysty IHostedService pozwala na bardziej zaawansowaną kontrolę cyklu życia.

Wzorce projektowe i dependency injection

Architekturę zadań w tle w .NET charakteryzuje kilka kluczowych wzorców projektowych, do których zaliczają się:

  • Dependency Injection – upraszcza rejestrację i zarządzanie zależnościami w usługach w tle;
  • Observer z użyciem CancellationToken – pozwala na współpracujące i łagodne anulowanie operacji;
  • Template Method – wykorzystywany w BackgroundService; implementowana metoda ExecuteAsync definiuje specyficzną logikę, podczas gdy cyklem życia usługi zarządza framework.

Tego typu wzorce gwarantują wysoką czytelność kodu, testowalność oraz spójność działania, nawet w sytuacjach awaryjnych i podczas zamykania aplikacji.

Interfejs IHostedService – teoria i praktyka

Kluczowe elementy interfejsu

Interfejs IHostedService definiuje dwa główne punkty startowe dla każdej usługi w tle:

  • StartAsync(CancellationToken) – inicjalizuje usługę oraz jej zasoby podczas uruchamiania aplikacji;
  • StopAsync(CancellationToken) – odpowiada za łagodne zamknięcie i zwolnienie wszystkich wykorzystywanych zasobów.

Rejestracja implementacji IHostedService odbywa się przez metodę AddHostedService<T> i domyślnie nadaje instancji zakres singleton, co zapewnia deterministyczne zarządzanie cyklem życia usług podczas działania aplikacji.

Usługi okresowe i zarządzanie timerami

Implementując zadania cykliczne w .NET, możesz wykorzystać różne mechanizmy zarządzania czasem:

  • klasę Timer (klasyczne podejście z .NET Framework),
  • PeriodicTimer (od .NET 6) – lepiej integruje się z async/await i zapewnia przewidywalność działania,
  • niskopoziomowe mechanizmy synchronizacji, takie jak SemaphoreSlim lub Interlocked dla ograniczania równoległości i zabezpieczenia dostępu do współdzielonych zasobów.

Ważne jest, aby stosować poprawne uwalnianie zasobów i dokładnie obsługiwać scenariusze anulowania oraz sytuacje brzegowe związane z nieukończonymi operacjami.

Zarządzanie zasobami i wzorzec Dispose

Kluczową praktyką jest implementacja IDisposable lub IAsyncDisposable, co pozwala na skuteczne oczyszczanie zasobów, niezależnie czy dotyczą one połączeń sieciowych, timerów czy obiektów zarządzanych przez framework. Stosowanie bloków try-catch oraz logowanie błędów podczas czyszczenia zasobów zapobiega maskowaniu błędów i utracie istotnych informacji.

Szablon Worker Service – zastosowanie praktyczne

Struktura i konfiguracja szablonu

Worker Service to szablon stanowiący punkt wyjścia dla nowoczesnych aplikacji serwisowych w .NET. Oparty jest na prostej strukturze zawierającej klasę Program oraz dziedziczącą po BackgroundService klasę Worker.

  • klasa Program – konfiguruje Generic Host i DI, uruchamia aplikację;
  • Worker – dziedziczy po BackgroundService i implementuje ExecuteAsync (główną logikę biznesową);
  • szkielet oparty o Microsoft.NET.Sdk.Worker zapewnia optymalne ustawienia, jak opcjonalne Server GC.

W ramach szablonu łatwo wdrożyć rozszerzone logowanie, monitoring czy integrację ze środowiskami chmurowymi.

Dostosowanie pod środowisko produkcyjne

Poniżej przedstawiamy główne aspekty, na które należy zwrócić uwagę podczas wdrożeń produkcyjnych:

  • kontrola timeoutów zamykania usług (HostOptions, ShutdownTimeout);
  • włączenie ServerGarbageCollection dla lepszej obsługi zadań wielowątkowych;
  • rozbudowa systemu logowania o strukturalne logi i integrację z Application Insights lub innymi narzędziami do monitoringu;
  • elastyczne wdrożenia: usługi mogą być uruchamiane jako standalone executables, kontenery lub klasyczne Windows Services.

Rzetelna konfiguracja monitoringu i logowania pozwala na szybką identyfikację problemów, dobór odpowiedniej strategii rotacji logów i zachowanie odpowiedniej wydajności w środowisku produkcyjnym.

BackgroundService – długotrwałe zadania w tle

Kluczowe cechy BackgroundService

BackgroundService specjalizuje się w obsłudze zadań długotrwałych, opierając się na wzorcu Template Method: framework wywołuje StartAsync/StopAsync, a deweloperzy implementują tylko ExecuteAsync, gdzie zawiera się cała logika zadania.

  • StartAsync – uruchamia zadanie w tle;
  • ExecuteAsync – pętla głównego zadania, która powinna regularnie sprawdzać otrzymany CancellationToken;
  • StopAsync – łagodne zamykanie, z możliwością rozszerzenia o własną logikę sprzątania.

Rozdzielenie długotrwałych operacji od inicjalizacji umożliwia niezawodną i skalowalną współpracę usług w tle z aplikacją główną.

Wzorce implementacyjne i odporność na błędy

Implementując zadania długotrwałe z wykorzystaniem BackgroundService, najczęściej stosuje się poniższe wzorce:

  • ciągła pętla z użyciem PeriodicTimer (od .NET 6, zamiast klasycznego Thread.Sleep);
  • obsługa kolejek w tle (BlockingCollection, Channel);
  • rozbudowana obsługa błędów i logiki retry (policies), w tym circuit breaker i kolejki błędów;
  • integracja ze strukturą IHealthCheck do monitorowania stanu usługi;
  • obsługa wyjątków – nieobsłużony wyjątek zamyka całą aplikację, stąd wszystkie kluczowe operacje powinny być chronione blokiem try-catch.

Odporność usług na błędy to fundament niezawodnego działania aplikacji, również w przypadku nagłych awarii zewnętrznych zależności lub niespodziewanego zamknięcia aplikacji.

Dependency injection i obsługa usług scoped

Jak bezpiecznie korzystać z usług scoped w singletonach?

Instancje BackgroundService są singletonami, dlatego nie można bezpośrednio wstrzykiwać do nich usług o zasięgu scoped przez konstruktor, ponieważ kontener DI zgłosi błąd.

Aby obsłużyć ten przypadek:

  • wstrzykuj IServiceScopeFactory do konstruktora;
  • twórz nowy scope za pomocą serviceScopeFactory.CreateScope() w metodzie ExecuteAsync;
  • korzystaj z usług scoped wewnątrz utworzonego scope;
  • wszystko, co implementuje IDisposable, zostanie automatycznie zwolnione wraz z końcem scope.

Takie podejście zapewnia poprawną izolację kontekstów oraz pozwala na wydajne zarządzanie DbContext i innymi usługami wymagającymi zakreślonego czasu życia.

CancellationToken – anulowanie operacji

Mechanizmy i dobre praktyki anulowania operacji

CancellationToken to standardowy mechanizm do kooperatywnego anulowania operacji w .NET (od wersji 4). Kod powinien regularnie sprawdzać stan tokena i kończyć operacje łagodnie, wykorzystując przewidziane timeouty:

  • token przekazywany do metody (np. ExecuteAsync) powinien być cyklicznie sprawdzany;
  • w sytuacji zamykania aplikacji framework przekazuje token z domyślnym timeoutem (zwykle 5 sekund), po którym wymagane są operacje cleanup;
  • HostOptions.ShutdownTimeout pozwala konfigurować czas łagodnego zamykania usług w tle.

Prawidłowa obsługa tokenów gwarantuje spójność stanu, chroni przed wyciekami zasobów i umożliwia szybkie reagowanie na polecenie zamknięcia aplikacji.

Integracja z ASP.NET Core

Rejestracja i obsługa hostowanych usług w ASP.NET Core

Aplikacje ASP.NET Core integrują zadania w tle korzystając z AddHostedService. Usługi są uruchamiane przed przyjęciem pierwszego żądania i zamykane po obsłużeniu wszystkich połączeń. Współdzielenie Hostów oraz możliwość rejestracji wielu hostowanych usług pozwalają na realizację skomplikowanych scenariuszy przetwarzania w tle:

  • notyfikacje i powiadomienia dla użytkowników,
  • cykliczne integracje z innymi systemami,
  • zadania administracyjne i sprzątanie danych.

Integracja z SignalR pozwala na komunikację w czasie rzeczywistym z klientami; IHubContext jest dostępny dla usług w tle poprzez dependency injection.

Projektowanie pod kątem wydajności i skalowanie

Zadania w tle współdzielą zasoby z web pipeline, przez co wymagają optymalnej alokacji pamięci, CPU i przypisania puli wątków. W środowiskach skalowalnych (np. Kubernetes) stosuje się rozproszone kolejki i locki, by uniknąć podwójnego przetwarzania oraz zapewnić wydajność i odporność całego systemu.

Zaawansowane wzorce optymalizacyjne

Wzorce kolejkowania i monitoringu

Dla wysokowydajnych zadań w tle warto zastosować:

  • wzorzec producent–konsument dla oddzielenia generowania i realizacji zadań,
  • kolejki z priorytetami, dead letter queue, integrację z Azure Service Bus lub AWS SQS,
  • BlockingCollection/Channel w pamięci dla prostych rozwiązań,
  • rozproszone kolejki oparte na bazie danych dla trwałych scenariuszy.

Monitorowanie metryk, długości kolejek i liczników błędów jest kluczowe dla identyfikowania problemów i zapewnienia ciągłości działania.

Zarządzanie pamięcią i wydajnością

Wydajne działanie usług w tle wymaga odpowiedniego zarządzania pamięcią:

  • analiza alokacji obiektów (profiling, generational GC),
  • zarządzanie pulą połączeń do bazy danych oraz cyklem życia DbContext,
  • stosowanie Server GC dla aplikacji wielowątkowych,
  • monitorowanie puli wątków ThreadPool i dynamiczne dostosowanie współbieżności zadań.

Optymalizacja tych aspektów wpływa bezpośrednio na wydajność oraz stabilność aplikacji i zapobiega degradacji działania na przestrzeni długiego czasu.

Najlepsze praktyki wdrożeniowe

Testowanie usług w tle

Testowanie usług w tle w .NET powinno wykorzystywać:

  • mockowanie zależności (DI) dla testów jednostkowych,
  • mockowanie CancellationToken i IServiceScopeFactory do testowania obsługi anulowań i usług scoped,
  • testy integracyjne symulujące ograniczenia zasobów i awarie zależności,
  • pipeline CI z automatycznymi testami wydajnościowymi i regresyjnymi.

Prawidłowe testy zapewniają odporność wdrożenia, szybkie wykrywanie regresji i niskie ryzyko problemów produkcyjnych.

DevOps i wdrażanie

Nowoczesne usługi w tle można wdrażać elastycznie i bezpiecznie stosując:

  • konteneryzację z Docker i wdrażanie na Kubernetes,
  • specjalne endpointy health check dla łatwej integracji z orkiestratorami,
  • separację konfiguracji środowiskowej (ConfigMap, Secret, Azure Key Vault),
  • monitoring i autoskalowanie w oparciu o rzeczywiste zużycie zasobów.

Bezpieczeństwo kluczy, walidacja konfiguracji i monitoring integralności aplikacji to podstawowe elementy każdej poważnej strategii DevOps dla aplikacji w tle.

Bezpieczeństwo i zgodność

Obsługa danych wrażliwych w usługach w tle wymaga spełnienia wysokich standardów bezpieczeństwa i zgodności z regulacjami:

  • szyfrowanie w spoczynku i w transferze,
  • autentykacja i autoryzacja dla endpointów administracyjnych,
  • strukturalne logowanie z identyfikatorami korelacyjnymi dla audytu,
  • spełnienie wymogów RODO, HIPAA, PCI DSS,
  • regularne testy penetracyjne oraz procedury reagowania na incydenty.

Kwestie bezpieczeństwa dotyczą nie tylko samej logiki aplikacji, ale także strategii przechowywania, retencji logów i ochrony dostępu do infrastruktury operacyjnej.