Freigeben über

Bewährte Methoden für Hintergrundaufträge

Viele Arten von Anwendungen erfordern Hintergrundaufgaben, die unabhängig von der Benutzeroberfläche ausgeführt werden. Beispiele hierfür sind Batchaufträge, intensive Verarbeitungsaufgaben und lange ausgeführte Prozesse wie Workflows. Hintergrundaufträge werden ohne Benutzerinteraktion ausgeführt. Die Anwendung startet den Auftrag und verarbeitet weiterhin interaktive Anforderungen von Benutzern. Durch diesen Ansatz wird die Auslastung der Benutzeroberfläche der Anwendung minimiert, wodurch die Verfügbarkeit verbessert und interaktive Reaktionszeiten reduziert werden.

Wenn eine Anwendung beispielsweise Miniaturansichten von Bildern generieren muss, die Benutzer hochladen, kann sie diese Arbeit als Hintergrundauftrag ausführen und die Miniaturansicht nach Abschluss im Speicher speichern. Der Benutzer muss nicht warten. Ebenso kann ein Benutzer, der eine Bestellung aufgibt, einen Hintergrund-Workflow initiieren, der die Bestellung verarbeitet, während die Benutzeroberfläche es ihm erlaubt, die Web-App weiter zu durchsuchen. Nach Abschluss des Hintergrundauftrags werden die gespeicherten Bestelldaten aktualisiert und eine E-Mail an den Benutzer gesendet, um die Bestellung zu bestätigen.

Wenn Sie überlegen, ob eine Aufgabe als Hintergrundauftrag implementiert werden soll, ist das Hauptkriterium, ob die Aufgabe ohne Benutzerinteraktion ausgeführt werden kann und ohne dass die Benutzeroberfläche auf den Abschluss warten muss. Aufgaben, bei denen der Benutzer oder die Benutzeroberfläche warten müssen, während sie abgeschlossen werden, sind möglicherweise nicht als Hintergrundaufträge geeignet.

Tipp

Dieser Artikel enthält Architekturanleitungen zum Entwerfen von Hintergrundauftragssystemen in Azure. Es umfasst Hostingoptionen, Designprinzipien, Zuverlässigkeit, Sicherheit, Observierbarkeit und Skalierung. Wenn Sie eine Zuverlässigkeitsprüfung einer vorhandenen Workload durchführen, die Hintergrundaufträge verwendet, finden Sie im Azure Well-Architected Framework unter Empfehlungen für die Entwicklung von Hintergrundaufträgen eine fokussierte Checkliste der Zuverlässigkeitsanforderungen.

Arten von Hintergrundaufträgen

Hintergrundaufträge umfassen in der Regel einen oder mehrere der folgenden Arten von Aufträgen:

  • CPU-intensive Aufträge, z. B. mathematische Berechnungen oder Strukturmodellanalyse.

  • Eingabe- und Ausgabe-intensive Aufträge, wie eine Reihe von Speichertransaktionen oder Dateiindizierungen.

  • Batchaufträge, z. B. Nachtdatenaktualisierungen oder geplante Verarbeitung.

  • Lang andauernde Workflows, wie die Auftragserfüllung oder die Bereitstellung von Diensten und Systemen.

  • Verarbeitung vertraulicher Daten, in der Sie die Aufgabe an einen sichereren Ort zur Verarbeitung senden. Beispielsweise möchten Sie möglicherweise keine vertraulichen Daten in einer Web-App verarbeiten. Sie können stattdessen ein Muster wie das Gatekeeper-Muster verwenden, um die Daten an einen isolierten Hintergrundprozess zu übertragen, der auf geschützten Speicher zugreifen kann.

Auslöser

Sie können Hintergrundaufträge auf verschiedene Arten initiieren. Sie fallen in eine der folgenden Kategorien:

  • Ereignisgesteuerte Trigger: Ein Ereignis, in der Regel eine Benutzeraktion oder ein Schritt in einem Workflow, startet die Aufgabe.

  • Zeitplangesteuerte Trigger: Ein Timer ruft den Vorgang in einem wiederkehrenden Zeitplan oder als einzelner Aufruf zu einem bestimmten Zeitpunkt auf.

Ereignisgesteuerte Auslöser

Der ereignisgesteuerte Aufruf verwendet einen Trigger, um die Hintergrundaufgabe zu starten. Beispiele für ereignisgesteuerte Auslöser sind:

  • Die Benutzeroberfläche oder ein anderer Auftrag platziert eine Nachricht in einer Warteschlange. Die Nachricht enthält Daten zu einer Aktion, die aufgetreten ist, z. B. der Benutzer, der eine Bestellung platziert. Die Hintergrundaufgabe überwacht diese Warteschlange auf neue Nachrichten. Sie liest eine Nachricht und verwendet die Daten als Eingabe für den Hintergrundauftrag. Dieses Muster wird als asynchrone nachrichtenbasierte Kommunikation bezeichnet.

  • Die Benutzeroberfläche oder ein anderer Auftrag speichert oder aktualisiert einen Wert im Speicher. Die Hintergrundaufgabe überwacht den Speicher und erkennt Änderungen. Sie liest die Daten und verwendet sie als Eingabe für den Hintergrundauftrag.

  • Die Benutzeroberfläche oder ein anderer Auftrag sendet eine Anforderung an einen Endpunkt, z. B. einen HTTPS Uniform Resource Identifier (URI) oder eine API, die als Webdienst verfügbar gemacht wird. Sie übergibt die zum Abschließen der Hintergrundaufgabe erforderlichen Daten als Teil der Anforderung. Der Endpunkt oder Webdienst ruft die Hintergrundaufgabe auf, die die Daten als Eingabe verwendet.

Typische Beispiele für Aufgaben, die für ereignisgesteuerte Aufrufe geeignet sind, sind Bildverarbeitung, Workflows, Senden von Informationen an Remotedienste, Senden von E-Mail-Nachrichten und Bereitstellen neuer Benutzer in mehrinstanzenfähigen Anwendungen.

Zeitplangesteuerte Auslöser

Der plangesteuerte Aufruf verwendet einen Timer, um die Hintergrundaufgabe zu starten. Beispiele für zeitplangesteuerte Auslöser sind:

  • Ein Timer, der lokal innerhalb der Anwendung oder als Teil des Betriebssystems der Anwendung ausgeführt wird, ruft regelmäßig eine Hintergrundaufgabe auf.

  • Ein Zeitgeber, der in einer anderen Anwendung ausgeführt wird, z. B. Azure Logic Apps, sendet regelmäßig eine Anforderung an eine API oder einen Webdienst. Die API oder der Webdienst ruft die Hintergrundaufgabe auf.

  • Ein separater Prozess oder eine separate Anwendung startet einen Timer, der die Hintergrundaufgabe einmal nach einer bestimmten Zeitverzögerung oder zu einem bestimmten Zeitpunkt startet.

