Muster „Scheduler-Agent-Supervisor“

Koordinieren Sie eine Reihe verteilter Aktionen als einzelne logische Operation, sodass der Vorgang als Ganzes entweder erfolgreich ausgeführt wird oder fehlschlägt. Behandeln Sie Fehler transparent, oder rückgängig machen Sie die abgeschlossene Arbeit. Dieser Ansatz erhöht die Resilienz verteilter Systeme, indem er die Wiederherstellung nach vorübergehenden Ausnahmefehlern, länger anhaltenden Fehlern und Prozessausfällen ermöglicht, die mehrstufige Workflows unterbrechen, die über Remotedienste und Ressourcen hinweg orchestriert werden.

Kontext und Problem

Anwendungen führen häufig Aufgaben aus, die sich über mehrere Schritte erstrecken, und einige Schritte können Remotedienste aufrufen oder unter der Orchestrierung der Anwendungslogik auf Remoteressourcen zugreifen. Die Interaktion mit allem außerhalb des lokalen Prozesses setzt die Aufgabe einer Reihe von Fehlermodi aus. Die Orchestrierungslogik muss diese Fehlermodi behandeln, ohne die Integrität des Vorgangs insgesamt zu verlieren.

Sie können einfache Situationen behandeln, z. B. vorübergehende Fehler, die eigenständig aufgelöst werden, indem Sie Ansätze wie das Wiederholungsmuster verwenden. Wenn Fehler dauerhafter sind oder wenn der Orchestrator selbst fehlschlägt, muss das System einen konsistenten Zustand aus dauerhaften Datensätzen wiederherstellen und die Integrität des Gesamtvorgangs sicherstellen.

Lösung

Das Muster "Scheduler Agent Supervisor" koordiniert einen mehrstufigen verteilten Vorgang über drei logische Akteure. Diese Akteure orchestrieren die Schritte, die als Teil der Gesamtaufgabe ausgeführt werden sollen, und behandeln sowohl erfolgreiche als auch fehlgeschlagene Ausführungen.

Scheduler

Der Scheduler ordnet die Schritte an, aus denen die Aufgabe besteht, und koordiniert ihre Ausführung. Der Scheduler ist dafür verantwortlich, Schritte in einer Pipeline oder einem Workflow zu kombinieren und in der richtigen Reihenfolge auszuführen. Während jeder Schritt voranschreitet, zeichnet der Scheduler seinen Status auf, z. B. "Schritt noch nicht gestartet", "Schritt ausführen" oder "Schritt abgeschlossen". Der Zustand enthält auch einen Abschlusszeitpunkt, der festlegt, wie viel Zeit dem Schritt maximal zur Verfügung steht.

Wenn ein Schritt einen Remotedienst oder eine Ressource benötigt, ruft der Scheduler einen geeigneten Agent auf und übergibt die Arbeitsdetails an ihn. Der Scheduler kommuniziert in der Regel mit Agenten über asynchrone Anforderungs-/Antwortnachrichten, die häufig über Warteschlangen implementiert werden. Sie können stattdessen andere verteilte Messagingtechnologien verwenden.

Agent

Ein Agent kapselt einen Aufruf eines Remotediensts oder den Zugriff auf eine Remoteressource, auf die ein Vorgangsschritt verweist. Jeder Agent kapselt in der Regel Aufrufe an einen einzelnen Dienst oder eine einzelne Ressource und implementiert die entsprechende Fehlerbehandlungs- und Wiederholungslogik innerhalb der vom Scheduler vorgegebenen Frist. Wenn die Wiederholungslogik beteiligt ist, übergibt der Agent einen stabilen Bezeichner für alle Wiederholungsversuche. Ein nachgeschalteter Dienst kann dies für die Deduplizierung verwenden.

Wenn unterschiedliche Schritte im Workflow unterschiedliche Dienste oder Ressourcen verwenden, kann jeder Schritt auf einen anderen Agent verweisen. Diese Zuordnung ist ein Implementierungsdetail des Musters. Anleitungen zum Entwerfen von Wiederholungsstrategien finden Sie unter Bewährte Methoden für die vorübergehende Fehlerbehandlung.

Vorgesetzter

Der Supervisor überwacht den Status der vom Scheduler ausgeführten Schritte. Der Supervisor wird in regelmäßigen Abständen mit der von der Workload angegebenen Frequenz ausgeführt und untersucht den Status des Schritts, den der Scheduler aufgezeichnet hat. Wenn der Supervisor feststellt, dass Schritte fehlgeschlagen sind oder bei denen eine Zeitüberschreitung aufgetreten ist, veranlasst er, dass der entsprechende Agent den Schritt wiederherstellt, oder er löst eine andere Abhilfemaßnahme aus, die auch eine Änderung des Schrittstatus umfassen kann. Der Supervisor fordert diese Wiederherstellungsaktionen nur an. Der Planer und die Agents implementieren sie.

