Es gibt zahlreiche Gründe für die Erstellung von Diensten mit langer Laufzeit, z. B.:
Verarbeiten CPU-intensiver Daten.
Queuing von Arbeitselementen im Hintergrund.
Ausführen eines zeitbasierten Vorgangs nach einem Zeitplan.
Die Verarbeitung von Hintergrunddiensten umfasst in der Regel keine Benutzeroberfläche, aber Benutzeroberflächen können um sie herum erstellt werden. Aus diesen Gründen konnten Windows-Entwickler in den Anfängen von .NET Framework Windows-Dienste erstellen. Nun können Sie mit .NET den BackgroundService, eine Implementierung von IHostedService, verwenden oder ihren eigenen implementieren.
Mit .NET sind Sie nicht mehr auf Windows beschränkt. Sie können plattformübergreifende Hintergrunddienste entwickeln. Gehostete Dienste sind protokollierungs-, konfigurations- und Dependency Injection(DI)-bereit. Sie sind Teil der Erweiterungssammlung von Bibliotheken, was bedeutet, dass sie für alle .NET-Workloads, die mit dem generischen Host arbeiten, von grundlegender Bedeutung sind.
Wichtig
Bei der Installation des .NET SDK werden auch Microsoft.NET.Sdk.Worker und die Workervorlage installiert. Anders ausgedrückt: Nach der Installation des .NET SDK können Sie mithilfe des Befehls dotnet new worker einen neuen Worker erstellen. Wenn Sie Visual Studio verwenden, wird die Vorlage ausgeblendet, bis die optionale ASP.NET- und Webentwicklungsworkload installiert ist.
Begriff
Viele Begriffe werden fälschlicherweise synonym verwendet. In diesem Abschnitt werden einige dieser Begriffe definiert, um ihre Absicht in diesem Artikel deutlicher zu machen.
Dienst mit langer Ausführungszeit: Jeder Dienst, der kontinuierlich ausgeführt wird.
Windows-Dienst: Die Infrastruktur des Windows-Diensts, die ursprünglich .NET Framework-zentrisch war, aber jetzt über .NET zugänglich ist
Workerdienst: Die Workerdienstvorlage
Workerdienstvorlage
Die Workerdienstvorlage ist für die .NET CLI und Visual Studio verfügbar. Weitere Informationen finden Sie unter .NET CLI, dotnet new worker: Vorlage. Die Vorlage besteht aus einer Program- und einer Worker -Klasse.
Ruft Run für die host-Instanz auf, die die App ausführt.
Vorlagenstandards
Die Worker-Vorlage aktiviert standardmäßig keine Server Garbage Collection (GC), da es zahlreiche Faktoren gibt, die bei der Bestimmung ihrer Notwendigkeit eine Rolle spielen. In allen Szenarien, in denen Dienste mit langer Ausführungszeit erforderlich sind, sollten die Auswirkungen dieser Standardeinstellung auf die Leistung berücksichtigt werden. Um die Server-GC zu aktivieren, fügen Sie der Projektdatei den Knoten ServerGarbageCollection hinzu:
Effiziente Speicherverwaltung: Übernimmt automatisch nicht genutzten Speicher, um Speicherverluste zu verhindern und die Ressourcennutzung zu optimieren.
Verbesserte Echtzeitleistung: Verhindert potenzielle Pausen oder Unterbrechungen, die durch die Garbage Collection in latenzempfindlichen Anwendungen verursacht werden.
Langfristige Stabilität: Hilft Standard stabile Leistung in langfristigen Diensten zu gewährleisten, indem der Speicher über längere Zeiträume verwaltet wird.
Ressourceneffizienz: Kann CPU- und Arbeitsspeicherressourcen in ressourcengeschränkten Umgebungen sparen.
Reduzierte Wartung: Minimiert den Bedarf an manueller Speicherverwaltung und vereinfacht die Wartung.
Manuelle Speichersteuerung: Bietet eine differenzierte Kontrolle über den Speicher für spezialisierte Anwendungen.
Vorhersehbares Verhalten: Trägt zu konsistentem und vorhersagbarem Anwendungsverhalten bei.
Geeignet für kurzlebige Prozesse: Minimiert den Aufwand der Garbage Collection für kurzlebige oder kurzlebige Prozesse.
Die vorangehende Worker-Klasse ist eine Unterklasse von BackgroundService, die IHostedService implementiert. Der BackgroundService ist ein abstract class und erfordert die Unterklasse, um BackgroundService.ExecuteAsync(CancellationToken) zu implementieren. In der Vorlagenimplementierung wird ein Mal pro Sekunde eine ExecuteAsync-Schleife erstellt, und das aktuelle Datum und die aktuelle Uhrzeit werden protokolliert, bis der Prozess abgebrochen wird.
Die Projektdatei.
Die Workervorlage basiert auf der folgenden Sdk-Projektdatei:
Eine App, die auf der Workervorlage basiert, verwendet das Microsoft.NET.Sdk.Worker SDK und verfügt über einen expliziten Paketverweis auf das Microsoft.Extensions.Hosting-Paket.
Container und Cloudanpassungsfähigkeit
Bei den meisten modernen .NET-Workloads sind Container eine praktikable Option. Wenn Sie über die Workervorlage in Visual Studio einen Dienst mit langer Ausführungszeit erstellen, können Sie Docker-Unterstützung verwenden. Dadurch wird eine Dockerfile-Datei erstellt, die Ihre .NET-App containerisiert. Eine Dockerfile-Datei ist eine Reihe von Anweisungen zum Erstellen eines Images. Bei .NET-Apps befindet sich die Dockerfile-Datei in der Regel im Stamm des Verzeichnisses neben einer Projektmappendatei.
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 /appFROM mcr.microsoft.com/dotnet/sdk:8.0@sha256:35792ea4ad1db051981f62b313f1be3b46b1f45cadbaa3c288cd0d3056eefb83 AS build
WORKDIR /srcCOPY ["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/buildFROM build AS publish
RUN dotnet publish "App.WorkerService.csproj" -c Release -o /app/publishFROM base AS final
WORKDIR /appCOPY --from=publish /app/publish .ENTRYPOINT ["dotnet", "App.WorkerService.dll"]
Die obigen Dockerfile-Schritte umfassen Folgendes:
Festlegen des Basisimages von mcr.microsoft.com/dotnet/runtime:8.0 als Alias base.
Ändern des Arbeitsverzeichnisses in /app.
Festlegen des build-Alias aus dem Image mcr.microsoft.com/dotnet/sdk:8.0.
Ändern des Arbeitsverzeichnisses in /src.
Kopieren des Inhalts und Veröffentlichen der .NET-App:
Die App wird mit dem Befehl dotnet publish veröffentlicht.
Neuschichten des .NET SDK-Image aus mcr.microsoft.com/dotnet/runtime:8.0 (base-Alias).
Kopieren der veröffentlichten Buildausgabe aus /publish.
MCR in mcr.microsoft.com steht für „Microsoft Container Registry“ und ist der syndizierte Containerkatalog von Microsoft aus dem offiziellen Docker-Hub. Der Artikel Microsoft syndicates container catalog enthält zusätzliche Details.
Wenn Sie Docker als Bereitstellungsstrategie für Ihren .NET-Workerdienst verwenden, sind in der Projektdatei einige Aspekte zu berücksichtigen:
In der obigen Projektdatei gibt das <DockerDefaultTargetOS>-Element Linux als Ziel an. Sollen Windows-Container das Ziel sein, verwenden Sie stattdessen Windows. Das Microsoft.VisualStudio.Azure.Containers.Tools.Targets NuGet-Paket wird automatisch als Paketverweis hinzugefügt, wenn Docker-Unterstützung aus der Vorlage ausgewählt wird.
Wenn Sie Benutzergeheimnisse mit der Workervorlage nutzen möchten, müssen Sie explizit auf das NuGet-Paket Microsoft.Extensions.Configuration.UserSecrets verweisen.
Erweiterbarkeit gehosteter Dienste
In der IHostedService-Schnittstelle sind zwei Methoden definiert:
Diese beiden Methoden dienen als Lebenszyklusmethoden – sie werden jeweils beim Starten und Beenden des Hosts aufgerufen.
Hinweis
Wenn die StartAsync- oder StopAsync-Methoden außer Kraft gesetzt werden, müssen Sie die base-Klassenmethode aufrufen und await verwenden, um sicherzustellen, dass der Dienst ordnungsgemäß gestartet und/oder beendet wird.
Wichtig
Die Schnittstelle dient als generische Parametereinschränkung für die Erweiterungsmethode AddHostedService<THostedService>(IServiceCollection), was bedeutet, dass nur Implementierungen zulässig sind. Sie können den bereitgestellten BackgroundService mit einer Unterklasse verwenden oder gänzlich ihren eigenen implementieren.
Signalisieren des Abschlusses
In den meisten gängigen Szenarien müssen Sie den Abschluss eines gehosteten Diensts nicht explizit signalisieren. Wenn der Host die Dienste startet, werden sie per Design so lange ausgeführt, bis der Host beendet wird. In einigen Szenarien müssen Sie jedoch möglicherweise den Abschluss der gesamten Hostanwendung signalisieren, wenn der Dienst abgeschlossen ist. Um den Abschluss zu signalisieren, ziehen Sie die folgende Worker-Klasse in Betracht:
Im vorherigen Code wird die ExecuteAsync-Methode nicht in einer Schleife ausgeführt. Wenn sie abgeschlossen ist, ruft sie IHostApplicationLifetime.StopApplication() auf.
Wichtig
Dadurch wird dem Host signalisiert, dass er beendet werden soll, und ohne den Aufruf StopApplication wird der Host auf unbestimmte Zeit weiter ausgeführt.
Die Quelle für diesen Inhalt finden Sie auf GitHub, wo Sie auch Issues und Pull Requests erstellen und überprüfen können. Weitere Informationen finden Sie in unserem Leitfaden für Mitwirkende.
Feedback zu .NET
.NET ist ein Open Source-Projekt. Wählen Sie einen Link aus, um Feedback zu geben:
Verstehen und Implementieren der Abhängigkeitsinjektion in einer ASP.NET Core-App. Verwenden Sie den integrierten Dienstcontainer von Core ASP.NET, um Abhängigkeiten zu verwalten. Registrieren Sie Dienste für den Dienstcontainer.