Typische Beispiele für Aufgaben, die für den plangesteuerten Aufruf geeignet sind, sind Batchverarbeitungsroutinen (z. B. Aktualisieren von Listen mit verwandten Produkten für Benutzer basierend auf ihrem aktuellen Verhalten), routinebasierte Datenverarbeitungsaufgaben (z. B. Aktualisieren von Indizes oder Generieren von gesammelten Ergebnissen), Datenanalysen für tägliche Berichte, Datenaufbereinigung und Datenkonsistenzprüfungen.

Wenn Sie einen zeitplangesteuerten Vorgang verwenden, der als einzelne Instanz ausgeführt werden muss, beachten Sie die folgenden Überlegungen:

  • Wenn Sie die Computeinstanz skalieren, die den Scheduler ausführt, z. B. einen virtuellen Computer (VM), der geplante Windows-Aufgaben verwendet, erstellen Sie mehrere Schedulerinstanzen. Diese Instanzen können mehrere Kopien der Aufgabe starten. Entwerfen Sie geplante Vorgänge so, dass sie idempotent sind , sodass das Ausführen desselben Vorgangs mehr als einmal keine doppelten Ergebnisse oder Inkonsistenzen erzeugt.

  • Wenn Vorgänge länger als der Zeitraum zwischen Planerereignissen ausgeführt werden, kann der Planer eine andere Instanz des Vorgangs starten, während die vorherige Instanz ausgeführt wird.

Ergebnisse zurückgeben

Hintergrundaufträge werden asynchron in einem separaten Prozess oder sogar an einem separaten Speicherort von der Benutzeroberfläche oder dem Prozess ausgeführt, der sie aufgerufen hat. Im Idealfall werden Hintergrundaufgaben ausgelöst und vergessen , und der Verarbeitungsfortschritt hat keine Auswirkungen auf die Benutzeroberfläche oder den aufrufenden Prozess. Der Aufrufvorgang wartet nicht auf den Abschluss der Aufgabe und kann nicht automatisch erkennen, wann die Aufgabe endet.

Wenn Sie eine Hintergrundaufgabe benötigen, um mit der aufrufenden Aufgabe zu kommunizieren, um den Fortschritt oder den Abschluss anzugeben, müssen Sie einen Mechanismus für diese Aufgabe implementieren. Zu den Optionen gehören:

  • Gibt einen Statusendpunkt an den Aufrufer zurück. Der Aufrufer erhält eine URL (oder einen Ressourcenbezeichner), nachdem er den Auftrag übermittelt hat, und fragt diesen Endpunkt nach dem Status ab. Das Muster "Asynchrone Request-Reply " beschreibt diesen Ansatz. Es eignet sich für HTTP-basierte APIs, bei denen der Aufrufer einen langdauernden Vorgang initiiert und den Abschluss überprüfen muss.

  • Verwenden Sie eine Antwortwarteschlange. Die Hintergrundaufgabe sendet Nachrichten an eine Warteschlange, auf die der Anrufer lauscht. Die Nachrichten geben den Status und den Abschluss an. Wenn Sie Azure Service Bus verwenden, können Sie die Eigenschaften ReplyTo und CorrelationId nutzen, um Antworten mit Anfragen zu korrelieren.

  • Pushbenachrichtigungen über Ereignisse. Die Hintergrundaufgabe veröffentlicht ein Ereignis, wenn es abgeschlossen ist, oder bei wichtigen Meilensteinen. Der Aufrufer abonniert diese Ereignisse. Dieser Ansatz passt zu Azure Event Grid für cloud-natives Ereignisrouting oder einen Veröffentlichungs- und Abonnementmechanismus wie Service Bus Topics.

  • Rufen Sie den Anrufer über einen Webhook zurück. Der Aufrufer stellt eine Rückruf-URL bereit, wenn er den Auftrag sendet. Die Hintergrundaufgabe sendet eine HTTP-Anforderung an diese URL, wenn die Verarbeitung abgeschlossen ist oder fehler auftreten. Dieser Ansatz ist nützlich, wenn der Aufrufer ein externes System ist.

  • Schreibe den Status in den freigegebenen Speicher. Die Hintergrundaufgabe schreibt den Fortschritt oder die Ergebnisse in einen freigegebenen Datenspeicher, z. B. eine Datenbank oder ein Blob, die der Aufrufer überwacht. Dieser Ansatz ist einfach, erfordert jedoch, dass der Aufrufer nach Änderungen fragt.

Design für idempotenz

Hintergrundaufträge sind besonders anfällig dafür, mehr als einmal für denselben logischen Arbeitsschritt ausgeführt zu werden. Warteschlangen liefern Nachrichten mindestens einmal, Scheduler können sich überschneiden, wenn ein Auftrag länger dauert als das Zeitgeberintervall, und Neustarts der Infrastruktur können teilweise abgeschlossene Arbeiten wiederholen. Entwerfen Sie jeden Hintergrundauftrag so, dass dieselbe Eingabe dasselbe Ergebnis erzeugt, wenn der Auftrag mehrmals ausgeführt wird. Weitere Informationen finden Sie unter "Idempotent message processing".

Hostingumgebung

Sie können Hintergrundaufgaben hosten, indem Sie eine Vielzahl von Azure-Plattformdiensten verwenden:

  • Azure-Funktionen: Ein serverloser Computedienst, der ereignisgesteuerte und zeitplangesteuerte Trigger mit automatischer Skalierung unterstützt. Verwenden Sie dauerhafte Funktionen für lange ausgeführte oder zustandsbehaftete Workflows.

  • Azure-Container-Apps: Eine serverlose Containerplattform, die sowohl lange ausgeführte Dienste als auch diskrete Aufträge unterstützt. Aufträge werden nach Abschluss ausgeführt, und Sie können sie manuell, in einem Zeitplan oder nach Ereignissen auslösen. Container-Apps verwenden KEDA für die ereignisgesteuerte Automatische Skalierung, einschließlich Skalierung auf Null.

  • Azure Kubernetes Service (AKS): Eine verwaltete Kubernetes-Umgebung, die die vollständige Kontrolle über die Container-Orchestrierung bietet. Verwenden Sie Kubernetes CronJobs und Aufträge für die Hintergrundverarbeitung, wenn Sie direkten Zugriff auf die Kubernetes-API und die Steuerungsebene benötigen.

  • Azure Batch: Ein Plattformdienst, der rechenintensive Arbeit für die Ausführung auf einer verwalteten Sammlung von virtuellen Computern plant. Sie kann Berechnungsressourcen automatisch über zehn, Hunderte oder Tausende von Knoten skalieren.

  • Virtuelle Azure-Computer: Eine Infrastruktur-as-a-Service-Option (IaaS) für Hintergrundaufgaben, die volle Kontrolle über das Betriebssystem oder die Laufzeitumgebung erfordern, z. B. Windows-Dienste, externe ausführbare Dateien oder spezielle Laufzeiten.

  • Azure App Service WebJobs: Ein Feature von App Service, das Hintergrundskripts oder Programme im selben Kontext wie eine Web-App ausführt. Berücksichtigen Sie WebJobs, wenn Sie eine Hintergrundverarbeitung benötigen, die zusammen mit einer bestehenden App Service-Anwendung ausgeführt wird.