Aktivitäten

Der Scheduler, Agent und Supervisor sind logische Komponenten, und ihre physische Implementierung hängt von der verwendeten Technologie ab. Sie können beispielsweise mehrere logische Agents als Teil eines einzelnen Webdiensts oder als Aktivitäten innerhalb desselben gehosteten Workers implementieren.

Der Scheduler verwaltet den Vorgangsfortschritt und den Status pro Schritt in einem dauerhaften Datenspeicher, der als Zustandsspeicher bezeichnet wird. Der Supervisor verwendet diese Informationen, um festzustellen, ob ein Schritt fehlgeschlagen ist. Das folgende Diagramm zeigt die Beziehung zwischen dem Scheduler, den Agents, dem Supervisor und dem Zustandsspeicher.

• Der Scheduler organisiert und führt die Schritte aus, die die Aufgabe als Workflow umfassen.
• Ein Schritt im Workflow kann eine Anforderung an einen Agent senden, um auf eine Remoteressource zuzugreifen oder einen Remotedienst aufzurufen. Anforderungen und Antworten werden in der Regel asynchron gesendet.
• Ein Agent greift auf die Remoteressource oder den Dienst zu. Der Agent sollte Fehlerbehandlung und Wiederholungslogik umfassen.
• Der Scheduler behält den Status der einzelnen Schritte im Zustandsspeicher bei, sobald er gestartet und abgeschlossen wird.
• Der Supervisor überwacht den Status der Schritte im Zustandsspeicher und fordert möglicherweise eine Aktualisierung eines Schrittstatus an.
• Der Vorgesetzte fordert den Planer auf, einen fehlgeschlagenen Schritt erneut zu planen.

Wenn die Anwendung bereit ist, einen Task auszuführen, sendet sie eine Anforderung an den Scheduler. Der Scheduler zeichnet den Anfangszustand für den Vorgang und seine Schritte auf, z. B. schritt noch nicht gestartet, im Zustandsspeicher und startet dann die Ausführung der Vorgänge, die der Workflow definiert. Wenn der Scheduler jeden Schritt startet, aktualisiert er den Status dieses Schritts, z. B. die Ausführung von Schritten, im Zustandsspeicher.

Wenn ein Schritt auf einen Remotedienst oder eine Ressource verweist, sendet der Scheduler eine Nachricht an den entsprechenden Agent. Die Nachricht enthält die Informationen, die der Agent benötigt, um den Dienst aufzurufen oder auf die Ressource zuzugreifen, sowie den Zeitpunkt, bis zu dem der Vorgang abgeschlossen sein muss, und die zulässige Anzahl von Wiederholungsversuchen für den Vorgang.

Ein Agent kann jede Wiederholungslogik implementieren, die für seine Arbeit geeignet ist, aber wenn der Agent seine Arbeit nicht innerhalb der gesamten Zeit abgeschlossen hat, geht der Scheduler davon aus, dass der Vorgang fehlgeschlagen ist und nicht mehr auf eine Antwort wartet. Der Agent muss die Frist einhalten und darf nach Ablauf der Frist keine neuen Seiteneffekte mehr auslösen, auch wenn bereits laufende Arbeit möglicherweise fortgesetzt wird.

Wenn der Agent den Vorgang erfolgreich abgeschlossen hat, gibt er eine Antwort an den Scheduler zurück. Der Scheduler aktualisiert den Status beispielsweise auf Schritt abgeschlossen und beginnt mit dem nächsten Schritt. Dieser Prozess wird fortgesetzt, bis der gesamte Task abgeschlossen wurde.

Der Scheduler muss jede verspätete Antwort ignorieren, und der Agent darf keine eigene Workflowwiederherstellung versuchen. Wenn der Agent selbst fehlschlägt, erhält der Scheduler auch keine Antwort. Der Status im State Store unterscheidet absichtlich nicht zwischen einem Schritt, bei dem eine Zeitüberschreitung auftritt, und einem Schritt, der fehlschlägt.

Wenn für einen Schritt eine Zeitüberschreitung auftritt oder er fehlschlägt, zeigt der Datensatz im Zustandsspeicher den Schritt weiterhin als wird ausgeführt an, jedoch mit einem abgelaufenen Abschlusszeitpunkt. Der Supervisor sucht nach Datensätzen in dieser Bedingung und ordnet die Wiederherstellung an.