In den folgenden Abschnitten werden diese Optionen ausführlicher beschrieben und Überlegungen aufgeführt, die Ihnen bei der Auswahl der geeigneten Option helfen.

Funktionen

Funktionen sind ein serverloser Computedienst, der ereignisgesteuerten Code ausführt. Funktionen sind für Hintergrundaufträge geeignet, da sie verschiedene Arten von Triggern unterstützt, einschließlich Warteschlangennachrichten, Blobspeicheränderungen, Zeitplanungen, HTTP-Anforderungen und Ereignisrasterereignissen.

Bei Hintergrundaufgaben mit kurzer Dauer stellt Functions die automatische Skalierung (einschließlich Skalierung auf Null) und abrechnung per Zahlung pro Ausführung bereit. Verwenden Sie für lang andauernde oder zustandsbehaftete Workflows Durable Functions, mit denen das Functions-Service um Orchestrierungsfunktionen erweitert wird.

Durable Functions unterstützt mehrere Orchestrationsmuster, die direkt zur Koordination von Hintergrundaufträgen verwendet werden können.

  • Funktionskette: Führen Sie eine Abfolge von Funktionen in einer bestimmten Reihenfolge aus, die die Ausgabe der einzelnen Schritte an die nächste übergibt.

  • Fan-out/Fan-In: Führen Sie mehrere Funktionen parallel aus, und aggregieren Sie dann die Ergebnisse.

  • Asynchrone HTTP-APIs: Koordinieren Sie lang andauernde Vorgänge mit externen Clients mithilfe eines Polling-Endpunkts oder eines Webhook-Rückrufs.

  • Menschliche Interaktion: Unterbrechen Sie eine Orchestrierung, bis sie ein externes Ereignis (z. B. eine Genehmigung) mit optionaler timeoutbasierter Eskalation empfängt.

  • Monitor: Implementieren Sie einen wiederkehrenden Prozess, der eine Bedingung abruft, mit konfigurierbaren Intervallen und Timeouts.

Überlegungen zu Funktionen

  • Wählen Sie einen Hostingplan basierend auf Ihren Workloadmerkmalen aus:

    • Flex-Verbrauchsplan: Am besten geeignet für Hintergrundaufträge, die intermittierend oder unvorhersehbar im Volumen auftreten. Skaliert auf Null, wenn keine Arbeit ansteht, und skaliert unter Last automatisch hoch, mit abrechnung pro Ausführung. Das Standardmäßige Funktionstimeout beträgt 30 Minuten ohne erzwungenes Maximum, sodass der Plan sowohl kurze Aufgaben als auch die längere Verarbeitung verarbeitet. Unterstützt die Integration virtueller Netzwerke und immer bereite Instanzen , um die Latenz von Kaltstarts zu reduzieren.

    • Premium-Plan: Eignet sich für Workloads mit hohem Durchsatz, die kontinuierlich oder nahezu kontinuierlich ausgeführt werden. Stellt vorgewärmte Instanzen bereit, um Kaltstarts zu vermeiden, bietet virtuelle Netzwerkintegration und längere Laufzeiten.

    • Dedizierter Plan (App Service): Führen Sie Funktionen in einer vorhandenen App Service-Infrastruktur aus. Diese Option eignet sich, wenn Sie über unterausgelastete App Service-Kapazität verfügen und Rechenkosten gemeinsam beanspruchen möchten.

  • Durable Functions verwaltet den Orchestrierungszustand automatisch durch Prüfpunkte. Wenn eine Funktions-App neu gestartet wird, wird die Orchestrierung ab dem letzten Prüfpunkt fortgesetzt. Entwerfen Sie Aktivitätsfunktionen als idempotent , sodass Wiederholungen keine doppelten Nebenwirkungen erzeugen. Sie können auch Zeitgebertrigger verwenden, um Funktionen in einem Zeitplan ohne externe Ereignisquelle auszuführen.

Container Apps

Container-Apps unterstützen die Hintergrundverarbeitung über Container-Apps-Aufträge, die containerisierte Aufgaben zum Abschluss ausführen und dann beenden. Aufträge eignen sich für die Batchverarbeitung, geplante Aufgaben und ereignisgesteuerte Arbeiten, bei denen ein kurzlebiger Prozess eine diskrete Einheit einer Aufgabe bearbeitet. Eine allgemeine Übersicht über die Plattform finden Sie in der Übersicht über Container-Apps.

Container-Apps-Aufträge unterstützen drei Triggertypen:

  • Manuelle Aufträge: Sie lösen diese Aufträge bei Bedarf über die Azure CLI, das Azure-Portal oder die Azure Resource Manager-API aus. Verwenden Sie manuelle Aufträge für einmalige Aufgaben wie Datenmigrationen oder on-Demand-Verarbeitung, die eine Anwendung initiiert.

  • Geplante Aufträge: Ein CRON-Ausdruck löst diese Aufträge zu bestimmten Zeiten aus. Verwenden Sie geplante Aufträge für Nachtberichte, regelmäßige Datenbereinigungen oder wiederkehrende Datenverarbeitung.

  • Ereignisgesteuerte Aufträge: Ereignisse wie eine Nachricht, die in einer Warteschlange eintrifft, lösen diese Aufträge aus. Container-Apps verwenden KEDA, um Ereignisquellen zu überwachen und die Ausführungsvorgänge basierend auf den konfigurierten Regeln zu skalieren. Ereignisgesteuerte Aufträge können auf Null skaliert werden, wenn keine Ereignisse verarbeitet werden. Weitere Informationen finden Sie unter Bereitstellen eines ereignisgesteuerten Auftrags.

Stellen Sie für Hintergrundaufgaben, die kontinuierlich ausgeführt werden, z. B. einen Dienst, der Nachrichten aus einer Warteschlange ständig verarbeitet, eine Container-App anstelle eines Auftrags bereit. Container-Apps werden automatisch bei Fehlern neu gestartet und unterstützen Skalierungsregeln basierend auf der Warteschlangenlänge oder anderen Metriken.

Überlegungen zu Container-Apps

  • Container-Apps-Aufträge erfordern das Erstellen und Verwalten von Container-Images. Dieser Ansatz erhöht den Aufwand im Vergleich zu Funktionen, bietet Ihnen jedoch die vollständige Kontrolle über die Laufzeit, Abhängigkeiten und Tools auf Betriebssystemebene, die Ihr Auftrag benötigt.

  • Überprüfen Sie bei ereignisgesteuerten Aufträgen, ob ein KEDA-Scaler Ihre Ereignisquelle unterstützt. KEDA unterstützt Service Bus, Azure Storage Queues, Apache Kafka, RabbitMQ und andere Quellen.

  • Wenn Sie direkten Zugriff auf die Kubernetes-APIs und die Steuerungsebene benötigen, verwenden Sie stattdessen AKS .

Azure Kubernetes Service (AKS)

Verwenden Sie AKS, wenn Ihre Hintergrundaufträge direkten Zugriff auf die Kubernetes-API, benutzerdefinierte Planungslogik oder Integration mit einer umfassenderen Kubernetes-basierten Plattform erfordern, die Ihr Team betreibt.

Verwenden Sie Kubernetes CronJobs für geplante Hintergrundaufgaben und Jobs für einmalige Aufgaben, die vollständig ausgeführt werden sollen. Sie können KEDA auch mit AKS für die ereignisgesteuerte Automatische Skalierung von Auftragsprozessoren verwenden.

Überlegungen zu AKS

AKS erfordert operative Investitionen in Clusterverwaltung, Upgrades und Sicherheitspatching. Wenn Sie keinen direkten Kubernetes-API-Zugriff benötigen, bieten Container-Apps-Aufträge eine verwaltete Alternative mit weniger Aufwand.

Batch

Berücksichtigen Sie Batch , wenn Sie große, parallele HPC-Workloads (High-Performance Computing) über zehn, Hunderte oder Tausende von VMs ausführen müssen.

Der Batchdienst stellt die virtuellen Computer bereit, weist den VMs Aufgaben zu, führt die Aufgaben aus und überwacht den Fortschritt. Batch kann die virtuellen Computer automatisch als Reaktion auf die Workload skalieren. Batch stellt auch die Auftragsplanung bereit. Batch unterstützt sowohl Linux- als auch Windows-VMs.

Überlegungen zur Batchverarbeitung

Batch funktioniert gut mit systemintern parallelen Workloads. Sie kann auch parallele Berechnungen mit einem reduzierten Schritt am Ende durchführen oder Nachrichtenübergabe-Schnittstellenanwendungen (MPI) für parallele Aufgaben ausführen, für die eine Meldung zwischen Knoten übergeben werden muss.

Ein Batch-Job wird auf einem Pool von Knoten (VMs) ausgeführt. Ein Ansatz besteht darin, einen Pool nur bei Bedarf zuzuweisen und nach Abschluss des Auftrags zu löschen. Dieser Ansatz maximiert die Auslastung, da Knoten nicht im Leerlauf sind, wobei der Auftrag warten muss, bis Batch Knoten zuweist. Alternativ können Sie vorab einen Pool erstellen. Dieser Ansatz minimiert die Zeit, die für den Start eines Auftrags benötigt wird, kann aber zu Leerlaufknoten führen. Weitere Informationen finden Sie im Abschnitt Lebensdauer von Pools und Rechenknoten. Eine umfassendere HPC-Anleitung finden Sie unter Batch- und HPC-Lösungen für rechenintensive Workloads im großen Maßstab.

Virtual Machines

Hintergrundaufgaben erfordern möglicherweise eine vollständige Betriebssystemumgebung oder bestimmte Laufzeitabhängigkeiten, die verhindern, dass sie plattform- oder serverlose Dienste verwenden. Typische Beispiele sind Windows-Dienste, ausführbare Dateien und Programme, die für spezialisierte Laufzeiten geschrieben wurden. Sie können aus einer Reihe von Betriebssystemen für eine Azure-VM wählen und Ihren Dienst oder ihre ausführbare Datei auf diesem virtuellen Computer ausführen.

Um die Hintergrundaufgabe in einem separaten virtuellen Computer zu initiieren, haben Sie mehrere Optionen:

  • Sie können die Aufgabe bei Bedarf direkt von Ihrer Anwendung ausführen, indem Sie eine Anforderung an einen Endpunkt senden, den die Aufgabe verfügbar macht. Diese Anforderung übergibt alle Daten, die die Aufgabe benötigt. Der Endpunkt ruft die Aufgabe auf.

  • Sie können die Aufgabe so einrichten, dass sie auf einem Zeitplan ausgeführt wird, indem Sie einen Planer oder einen Timer verwenden, der in Ihrem ausgewählten Betriebssystem verfügbar ist. Unter Windows können Sie beispielsweise windows Task Scheduler verwenden, um Skripts und Aufgaben auszuführen. Oder wenn Sql Server auf dem virtuellen Computer installiert ist, können Sie den SQL Server-Agent verwenden, um Skripts und Aufgaben auszuführen.

  • Sie können Logic Apps verwenden, um die Aufgabe zu initiieren, indem Sie eine Nachricht zu einer Warteschlange hinzufügen, die die Aufgabe überwacht, oder indem Sie eine Anforderung an eine API senden, die die Aufgabe verfügbar macht.

Weitere Informationen zum Initiieren von Hintergrundaufgaben finden Sie unter Trigger.

Überlegungen zu virtuellen Computern