Der Supervisor muss auch verhindern, dass derselbe Schritt unbegrenzt wiederholt wird. Der Supervisor verwaltet für jeden Schritt eine Wiederholungsanzahl zusammen mit den Statusinformationen im Zustandsspeicher. Wenn die Anzahl einen vordefinierten Schwellenwert überschreitet, kann der Supervisor auf einen längeren Zeitraum warten, bevor der Scheduler aufgefordert wird, den Schritt erneut zu wiederholen, falls der zugrunde liegende Fehler während dieses Intervalls gelöscht wird.

Eine mögliche Supervisor-Strategie besteht darin, den Complete-by-Wert zu verlängern und eine Nachricht an den Scheduler zu senden, die den Schritt identifiziert, für den ein Timeout aufgetreten ist, damit der Scheduler ihn erneut ausführen kann. Dieses Design erfordert, dass die Schrittlogik idempotent ist, da die gleiche Arbeit möglicherweise mehrmals ausgeführt wird.

Alternativ kann der Supervisor den Planer bitten, den gesamten Vorgang rückgängig zu machen, indem eine Ausgleichstransaktion ausgelöst wird. Dieser Ansatz setzt voraus, dass der Scheduler und die Agenten genügend Informationen bereitstellen, um für jeden Schritt, der bereits erfolgreich abgeschlossen wurde, Kompensationsvorgänge zu implementieren. Das Vergütungsprotokoll benötigt Reihenfolge und Haltbarkeit, da Ausgleichsvorgänge in der Regel in der umgekehrten Reihenfolge der abgeschlossenen Schritte ausgeführt werden. Ein Kompensationsvorgang, der selbst fehlschlägt, lässt die Aufgabe in einem Zustand zurück, der weder abgeschlossen noch sauber rückgängig gemacht ist. Der Statusspeicher muss diese Bedingung darstellen können, damit Operatoren sie suchen und untersuchen können.

In einer tatsächlichen Implementierung dieses Musters können mehrere Instanzen des Schedulers gleichzeitig ausgeführt werden, wobei jede Teilmenge von Aufgaben behandelt wird. Das System kann auch mehrere Instanzen der einzelnen Agents oder mehrere Supervisor ausführen. Wenn mehr als ein Supervisor aktiv ist, müssen sich die Supervisoren abstimmen, damit sie nicht versuchen, denselben fehlgeschlagenen Schritt oder dieselbe fehlgeschlagene Aufgabe wiederherzustellen. Das Wahlmuster von Leitern ist eine Möglichkeit zur Koordinierung der Vorgesetzten.

Der Hauptvorteil dieses Musters besteht darin, dass das System sowohl gegenüber vorübergehenden als auch gegenüber nicht behebbaren Ausfällen widerstandsfähig bleibt und so aufgebaut werden kann, dass es sich selbst heilt. Wenn ein Agent oder der Scheduler ausfällt, können Sie eine neue Instanz starten, und der Supervisor kann veranlassen, dass die betroffene Aufgabe wiederaufgenommen wird. Wenn der Supervisor selbst fehlschlägt, kann eine andere Instanz übernehmen, wo die vorherige beendet wurde. Wenn der Supervisor nach einem Zeitplan ausgeführt wird, wird beim nächsten Intervall automatisch eine neue Instanz gestartet. Sie können den Zustandsspeicher auch replizieren, um eine höhere Resilienz zu erhalten.

Probleme und Überlegungen

Beachten Sie die folgenden Punkte bei der Entscheidung, wie dieses Muster implementiert werden soll:

• Implementierungskomplexität. Dieses Muster ist schwierig zu implementieren und erfordert gründliche Tests jedes Fehlermodus, den das System erleben kann. Planen Sie Fehlerinjektionstests neben Funktionstests.

• Wiederholen Sie die Amplifikation. Unabhängige Wiederholungsgrenzen auf der Agent-, Orchestrierungslaufzeit-, Messaging- und Supervisor-Ebene sowie in der Clientbibliothek vervielfachen die Zahl der Aufrufe an eine ausfallende Abhängigkeit. Legen Sie den Scheduler als Besitzer eines dauerhaften End-to-End-Wiederholungsbudgets fest, und konfigurieren oder deaktivieren Sie Wiederholungen auf den anderen Ebenen, damit ihr kombiniertes Maximum das Budget nicht überschreiten kann.