Berücksichtigen Sie die folgenden Punkte, wenn Sie Hintergrundaufgaben in einer Azure-VM bereitstellen:

  • Das Hosten von Hintergrundaufgaben in einer separaten Azure-VM bietet Flexibilität und präzise Kontrolle über Initiierung, Verarbeitung, Planung und Ressourcenzuordnung. Dieser Ansatz erhöht jedoch die Laufzeitkosten, wenn eine VM ausschließlich zum Ausführen von Hintergrundaufgaben bereitgestellt werden muss. Informationen dazu, ob ein virtueller Computer das richtige Computemodell ist, finden Sie unter Auswählen eines Azure-Computediensts.

  • Das Azure-Portal verfügt nicht über eine integrierte Einrichtung zum Überwachen einzelner Aufgaben und keine automatisierte Neustartfunktion für fehlgeschlagene Aufgaben. Sie können den grundlegenden Status der VM überwachen und verwalten, indem Sie Azure PowerShell-Cmdlets verwenden. Sie müssen jedoch eigene Mechanismen zum Sammeln von Instrumentierungsdaten aus dem Aufgaben- und Betriebssystem implementieren. Verwenden Sie den Azure Monitor-Agent , um Protokolle und Metriken von der VM zu sammeln.

  • Erstellen Sie Überwachungssonden, die über HTTP-Endpunkte bereitgestellt werden. Der Code für diese Prüfpunkte sollte Integritätsprüfungen durchführen, betriebstechnische Informationen und Statistiken sammeln oder Fehlerinformationen zusammenführen und an eine Verwaltungsanwendung zurückgeben. Weitere Informationen finden Sie im Health Endpoint Monitoring Muster.

App Service WebJobs

Azure WebJobs ist ein Feature von App Service, das Hintergrundskripts oder Programme in derselben Instanz wie eine Web-App ausführt. WebJobs werden im Sandkasten der Web-App ausgeführt, was bedeutet, dass sie auf Umgebungsvariablen, Verbindungszeichenfolgen und andere konfiguration zugreifen können, die für die App freigegeben ist. Sie können das Azure WebJobs SDK verwenden, um den Code zu vereinfachen, den Sie für allgemeine Hintergrundverarbeitungsaufgaben schreiben.

Erwägen Sie den Einsatz von WebJobs, wenn Sie bereits über eine vorhandene App Service-WebApp verfügen und Hintergrundverarbeitung benötigen, die denselben Lebenszyklus, dieselbe Konfiguration und Bereitstellung wie die WebApp aufweist. Wir empfehlen WebJobs nicht als universelle Plattform für Hintergrundaufgaben bei neuen Workloads. Bei neuen ereignisgesteuerten oder geplanten Hintergrundverarbeitungen sollten Sie Funktionen oder Container App-Jobs bewerten.

WebJobs können als fortlaufende oder ausgelöste Prozesse ausgeführt werden:

  • Fortlaufend ausgeführt: Der WebJob wird sofort gestartet und als langer Prozess ausgeführt. Das Skript oder Programm wird gespeichert in site/wwwroot/app_data/jobs/continuous.

  • Ausführen nach einem Zeitplan oder bei Bedarf: Ein Zeitplan mithilfe eines CRON-Ausdrucks oder eine manuelle Aktion löst den WebJob aus. Das Skript oder Programm wird gespeichert in site/wwwroot/app_data/jobs/triggered.

Überlegungen zu App Service WebJobs

  • Standardmäßig skalieren WebJobs mit der Web-App. Sie können einen Auftrag so einrichten, dass er als einzelne Instanz ausgeführt wird, indem Sie die is_singleton Konfigurationseigenschaft auf festlegen true. WebJobs mit einzelner Instanz eignen sich für Aufgaben, die Sie nicht als gleichzeitige mehrere Instanzen ausführen möchten, z. B. neu indizieren oder Datenanalysen.

  • Um die Auswirkungen von Jobs auf die Leistung von Webanwendungen zu verringern, sollten Sie eine leere Azure Web App-Instanz in einem separaten App Service-Plan erstellen, um lang andauernde oder ressourcenintensive WebJobs zu hosten.

  • WebJobs teilen Computeressourcen mit der Hostweb-App. Ressourcenintensive Hintergrundverarbeitung kann die Reaktionsfähigkeit der Web-App beeinträchtigen.

Partitionierung

Wenn Sie Sich entscheiden, Hintergrundaufgaben in eine vorhandene Computeinstanz einzuschließen, überlegen Sie, wie sich dieser Ansatz auf die Qualitätsattribute der Computeinstanz und die Hintergrundaufgabe selbst auswirkt. Anhand dieser Faktoren können Sie entscheiden, ob Sie die Aufgaben mit der vorhandenen Computeinstanz zusammenführen oder in eine dedizierte Computeinstanz aufteilen möchten.

  • Verfügbarkeit: Hintergrundaufgaben tolerieren häufig kurze Ausfälle besser als die Benutzeroberfläche, da ausstehende Arbeiten in die Warteschlange gestellt werden können. Wenn sich die Warteschlange jedoch zurückstaut, weil die Hintergrundverarbeitung zu lange nicht verfügbar ist, wird die Anwendung beeinträchtigt.

  • Wiederherstellung: Wenn eine Computeinstanz, die nur Hintergrundaufgaben hostet, fehlschlägt, kann die Anwendung weiterhin Benutzer bedienen, solange die ausstehende Arbeit in der Warteschlange verbleibt. Wenn die Instanz wiederhergestellt wird, verarbeitet sie den Backlog.

  • Sicherheit: Hintergrundaufgaben benötigen möglicherweise Zugriff auf verschiedene Ressourcen, Anmeldeinformationen oder Netzwerksegmente als die Benutzeroberfläche. Wenn Sie sie in einer separaten Computeinstanz ausführen, können Sie eine engere Sicherheitsgrenze anwenden, z. B. das Einschränken des Netzwerkzugriffs auf einen Datenspeicher, den die Benutzeroberfläche nie direkt erreichen sollte. Sie können auch Muster wie Gatekeeper verwenden, um die Hintergrundberechnung von benutzerdefinierten Komponenten zu isolieren.

  • Verwaltbarkeit: Hintergrundaufgaben ändern sich häufig in einem anderen Veröffentlichungsrhythmum als die Benutzeroberfläche. Durch das Trennen von Aufgaben wird verhindert, dass die gesamte Anwendung erneut bereitgestellt wird, wenn sich nur die Auftragslogik ändert.

  • Skalierbarkeit: Hintergrundaufgaben skalieren in der Regel auf unterschiedliche Signale als die Benutzeroberfläche. Hintergrundsysteme skalieren basierend auf der Warteschlangentiefe oder Batchgröße, während die Benutzeroberfläche basierend auf gleichzeitigen Benutzern oder Anforderungsrate skaliert wird. Durch das Trennen dieser Vorgänge kann jede Aufgabe unabhängig skaliert werden.

Durch das Trennen von Hintergrundaufgaben in dedizierte Rechenressourcen erhöhen sich die Hostingkosten. Vergleichen Sie diese Kosten mit den betrieblichen Vorteilen der unabhängigen Skalierung, Bereitstellung und Ausfallisolation.