• Einlasssteuerung. Das Muster beschränkt nicht, wie viel Arbeit gleichzeitig im Flug sein kann. Da der Scheduler so aufgebaut ist, dass er niemals die akzeptierte Arbeit verliert, erzeugt ein langsamer oder fehlerhafter Downstream-Dienst eine wachsende Population von Verarbeitungsdatensätzen und nicht sichtbaren Rückdruck für den Submitter. Der Übermittlungspfad benötigt eine eigene Annahmesteuerung, z. B. eine begrenzte Warteschlange, eine Obergrenze für gleichzeitig in Bearbeitung befindliche Aufgaben oder die Ablehnung neuer Einreichungen, wenn der Rückstau einen Schwellenwert überschreitet. Dieser Backpressure-Mechanismus hilft sicherzustellen, dass ein Vorfall in einem nachgelagerten System nicht unbemerkt zu einem unbegrenzten Rückstau im Zustandsspeicher führt.

• Dauerhaftigkeit des Wiederherstellungszustands. Die Wiederherstellungs- und Logik für Wiederholungsversuche des Schedulers ist komplex und hängt von dem im Statusspeicher gespeicherten Zustand ab. Möglicherweise müssen Sie auch die erforderlichen Informationen in einem persistenten Speicher aufzeichnen, um eine Ausgleichstransaktion auszuführen, und die Ausgleichstransaktion selbst kann fehlschlagen. Behandeln Sie den Statusspeicher und jedes Protokoll für Kompensationstransaktionen als vorrangige dauerhafte Ressourcen. Diese Datenbestände müssen den Scheduler, die Agents und den Supervisor überdauern, und sie müssen unabhängig von den Workern, die in sie schreiben, wiederherstellbar sein.

  Important

  Das Kompensationsprotokoll muss die Datenklassifizierung der Daten übernehmen, die es nachverfolgen muss. Wenn ein Schritt Kunden- oder Zahlungsdaten verarbeitet, übernimmt das Protokoll der Kompensationstransaktion diese Sensibilität und die zugehörigen Aufbewahrungsregeln.

• Problem beim Dual-Write. Das Einreichen einer Aufgabe umfasst in der Regel mehr als einen persistenten Schreibvorgang. Eine Aufgabe muss z. B. sowohl einen Anwendungsdatensatz in einer Geschäftsdatenbank als auch einen ersten Datensatz im Statusspeicher schreiben. Diese Schreibvorgänge verwenden keine gemeinsame Transaktion. Wenn also nur einer der beiden Schreibvorgänge erfolgreich abgeschlossen wird, hat ein Anwendungsdatensatz möglicherweise keinen Datensatz im Statusspeicher, oder ein Datensatz im Statusspeicher hat möglicherweise keinen Anwendungsdatensatz. Das aktuelle Muster selbst löst dieses Problem mit zwei Schreibvorgängen nicht. Häufig verwendete Lösungen umfassen Schreibvorgänge innerhalb einer dauerhaften Orchestrierung mit einer kompensierenden Löschung im Fehlerfall, die Anwendung des Transactional-Outbox-Musters oder die Verwendung eines stabilen Bezeichners, wie etwa der anwendungseigenen Aufgaben-ID, damit jeder Schreibvorgang sicher wiederholt werden kann.

• Workflow- und Statusversionsverwaltung. Lang laufende Aufgaben können sich über mehrere Bereitstellungen erstrecken, sodass Änderungen an der Workflow-Logik oder am persistierten Zustand das erneute Abspielen, die Wiederherstellung oder die Kompensation laufender Vorgänge verhindern können. Versionieren Sie beide Verträge und behalten Sie kompatiblen Code sowie eine kompatible Zustandsverwaltung bei, bis keine aktive Aufgabe mehr davon abhängt.

• Vergütungsergebnisse. Eine Ausgleichstransaktion kann abgeschlossen werden, fehlschlagen oder auf halbem Weg stecken bleiben. Der Zustandsautomat, den der Scheduler verwaltet, muss alle diese Zustände darstellen. Wenn Fehler der einzige Endzustand ist, ist eine festhängende Kompensation nicht von einem Schritt zu unterscheiden, der fehlgeschlagen ist, bevor die Kompensation ausgeführt wurde, und Operatoren verlieren das Signal, das sie zum Eingreifen brauchen. Unterscheiden Sie im Statusspeicherschema zwischen Kompensation in Bearbeitung, abgeschlossener Kompensation und fehlgeschlagener Kompensation, anstatt sie in einem einzigen Fehler-Zustand zusammenzufassen.