Konflikte

Wenn Sie mehrere Instanzen eines Hintergrundauftrags haben, können diese um den Zugriff auf Ressourcen und Dienste wie Datenbanken und Speicher konkurrieren. Dieser gleichzeitige Zugriff kann zu einer Ressourcenverknügung führen, die sich auf die Dienstverfügbarkeit und die Datenintegrität auswirken kann. Sie können Ressourcenkonflikte mithilfe eines pessimistischen Sperrverfahrens auflösen. Dieser Ansatz verhindert, dass konkurrierende Instanzen einer Aufgabe gleichzeitig auf einen Dienst zugreifen oder Daten beschädigt werden.

Ein anderer Ansatz löst Konflikte durch das Definieren von Hintergrundaufgaben als Singleton, sodass nur eine Instanz ausgeführt wird. Dieser Ansatz beseitigt jedoch die Zuverlässigkeits- und Leistungsvorteile einer Konfiguration mit mehreren Instanzen. Dieser Effekt gilt insbesondere, wenn die Benutzeroberfläche ausreichend Arbeit bereitstellen kann, um mehr als eine Hintergrundaufgabe beschäftigt zu halten.

Stellen Sie sicher, dass die Hintergrundaufgabe automatisch neu gestartet werden kann und über ausreichende Kapazität verfügt, um Spitzen bei Bedarf zu bewältigen. Um dieses Ergebnis zu erzielen, weisen Sie eine Computeinstanz mit ausreichenden Ressourcen zu, implementieren Sie einen Warteschlangenmechanismus, der Anforderungen für die spätere Verarbeitung speichert, wenn die Nachfrage verringert wird, oder kombinieren Sie beide Techniken.

Koordination

Hintergrundaufgaben können komplex sein und erfordern mehrere einzelne Aufgaben, um ein Ergebnis zu erzeugen oder alle Anforderungen zu erfüllen. In diesen Szenarien teilen Teams die Aufgabe häufig in kleinere, diskrete Schritte oder Teilvorgänge auf, die mehrere Verbraucher ausführen können. Multistep-Aufträge erhöhen oft die Effizienz und Flexibilität, da mehrere Aufträge einzelne Schritte wiederverwenden können. Sie können die Schritte auch hinzufügen, entfernen oder neu anordnen.

Es kann schwierig sein, Aufgaben zu koordinieren, aber drei allgemeine Muster können Ihre Implementierung leiten:

  • Teilen Sie eine Aufgabe in mehrere wiederverwendbare Schritte auf. Ein Hintergrundauftrag verarbeitet Informationen in mehreren Etappen, wie validieren, transformieren und speichern. Sie können diesen Fluss in diskrete Filter unterteilen, die durch Warteschlangen verbunden sind. Jeder Schritt wird unabhängig ausgeführt und kann in verschiedenen Aufträgen skaliert oder verwendet werden. Weitere Informationen finden Sie im Rohr- und Filtermuster.

  • Verwalten Sie, wie die Schritte für eine Aufgabe ausgeführt werden. Ein Hintergrundauftrag, der aus mehreren Schritten besteht und Remotedienste aufruft oder auf Remoteressourcen zugreift, benötigt eine Orchestrierungslogik, um die Schritte zu sequenzieren, Timeouts zu verarbeiten und den Fortschritt nachzuverfolgen. Weitere Informationen finden Sie unter Scheduler Agent Supervisor-Muster.

  • Verwalten Sie die Wiederherstellung für Aufgabenschritte, die fehlschlagen. Ein Hintergrundauftrag, der mehrere Schritte umfasst (die gemeinsam einen eventuell konsistenten Vorgang definieren), muss möglicherweise abgeschlossene Arbeiten rückgängig machen, wenn ein späterer Schritt fehlschlägt. Weitere Informationen finden Sie im Muster der Ausgleichstransaktion.

Überlegungen zur Zuverlässigkeit

Hintergrundaufgaben müssen robust und wiederherstellbar sein, um zuverlässige Dienste für die Anwendung bereitzustellen. Berücksichtigen Sie beim Planen und Entwerfen von Hintergrundaufgaben die folgenden Punkte:

  • Hintergrundaufgaben müssen problemlos Neustarts behandeln, ohne Daten zu beschädigen oder Inkonsistenzen in der Anwendung einzuführen. Bei langandauernden oder mehrstufigen Aufgaben sollten Sie Checkpointing verwenden, indem Sie den Auftragsstatus im persistenten Speicher oder in Warteschlangenmeldungen speichern, wenn dies sinnvoll ist. Sie können beispielsweise Statusinformationen in einer Warteschlangenmeldung beibehalten und diesen Zustand inkrementell mit dem Vorgangsfortschritt aktualisieren, sodass die Aufgabe vom letzten bekannten guten Prüfpunkt fortgesetzt wird, anstatt von Anfang an neu zu starten. Wenn Sie Service Bus-Warteschlangen verwenden, können Sie Nachrichtensitzungen verwenden, um den Anwendungsverarbeitungszustand zu speichern und abzurufen. Weitere Informationen zum Entwerfen zuverlässiger mehrstufiger Prozesse und Workflows finden Sie im Muster "Scheduler Agent Supervisor".

  • Entwerfen Sie Hintergrundaufgaben so, dass sie ordnungsgemäß heruntergefahren werden, wenn die Hostingplattform die Beendigung signalisiert. Bereitstellungen, Skalierungsereignisse und Plattformwartung können eine ausgeführte Instanz jederzeit beenden. Wenn eine Hintergrundaufgabe ein Beendigungssignal empfängt, während sie ausgeführt wird (wie SIGTERM in Containern), sollte sie die Annahme neuer Aufgaben einstellen, den aktuellen Arbeitsauftrag abschließen oder sichern und sauber beendet werden. Bei Queue-gesteuerten Aufgaben bedeutet ein sanftes Herunterfahren, die aktuelle Nachricht abzuschließen, bevor der Prozess beendet ist, damit die Nachricht nicht unnötig erneut zugestellt wird. Wenn der Vorgang nicht rechtzeitig beendet werden kann, sollte er den Fortschritt prüfen oder das Zeitlimit für die Sichtbarkeit der Nachricht ablaufen lassen, damit eine andere Instanz die Arbeit verarbeitet.

    Richten Sie die Nachfrist für das Herunterfahren der Plattform lange genug ein, damit Ihre typische Arbeitsaufgabe abgeschlossen werden kann. In Kubernetes die Pod-Spezifikation mit terminationGracePeriodSeconds festlegen. In den Plänen "Functions Flex Consumption" und "Premium" stellt die Plattform automatisch bis zu 60 Minuten bereit, damit laufende Arbeiten während des Scale-Ins abgeschlossen werden können.

  • Wenn Sie Warteschlangen verwenden, um mit Hintergrundaufgaben zu kommunizieren, können Warteschlangen als Puffer zum Speichern von Anforderungen funktionieren, während die Anwendung höher als üblich geladen ist. Dieses Design ermöglicht es, dass Aufgaben während weniger ausgelasteten Zeiträumen mit der Benutzeroberfläche synchronisiert werden. Dies bedeutet auch, dass Neustarts die Benutzeroberfläche nicht blockieren. Weitere Informationen finden Sie im Queue-Based Load Leveling-Muster. Wenn einige Aufgaben wichtiger sind als andere, sollten Sie das Muster "Prioritätswarteschlange " implementieren, um sicherzustellen, dass diese Aufgaben vor weniger wichtigen Aufgaben ausgeführt werden.

  • Hintergrundaufgaben, die Nachrichten initiieren oder die Nachrichten verarbeiten, müssen Inkonsistenzen verarbeiten, z. B. Nachrichten, die außerhalb der Reihenfolge eingehen, Nachrichten, die wiederholt einen Fehler verursachen (häufig als Giftnachrichten bezeichnet), und Nachrichten, die mehrmals übermittelt werden. Berücksichtigen Sie die folgenden Faktoren:

    • Nachrichten, die eine geordnete Verarbeitung erfordern, z. B. Aktualisierungen, die vom aktuellen Datenwert abhängen, werden möglicherweise nicht in der Reihenfolge übermittelt, in der sie gesendet wurden. Alternativ können unterschiedliche Instanzen einer Hintergrundaufgabe sie auch in einer anderen Reihenfolge behandeln, da sie bei jeder Instanz unterschiedlich geladen werden. Nachrichten, die in einer bestimmten Reihenfolge verarbeitet werden müssen, sollten eine Sequenznummer, einen Schlüssel oder einen anderen Indikator enthalten, den Hintergrundaufgaben verwenden können, um die richtige Verarbeitungsreihenfolge sicherzustellen. Wenn Sie Service Bus verwenden, können Sie Nachrichtensitzungen verwenden, um die Reihenfolge der Zustellung zu garantieren. Aber es ist oft effizienter, wenn möglich, den Prozess so zu entwerfen, dass die Nachrichtenreihenfolge keine Rolle spielt.

    • Eine Hintergrundaufgabe wirft in der Regel einen Blick auf Nachrichten in der Warteschlange, wodurch sie vorübergehend von anderen Nachrichtenempfängern ausgeblendet werden. Nachdem die Aufgabe eine Nachricht erfolgreich verarbeitet hat, wird sie gelöscht. Wenn eine Hintergrundaufgabe fehlschlägt, wenn sie eine Nachricht verarbeitet, wird diese Nachricht nach Ablauf des Vorschautimeouts wieder in der Warteschlange angezeigt. Eine andere Instanz der Aufgabe oder der nächste Verarbeitungszyklus dieser Instanz verarbeitet sie dann. Wenn die Nachricht ständig einen Fehler im Consumer verursacht, blockiert sie den Prozess, die Warteschlange und letztendlich die Anwendung, wenn die Warteschlange voll wird. Erkennen und Entfernen von Giftmeldungen aus der Warteschlange. Wenn Sie Service Bus verwenden, können fehlerhafte Nachrichten automatisch verschoben werden, oder Sie können sie manuell in eine zugeordnete Fehlerwarteschlange verschieben.

    • Warteschlangen sind Mechanismen zur garantierten mindestens einmal Zustellung, das bedeutet, dass eine Nachricht mehrmals zugestellt werden kann. Wenn eine Hintergrundaufgabe nach der Verarbeitung einer Nachricht fehlschlägt, aber bevor sie aus der Warteschlange gelöscht wird, steht die Nachricht erneut zur Verarbeitung zur Verfügung. Alle nachrichtengesteuerten Hintergrundaufgaben müssen idempotent sein. Weitere Informationen finden Sie unter "Design for idempotency".

  • Unterscheiden Sie vorübergehende Fehler von dauerhaften Fehlern in Ihrem Auftragsprozessor. Wenn eine Hintergrundaufgabe eine Nachricht nicht verarbeitet, wird sie automatisch von der Warteschlange erneut bearbeitet. Wenn der Fehler vorübergehend ist, z. B. ein nachgelagertes Timeout oder eine Drosselungsreaktion, funktioniert die erneute Zustellung ordnungsgemäß. Wenn der Fehler dauerhaft ist, z. B. eine falsch formatierte Nutzlast oder fehlende referenzierte Daten, schlägt die Nachricht bei jedem Versuch fehl. Richten Sie Ihren Auftragsprozessor so ein, dass er permanente Fehler erkennt und diese Nachrichten direkt an eine Dead-Letter-Queue weiterleitet, anstatt Wiederholungsversuche zu verbrauchen. Die maximale Lieferanzahl der Warteschlange steuert, wie oft eine Nachricht zugestellt wird, bevor sie automatisch in die Warteschlange für nicht zustellbare Nachrichten verschoben wird. Weitere Informationen zur Behandlung vorübergehender Bedingungen in Ihrer Verarbeitungslogik finden Sie unter Vorübergehende Fehlerbehandlung.

Sicherheitsüberlegungen

Hintergrundaufträge werden häufig mit einem breiteren Zugriff auf Datenspeicher, APIs und interne Dienste als die benutzerorientierte Anwendung ausgeführt. Berücksichtigen Sie beim Planen der Sicherheit für Hintergrundaufgaben die folgenden Punkte:

  • Gewähren Sie den Zugriff auf Job-Prozessoren mit minimalen Berechtigungen. Ein Hintergrundauftrag, der aus einer Warteschlange liest und in eine Datenbank schreibt, sollte nur über die Berechtigung zum Ausführen dieser beiden Vorgänge verfügen. Vermeiden Sie die erneute Wiederverwendung einer breiten Anwendungsidentität, die auch den UI- oder Administrator-APIs dient. Wenn ein Auftragsverarbeiter kompromittiert wird, bleibt der Wirkungsbereich auf seine erteilten Berechtigungen beschränkt.

  • Halten Sie vertrauliche Daten außerhalb der Nachrichtennutzlasten. Warteschlangennachrichten können während des Debuggens protokolliert, in eine Dead-Letter-Queue verschoben oder überprüft werden. Statt vertrauliche Daten wie persönliche Informationen oder Anmeldeinformationen direkt in einer Nachricht zu platzieren, speichern Sie die Daten in einem geschützten Datenspeicher und übergeben Sie einen Verweisidentifier in der Nachricht, die der Prozess verwendet, um die Daten abzurufen.