• Takt des Vorgesetzten Wie oft der Supervisor ausgeführt werden sollte, ist eine bewusste Abwägung. Es sollte häufig genug ausgeführt werden, damit fehlgeschlagene oder mit Zeitüberschreitung abgebrochene Schritte die Arbeit nicht über einen längeren Zeitraum blockieren, aber nicht so oft, dass es zu einer Belastung und zu Kosten für den Zustandsspeicher wird. Optimieren Sie das Intervall mit der typischen Schrittdauer und der akzeptablen Erkennungsverzögerung für einen hängen gebliebenen Schritt, und überprüfen Sie es erneut, wenn das Workflowvolumen wächst.

• Schritt-Idempotenz. Ein Agent kann einen Schritt mehrmals ausführen. Beispielsweise kann der Supervisor den Fertigstellungszeitpunkt verlängern und den Scheduler bitten, einen Schritt erneut auszuführen, dessen ursprüngliche Ausführung bereits eine Wirkung hatte, die der Scheduler nie gesehen hat. Daher muss die Logik, die jeden Schritt implementiert, idempotent sein.

• Operative Sichtbarkeit. Das Laufzeitverhalten des Musters befindet sich in Zustandsspeicherübergängen und nicht in synchronen Antworten. Operatoren können nur sehen, was der Zustandsspeicher und die Arbeiter ausgeben. Entscheiden Sie, was der Scheduler, die Agents und der Supervisor ausgeben sollen und welche Schwellenwerte Warnungen auslösen sollen.

• Scheduler-Neustart und Wiederherstellung. Wenn der Scheduler nach einem Fehler neu gestartet wird oder der Workflow, der vom Scheduler ausgeführt wird, unerwartet beendet wird, muss der Scheduler in der Lage sein, den Status eines Vorgangs zu ermitteln, der bei einem Fehler aufgetreten ist, und den Vorgang ab diesem Zeitpunkt fortsetzen. Die Implementierungsdetails dieser Wiederherstellung sind in der Regel systemspezifisch. Beispielsweise kann sich ein Scheduler, der auf einer Orchestrierungslaufzeit mit Prüfpunkten basiert, darauf verlassen, dass die Laufzeit den Verlauf erneut abspielt und die Ausführung fortsetzt, während ein benutzerdefinierter Scheduler den aktuellen Zustand laufender Vorgänge selbst aus dem Zustandspeicher rekonstruieren muss. Wenn ein Vorgang nicht wiederhergestellt werden kann, muss die bereits für diesen Vorgang ausgeführte Arbeit rückgängig gemacht werden, was eine Ausgleichstransaktion erfordern kann.

Wann dieses Muster verwenden

Verwenden Sie dieses Muster in folgenden Fällen:

• Ein Prozess wird in einer verteilten Workload ausgeführt und muss resilient bleiben gegenüber sowohl Kommunikationsfehlern als auch Betriebsausfällen in den Diensten und Ressourcen, die er koordiniert.

• Hintergrundaufträge koordinieren mehrstufige Workflows, deren Schritte Remotedienste oder Ressourcen umfassen, und die Workflows als Ganzes müssen entweder abgeschlossen oder sauber rückgängig gemacht werden. Häufige Beispiele sind die Auftragsverarbeitung und die Ressourcenbereitstellung. Weitere Informationen finden Sie unter Bewährte Methoden für Hintergrundaufträge.

Dieses Muster ist möglicherweise nicht geeignet, wenn:

• Die Aufgabe ruft keine Remotedienste auf oder greift nicht auf Remoteressourcen zu. Es gibt keine verteilte Fehleroberfläche für die Rollen "Scheduler", "Agent" und "Supervisor", um sie abzumildern. Der Koordinationsaufwand des Musters erhöht Kosten ohne Ausfallsicherheitsvorteil.

Arbeitslastgestaltung

Bewerten Sie, wie Sie das Scheduler-Agent-Supervisor-Muster beim Entwurf einer Workload verwenden, um die in den Azure Well-Architected Framework-Säulen erörterten Ziele und Prinzipien zu erfüllen. Die folgende Tabelle enthält Anleitungen dazu, wie dieses Muster die Ziele jeder Säule unterstützt.

Wenn dieses Muster Kompromisse innerhalb einer Säule einführt, sollten Sie sie gegen die Ziele der anderen Säulen berücksichtigen.

Beispiel

In diesem Beispiel wird eine Webanwendung bereitgestellt, die ein E-Commerce-System auf Microsoft Azure implementiert. Benutzer durchsuchen Produkte und platzieren Aufträge über ein Web-Front-End, und die Hintergrundmitarbeiter im Auftragsverarbeitungspfad rufen einen Remotedienst auf, der anfällig für vorübergehende und längere Fehler ist. Die Auftragsverarbeitung implementiert das Muster "Scheduler Agent Supervisor" mithilfe von Durable Functions, Azure Service Bus und Azure Cosmos DB.

Eine Übermittlungsaktivität schreibt in die Auftragsdatenbank und in einen Cosmos DB-Zustandsspeicher, ein Durable-Functions-Orchestrator übernimmt ausstehende Zustandsdatensätze und leitet Arbeit über ein Paar von Service-Bus-Anforderungs- und -Antwortwarteschlangen an einen Agenten weiter, und ein Supervisor durchsucht den Zustandsspeicher nach abgelaufenen CompleteBy-Zeitpunkten.

Das folgende Diagramm zeigt eine allgemeine Ansicht der Azure Lösung.

1. Die Anwendung sendet eine Anforderung an eine Warteschlange, um die Bestellung zu verarbeiten.
2. Im Rahmen des Einreichungsprozesses werden Anfragen abgerufen, Auftragsdetails in die Auftragsdatenbank eingetragen und ein Datensatz für den Auftrag im Statusspeicher angelegt.
3. Der Scheduler sucht im State-Store nach einem Auftrag, bei dem LockedBy auf null gesetzt ist, und die Workflow-Logik im Scheduler behandelt den Auftrag.
4. Die Workflowlogik sendet Anfragen an Agenten und empfängt Antworten von ihnen über Nachrichtenwarteschlangen.
5. Workflowaufgaben verwenden Agents, um den Remotedienst aufzurufen.
6. Der Supervisor sucht nach Aufträgen mit einem abgelaufenen CompleteBy-Wert und aktualisiert diesen Wert, damit der Scheduler den Prozess erneut ausführen kann.

Einreichung

Wenn ein Kunde eine Bestellung abordnet, sendet das Web-Front-End eine Bestellnachricht an eine Service Bus Warteschlange. Eine Übermittlungsfunktion empfängt die Nachricht im PeekLock-Modus, fügt die Bestelldetails in die Auftragsdatenbank ein und erstellt einen Zustandsspeicherdatensatz für den Bestellvorgang.

Da die Auftragsdatenbank und die mit Azure Cosmos DB erstellte Datenbank unterschiedliche Ressourcen sind und keine gemeinsame Transaktion nutzen, behandelt die Funktion jeden Schreibvorgang für sich als idempotent. Die Funktion verwendet die Bestell-ID als stabilen Schlüssel, erstellt den jeweils fehlenden Datensatz und akzeptiert einen vorhandenen Datensatz erst dann, wenn überprüft wurde, dass dessen unveränderliche Bestelldaten mit der Nachricht übereinstimmen. Aufgrund widersprüchlicher Daten versetzt die Funktion die Nachricht in den „Dead-Letter“-Status und benachrichtigt einen Operator, anstatt einen Datensatz zu überschreiben.

Der Datensatz enthält die folgenden Felder:

Wenn die Übermittlungsaktivität den Datensatz zum ersten Mal schreibt, kopiert sie OrderID aus der neuen Bestellung, setzt LockedBy und CompleteBy auf null, setzt Pending auf ProcessState und setzt FailureCount auf 0.

Scheduling

Der Scheduler ist ein Orchestrator von Durable Functions. Eine Starterfunktion fragt Azure Cosmos DB nach Datensätzen ab, bei denen LockedBy null ist und ProcessStatePending ist. Die Funktion erstellt aus OrderID und der Nummer des nächsten Versuchs eine versuchsspezifische Orchestrierungsinstanz-ID. Ein bedingtes Update setzt Processing auf ProcessState und LockedBy auf diese Instanz-ID, bevor der Starter die Orchestrierung plant. Dieser Anspruch verhindert, dass zwei Starter denselben Versuch planen.

Jedes Update von der Orchestrierung überprüft außerdem, ob LockedBy noch mit seiner Instanz-ID übereinstimmt. Diese Überprüfung verhindert, dass ein abgelaufener Versuch den Zustand eines Ersatzversuchs ändert. Die übergreifende Parallelität kommt aus der gleichzeitigen Ausführung vieler Orchestrierungsinstanzen, nicht von Parallelität innerhalb einer Reihenfolge. Die Orchestrierung setzt CompleteBy und steuert den Workflow.

Der Orchestrator ruft die Bestelldetails aus der Auftragsdatenbank ab und führt den Workflow als Sequenz von Aktivitätsfunktionen aus. Wenn ein Schritt den Remotedienst benötigt, ruft er einen Agent auf.