Überlegungen zur Beobachtbarkeit

Hintergrundaufträge laufen ohne anwesenden Benutzer ab, sodass Fehler unbemerkt bleiben, es sei denn, Sie überwachen sie aktiv. Berücksichtigen Sie beim Planen der Observierbarkeit für Hintergrundaufgaben die folgenden Punkte:

  • Verfolgen Sie den Auftragsabschluss, nicht nur den Auftragsstart. Protokollieren Sie, wenn ein Hintergrundauftrag gestartet, abgeschlossen oder fehlgeschlagen ist. Fügen Sie den Auftragstyp, einen Korrelationsbezeichner, der den Auftrag mit dem auslösenden Ereignis oder der Nachricht verknüpft, und die verstrichene Dauer hinzu. Ohne Nachverfolgung des Abschlusses scheint ein Auftrag, der im Hintergrund hängt oder abstürzt, normal ausgeführt zu werden.

  • Warnung für verpasste Zeitpläne. Überwachen Sie bei zeitplangesteuerten Vorgängen, dass jede erwartete Ausführung erfolgt. Wenn ein geplanter Auftrag nicht ausgeführt wird, gibt es keinen Fehler abzufangen, da nichts gelaufen ist. Vergleichen Sie die tatsächlichen Laufzeiten mit dem erwarteten Zeitplan und warnen Sie, wenn ein Durchlauf fehlt.

  • Überwachen von Dead-Letter-Queues. Inaktive Nachrichten stellen Hintergrundarbeit dar, die nicht abgeschlossen wurden. Richten Sie Warnungen für die Tiefe und das Alter der Nachrichten in der Dead-Letter-Queue ein, sodass Ihr Betriebsteam Fehler untersuchen, das zugrunde liegende Problem beheben und Nachrichten erneut übermitteln kann. Ohne Überwachung kumuliert sich fehlgeschlagene Arbeit im Hintergrund.

  • Messen Sie die Wartezeit der Warteschlange, nicht nur die Verarbeitungszeit. Die geschäftlichen Auswirkungen werden davon bestimmt, wie lange eine Nachricht von der Warteschlange bis zum Abschluss dauert. Ein Auftrag, der in 2 Sekunden verarbeitet wird, aber 30 Minuten lang in der Warteschlange sitzt, verursacht eine Verzögerung von 30 Minuten. Verfolgen Sie die Enqueue-to-Completion-Latenz zusammen mit der Verarbeitungszeit pro Auftrag.

  • Korrelieren Sie über Jobschritte hinweg. Multistep-Hintergrundaufträge können mehrere Dienste, Warteschlangen und Compute-Instanzen umfassen. Verteilen Sie einen Korrelationsbezeichner durch jeden Schritt, damit Sie den gesamten Lebenszyklus einer einzelnen Arbeitsaufgabe in Ihren Protokollen und verteilten Ablaufverfolgungen nachverfolgen können.

Überlegungen zu Skalierung und Leistung

Hintergrundaufgaben müssen mit dem Tempo Schritt halten, in dem die Arbeit eingeht. Wenn Aufgaben im Rückstand sind, wachsen Warteschlangen, die Verzögerung steigt und nachgeschaltete Prozesse werden aufgehalten. Berücksichtigen Sie beim Planen der Skalierung für Hintergrundaufgaben die folgenden Punkte:

  • Skalieren Sie nach der Tiefe der Warteschlange, nicht nur nach der CPU. Bei nachrichtengesteuerten Hintergrundaufgaben ist das nützlichste Skalierungssignal, wie viel Arbeit in der Warteschlange wartet, nicht wie ausgelastet die aktuellen Instanzen sind. Funktionen, Container-Apps und AKS (über KEDA) unterstützen die Skalierung basierend auf der Länge der Warteschlange, der Anzahl der Themenabonnements oder anderen Metriken der Ereignisquelle. Bei diesem Ansatz wird Kapazität hinzugefügt, wenn sich die Arbeit anhäuft, und Kapazität reduziert, wenn die Warteschlangen abgebaut werden.

  • Verwenden Sie Scale-to-Zero für intermittierende Workloads. Wenn Ihre Hintergrundaufträge nur zu bestimmten Zeiten ausgeführt werden, z. B. Nachtbatchaufträge oder ereignisgesteuerte Verarbeitung mit Leerlaufzeiten, verwenden Sie ein Hostingmodell, das auf Null skaliert wird, wenn es keine Arbeit gibt. Funktionen und Container-Apps-Aufträge können auf Null skaliert werden, sodass Sie nicht für die Berechnung im Leerlauf bezahlen.

  • Skalieren Sie Hintergrundaufgaben unabhängig von der Anwendung. Hosten Sie Hintergrundaufgaben in einem separaten Computedienst, sodass die UI und die Hintergrundverarbeitung auf unterschiedlichen Signalen skaliert werden. Wenn Sie über mehrere Hintergrundaufgabentypen verfügen, die unterschiedliche Durchsatzmerkmale aufweisen, sollten Sie sie trennen, damit jeder Typ unabhängig voneinander skaliert werden kann.

  • Skalieren Sie die gesamte Verarbeitungspipeline, nicht nur die Rechenleistung. Weitere Aufgabeninstanzen helfen nicht, wenn die Warteschlange, die Datenbank oder die Downstream-API zu einem Engpass wird. Identifizieren Sie Durchsatzgrenzwerte in der gesamten Pipeline, einschließlich Nachrichtendurchsatzeinheiten, Datenbankanforderungseinheiten und API-Rate-Grenzwerte. Skalieren Sie diese Ressourcen parallel mit Ihrer Rechenkapazität.

  • Erzwingen Sie bei Bedarf die Ausführung einer einzelnen Instanz. Einige geplante Hintergrundaufgaben dürfen nicht gleichzeitig ausgeführt werden, z. B. Datenbankwartung oder Berichtsgenerierung, die nicht idempotent ist. Funktionstimertrigger verwenden eine verteilte Sperre , um sicherzustellen, dass nur eine Instanz ausgeführt wird. Verwenden Sie bei Containern die Kubernetes CronJob-Einstellung concurrencyPolicy: Forbid oder die Parallelitätseinstellungen auf Job-Ebene für Container-Apps.

Nächste Schritte

  • Last updated on