Ausführung

Der Agent kann eine Aktivitätsfunktion sein, wenn die Arbeit nur kurz läuft und in derselben Function App ausgeführt wird, oder ein separater Worker, der über ein Anforderungs-/Antwort-Warteschlangenpaar in Service Bus erreicht wird, wenn er in einer anderen Laufzeit oder über Vertrauensgrenzen hinweg ausgeführt wird. In beiden Fällen lässt der Orchestrator einen persistenten Timer gegen die Antwort des Agents antreten, um die CompleteBy-Frist zu erkennen.

Wenn der Agent über Service Bus erreicht ist, empfängt eine durch die Warteschlange ausgelöste Funktion die Antwort und verwendet den Durable Functions Client, um ein externes Ereignis auszulösen, das die Orchestrierungsinstanz-ID und eine stabile Ereignis-ID enthält. Der Orchestrator dedupliziert externe Ereignisse, indem doppelte Erkennung aktiviert und eine stabile MessageId Einstellung für jede Anforderung festgelegt wird, sodass Service Bus Duplikate verwerfen können, die durch Wiederholungen eingeführt werden.

Wenn der Agent eine Antwort vom Remotedienst empfängt, bevor der dauerhafte Timer ausgelöst wird, gibt der Agent das Ergebnis an den Orchestrator zurück. Der Orchestrator schließt den Schritt ab und aktualisiert ProcessState nur dann auf Processed, wenn LockedBy weiterhin die aktuelle Orchestrierung identifiziert. Sollte der Timer zuerst ausgelöst werden, behandelt der Orchestrator den Schritt als fehlgeschlagen, beendet das Warten und schließt den Vorgang ab, ohne den Statusdatensatz zu ändern.

Der Agent hört nach seiner eigenen Frist kooperativ damit auf, neue Nebeneffekte zu starten, aber bereits begonnene Arbeit könnte weiterlaufen. Der Zustandsspeicherdatensatz verbleibt dann im Processing Zustand mit einem abgelaufenen CompleteBy Wert, sodass der Supervisor die Wiederherstellung anordnen kann. Verwenden Sie Idempotenz oder ein zielseitig erzwungenes Fencing-Token, um zu verhindern, dass ein überlappender Versuch eine Nebenwirkung dupliziert oder mit ihr in Konflikt gerät.

Wenn der Agent beim Kontaktieren des Remotediensts einen nicht behebbaren, nicht vorübergehenden Fehler erkennt, wird eine Fehlerantwort an den Orchestrator zurückgegeben. Der Orchestrator setzt Error auf ProcessState und löst ein Ereignis aus, das einen Operator benachrichtigt, der den Fehler untersuchen und den fehlgeschlagenen Verarbeitungsschritt erneut übermitteln kann.

Aufsicht

Der Supervisor fragt den Azure Cosmos DB-Statusspeicher regelmäßig nach Bestellungen im Status Processing mit einem abgelaufenen CompleteBy ab. Da OrderID der Partitionsschlüssel ist, erreicht diese Abfrage jede physische Partition, auch wenn ProcessState und CompleteBy indiziert sind. Der Prozess begrenzt jeden Scan um ein CompleteBy Zeitfenster, eine maximale Ergebnisanzahl und eine Fortsetzungstoken-Paging und überwacht die Anforderungseinheit (RU)-Belastung.

Größere Workloads führen einen separaten Wiederherstellungsindex oder eine separate Warteschlange, die entsprechend dem Zugriffsmuster des Supervisors partitioniert ist. Wenn der Supervisor einen abgelaufenen Datensatz findet, verwendet er eine bedingte Aktualisierung, die den abgelaufenen Wert LockedBy überprüft, bevor FailureCount erhöht wird. Wenn FailureCount unter einem konfigurierten Schwellenwert liegt, setzt der Supervisor LockedBy auf null zurück, aktualisiert CompleteBy mit einer neuen Ablaufzeit und setzt ProcessState zurück auf Pending, sodass der Starter einen neuen Versuch planen kann. Wenn FailureCount den Schwellenwert überschreitet, stuft der Supervisor den Fehler als nicht vorübergehend ein, setzt ProcessState auf Error und löst ein Ereignis aus, das einen Operator benachrichtigt.

Statusberichterstattung

Möglicherweise muss der Orchestrator auch die Anwendung, die die Bestellung übermittelt hat, über den Fortschritt und den endgültigen Status auf dem Laufenden halten, was im Diagramm nicht dargestellt ist. Die Anwendung und der Orchestrator werden absichtlich entkoppelt. Die Anwendung weiß nicht, welche Orchestrierungsinstanz die Reihenfolge verarbeitet, und die Orchestrierung weiß nicht, welche Anwendungsinstanz sie bereitgestellt hat. Aufgrund dieser Entkopplung kann der Orchestrator keine Statusaktualisierungen synchron zurückgeben.

Um den Auftragsstatus zurück zu melden, stellt jede Übermittlungsanwendung eine eigene private, zugriffsgesteuerte Service Bus Antwortwarteschlange bereit. Die an die Submission-Aktivität gesendete Anfrage enthält den Bezeichner dieser Warteschlange, den die Submission-Aktivität im State-Store-Eintrag der Bestellung erfasst, damit der Orchestrator an die richtige Warteschlange senden kann, anstatt eine Rundsendung auszuführen. Der Orchestrator veröffentlicht dann Statusmeldungen wie Anfrage empfangen, Bestellung abgeschlossen oder Bestellung fehlgeschlagen an diese Warteschlange, einschließlich OrderID, sodass die Anwendung jede Nachricht der ursprünglichen Anfrage zuordnen kann.

Unterstützende Technologien

Ordnen Sie die logischen Rollen des Musters Diensten zu, die Ihren Workflow und den betrieblichen Anforderungen entsprechen:

• Scheduler: Verwenden Sie Durable Functions für die codeorientierte Orchestrierung oder Azure Logic Apps für visuelle Workflows und die Integration über Connectoren.

• Agent-Messaging: Verwenden Sie Service Bus Warteschlangen für asynchrone Anforderungs- und Antwortnachrichten.

• Statusspeicher: Verwenden Sie Azure Cosmos DB für Dokumentstatus oder Azure SQL-Datenbank für relationale Zustands- und Datensatzübergreifende Transaktionen.

• Aufsichtsperson: Verwenden Sie einen Funktionstimertrigger für einfache Scans oder einen Container-Apps-Auftrag , wenn Sie eine Containerlaufzeit benötigen.

• Vergütungsprotokoll: Speichern Sie Kompensationseinträge mit Vorgangsstatus oder in Azure Tabellenspeicher oder Blob Storage.

Nächste Schritte

• Wählen Sie zwischen Azure Functions und Azure Logic Apps für die Workflow-Orchestrierung aus.
• Versionieren Sie Durable Functions-Orchestrierungen, um laufende Workflows bei Bereitstellungen zu schützen.
• Verhindern Sie Nachrichtenverlust und die Doppelverarbeitung von Nachrichten in Azure Service Bus, indem Sie Nachrichtenbestätigung, Idempotenz und Dead-Letter-Behandlung kombinieren.

Zugehörige Ressourcen

Die folgenden Muster sind unter Umständen bei der Implementierung dieses Musters ebenfalls relevant:

• Wiederholungsmuster: Ein Agent kann dieses Muster verwenden, um einen Vorgang, der auf einen Remote-Dienst oder eine Ressource zugreift und zuvor fehlgeschlagen ist, transparent zu wiederholen. Verwenden Sie sie, wenn die Ursache des Fehlers voraussichtlich vorübergehend ist und durch einen Wiederholungsversuch behoben werden kann.

• Circuit-Breaker-Muster. Ein Agent, der eine Verbindung zu einem Remotedienst oder einer Ressource herstellt, kann dieses Muster verwenden, um Fehler zu bewältigen, deren Behebung unterschiedlich lange dauern kann, damit sich wiederholte Aufrufe nicht bei einer Abhängigkeit aufstauen, von der wahrscheinlich keine Antwort zu erwarten ist.

• Muster „Kompensationstransaktion“. Wenn ein Scheduler seinen Workflow nicht erfolgreich abschließen kann, muss die bereits ausgeführte Arbeit möglicherweise rückgängig gemacht werden. Das Kompensationstransaktionsmuster beschreibt, wie diese Arbeit bei Vorgängen rückgängig gemacht werden kann, die dem Modell der letztendlichen Konsistenz folgen, was in den lang andauernden Geschäftsprozessen, die ein Scheduler koordiniert, üblich ist.

• Führungswahlmuster. Wenn mehrere Supervisor-Instanzen gleichzeitig laufen, müssen sie sich abstimmen, damit sie nicht darum konkurrieren, denselben fehlgeschlagenen Schritt wiederherzustellen. Das Wahlmuster von Leader beschreibt, wie ein einzelner Koordinator für diese Arbeit gewählt wird.