Scheduler Agent Supervisor-patroon

Coördineer een set gedistribueerde acties als één logische bewerking, zodat de bewerking als geheel slaagt of mislukt. Fouten transparant afhandelen of voltooid werk ongedaan maken. Deze aanpak voegt tolerantie toe aan gedistribueerde systemen door te herstellen van tijdelijke uitzonderingen, langdurige fouten en procesfouten die werkstromen met meerdere stappen onderbreken die zijn ingedeeld in externe services en resources.

Context en probleem

Toepassingen voeren vaak taken uit die meerdere stappen omvatten en sommige stappen kunnen externe services aanroepen of toegang krijgen tot externe resources onder de indeling van toepassingslogica. Interactie met iets buiten het lokale proces stelt de taak bloot aan een reeks foutmodi. De indelingslogica moet deze foutmodi afhandelen zonder de integriteit van de bewerking als geheel te verliezen.

U kunt eenvoudige situaties, zoals tijdelijke fouten die zichzelf oplossen, afhandelen met behulp van benaderingen zoals het patroon Opnieuw proberen. Wanneer fouten permanenter zijn of wanneer de orchestrator zelf uitvalt, moet het systeem een consistente status herstellen uit duurzame records en de integriteit van de algehele bewerking garanderen.

Solution

Het Scheduler Agent Supervisor-patroon coördineert een gedistribueerde taak met meerdere stappen via drie logische actoren. Deze actoren organiseren de stappen die moeten worden uitgevoerd als onderdeel van de algehele taak en verwerken zowel geslaagde als mislukte uitvoeringen.

Taakplanner

De Scheduler rangschikt de stappen waaruit de taak bestaat en organiseert de uitvoering. De Scheduler is verantwoordelijk voor het combineren van stappen in een pijplijn of werkstroom en het uitvoeren ervan in de juiste volgorde. Wanneer elke stap vordert, registreert de Scheduler de status, zoals stap die nog niet is gestart, stap wordt uitgevoerd of stap voltooid. De status bevat ook een complete-by-tijd die bepaalt hoe lang de stap maximaal mag duren.

Wanneer een stap een externe service of resource nodig heeft, roept de Scheduler een geschikte agent aan en geeft de werkgegevens hieraan door. Scheduler communiceert doorgaans met agents via asynchrone aanvraag-/antwoordberichten, vaak geïmplementeerd via wachtrijen. U kunt in plaats daarvan andere gedistribueerde berichtentechnologieën gebruiken.

Agent

Een agent bevat een aanroep naar een externe service of toegang tot een externe resource waarnaar een taakstap verwijst. Elke agent verpakt doorgaans aanroepen naar één service of resource en implementeert de juiste foutafhandeling en logica voor opnieuw proberen binnen de volledige tijd die de Scheduler oplegt. Wanneer logica voor opnieuw proberen wordt gebruikt, geeft de agent een stabiele id door voor alle nieuwe pogingen. Een downstreamservice kan dit gebruiken voor ontdubbeling.

Als verschillende stappen in de werkstroom verschillende services of resources gebruiken, kan elke stap verwijzen naar een andere agent. Deze toewijzing is een implementatiedetail van het patroon. Raadpleeg Best practices voor de afhandeling van tijdelijke fouten voor richtlijnen bij het ontwerpen van retrystrategieën.

Opzichter

De Supervisor bewaakt de status van de stappen die de Scheduler uitvoert. De Supervisor wordt periodiek uitgevoerd met de frequentie die de workload specificeert en controleert de status van de stap die de Scheduler heeft vastgelegd. Als de Supervisor stappen vindt waarvoor een time-out is opgetreden of die zijn mislukt, zorgt deze ervoor dat de juiste Agent de stap herstelt, of initieert deze een andere corrigerende actie, waaronder mogelijk het wijzigen van de stapstatus. De Supervisor vraagt deze herstelacties alleen aan. De Scheduler en agents implementeren ze.

Interacties

De Scheduler, Agent en Supervisor zijn logische onderdelen en hun fysieke implementatie is afhankelijk van de technologie die u gebruikt. U kunt bijvoorbeeld verschillende logische Agents implementeren als onderdeel van één webservice of als activiteiten binnen dezelfde gehoste worker.

De Scheduler onderhoudt taakvoortgang en status per stap in een duurzaam gegevensarchief, de statusopslag genoemd. De Supervisor gebruikt deze informatie om te bepalen of een stap is mislukt. In het volgende diagram wordt de relatie getoond tussen de Scheduler, de Agents, de Supervisor en de toestandsopslag.

• De Scheduler organiseert en voert de stappen uit die deel uitmaken van de taak als werkstroom.
• Een stap in de werkstroom kan een aanvraag verzenden naar een agent voor toegang tot een externe resource of het aanroepen van een externe service. Aanvragen en antwoorden worden doorgaans asynchroon verzonden.
• Een agent heeft toegang tot de externe resource of service. De agent moet foutafhandeling en logica voor nieuwe pogingen bevatten.
• De planner houdt de status van elke stap bij in de statusopslag wanneer elke stap start en wordt voltooid.
• De Supervisor bewaakt de status van de stappen in de toestandsopslag en kan verzoeken om de status van een stap bij te werken.
• De Supervisor vraagt de Scheduler om een mislukte stap opnieuw in te voeren.

Wanneer de toepassing gereed is om een taak uit te voeren, verzendt deze een aanvraag naar de Scheduler. De Scheduler registreert de initiële status van de taak en de bijbehorende stappen, zoals stap die nog niet is gestart, in het statusarchief en start vervolgens met het uitvoeren van de bewerkingen die de werkstroom definieert. Wanneer de Scheduler elke stap start, wordt de status van die stap bijgewerkt, zoals de stap die wordt uitgevoerd, in het statusarchief.

Als een stap naar een externe service of resource verwijst, verzendt de Scheduler een bericht naar de desbetreffende Agent. Het bericht bevat de informatie die de Agent nodig heeft om de service aan te roepen of toegang te krijgen tot de bron, samen met de uiterste voltooiingstijd en het toegestane aantal nieuwe pogingen voor de bewerking.

Een agent kan elke logica voor opnieuw proberen implementeren die geschikt is voor het werk, maar als de agent het werk niet binnen de volledige tijd voltooit, gaat de Scheduler ervan uit dat de bewerking is mislukt en stopt met wachten op een antwoord. De agent moet de deadline observeren en mag geen nieuwe bijwerkingen starten nadat de tijd is verstreken, hoewel het werk dat al wordt uitgevoerd, kan doorgaan.

Als de Agent zijn bewerking met succes heeft voltooid, stuurt deze een reactie terug aan de Scheduler. De Scheduler werkt de status bij, zodat de stap bijvoorbeeld is voltooid en de volgende stap wordt gestart. Dit proces gaat door totdat de volledige taak is voltooid.

De Scheduler moet eventuele late reacties negeren en de agent mag geen eigen werkstroomherstel uitvoeren. Als de agent zelf mislukt, ontvangt de Scheduler ook geen antwoord. De status in de statusopslag maakt opzettelijk geen onderscheid tussen een stap die een time-out krijgt en een stap die mislukt.

Wanneer een stap een time-out bereikt of mislukt, wordt het record in de statusopslag nog steeds weergegeven als wordt uitgevoerd, maar met een verstreken uiterste voltooiingstijd. De supervisor zoekt naar records in deze toestand en zorgt voor herstel.

De Supervisor moet ook voorkomen dat dezelfde stap voor onbepaalde tijd opnieuw wordt geprobeerd. De supervisor houdt voor elke stap het aantal herhalingspogingen bij, samen met de statusinformatie in de statusopslag. Als het aantal een vooraf gedefinieerde drempelwaarde overschrijdt, kan de Supervisor worden ingesteld om te wachten op een langere periode voordat de Scheduler wordt gevraagd de stap opnieuw uit te voeren, voor het geval de onderliggende fout tijdens dat interval wordt gewist.

Een mogelijke Supervisor-strategie is om de complete-by-waarde te verlengen en een bericht naar de Scheduler te sturen waarin de stap wordt geïdentificeerd waarvoor een time-out is opgetreden, zodat de Scheduler deze opnieuw kan proberen. Dit ontwerp vereist dat de staplogica idempotent is, omdat hetzelfde werk meerdere keren kan worden uitgevoerd.

De Supervisor kan ook de Scheduler vragen om de hele taak ongedaan te maken door een compenserende transactie te activeren. Deze aanpak hangt af van de Scheduler en Agents die voldoende informatie verstrekken om compenserende bewerkingen te implementeren voor elke stap die al met succes is voltooid. Het compensatielogboek heeft volgorde en duurzaamheid nodig, omdat compenserende bewerkingen doorgaans worden uitgevoerd in de omgekeerde volgorde van de stappen die zijn voltooid. Een compenserende bewerking die zelf mislukt, laat de taak achter in een toestand die noch voltooid, noch netjes teruggedraaid is. De statusopslag moet deze toestand kunnen weergeven, zodat operators deze kunnen lokaliseren en onderzoeken.

In een werkelijke implementatie van dit patroon kunnen meerdere exemplaren van de Scheduler gelijktijdig worden uitgevoerd, waarbij elk een subset van taken verwerkt. Het systeem kan ook meerdere exemplaren van elke agent of meerdere supervisors uitvoeren. Wanneer meer dan één Supervisor actief is, moeten de Supervisors coördineren, zodat ze niet concurreren om dezelfde mislukte stap of taak te herstellen. Het patroon Leiderverkiezing is een manier om supervisors te coördineren.

Het belangrijkste voordeel van dit patroon is dat het systeem veerkrachtig blijft bij zowel tijdelijke als niet-herstelbare storingen, en u kunt het zo ontwerpen dat het zelfherstellend is. Als een agent of de Scheduler uitvalt, kunt u een nieuw exemplaar starten en kan de Supervisor regelen dat de betrokken taak wordt hervat. Als de Supervisor zelf uitvalt, kan een andere instantie het overnemen vanaf het punt waar de vorige stopte. Wanneer de Supervisor volgens een planning wordt uitgevoerd, wordt een nieuw exemplaar automatisch gestart bij het volgende interval. U kunt de statusopslag ook repliceren om de veerkracht te vergroten.

Problemen en overwegingen

Houd rekening met de volgende punten bij het bepalen hoe u dit patroon implementeert:

• Implementatiecomplexiteit. Dit patroon is moeilijk te implementeren en vereist grondige tests van elke foutmodus die het systeem kan ervaren. Plan foutinjectietests samen met functionele tests.

• Versterking opnieuw proberen. Onafhankelijke limieten voor nieuwe pogingen op de lagen Agent, orchestratieruntime, clientbibliotheek, messaging en Supervisor vergroten het aantal aanroepen op een falende afhankelijkheid. Wijs de Scheduler aan als de eigenaar van een duurzaam end-to-end budget voor opnieuw proberen en configureer of schakel nieuwe pogingen uit op de andere lagen, zodat het gecombineerde maximum het budget niet kan overschrijden.

• Toegangsbeheer. Het patroon beperkt niet hoeveel werk tegelijk kan worden uitgevoerd. Omdat de Scheduler zo is ontworpen dat deze nooit werk verliest dat hij accepteert, leidt een trage of falende downstreamservice tot een groeiend aantal verwerkingsrecords in plaats van zichtbare backpressure voor de indiener. Het indieningspad heeft een eigen toelatingscontrole nodig, zoals een begrensde wachtrij, een limiet voor gelijktijdige taken die al in uitvoering zijn, of het afwijzen van nieuwe indieningen wanneer de wachtrij met wachtende taken een drempel overschrijdt. Deze backpressure helpt ervoor te zorgen dat een incident verderop in de keten niet onopgemerkt een onbegrensde achterstand in de state store veroorzaakt.

• Duurzaamheid van herstelstatus. De scheduler-herstel- en pogingslogica is complex en is afhankelijk van de status in het statusarchief. Mogelijk moet u ook de informatie vastleggen die nodig is om een compenserende transactie in een duurzame opslag te stimuleren en kan de compenserende transactie zelf mislukken. Behandel het statusarchief en eventuele compenserende transactielogboeken als eersteklas duurzame assets. Deze middelen moeten langer meegaan dan de Scheduler, de Agents en de Supervisor, en ze moeten onafhankelijk kunnen worden hersteld van de workers die ernaar schrijven.

  Important

  Het compensatielogboek moet de gegevensclassificatie overnemen van de gegevens die moeten worden bijgehouden. Als een stap klant- of betalingsgegevens accepteert, neemt het compenserende transactielogboek die gevoeligheid en de bijbehorende bewaarregels over.

• Probleem met dubbel schrijven. Het indienen van een taak omvat doorgaans meer dan één duurzame schrijfbewerking. Een taak moet bijvoorbeeld mogelijk zowel een toepassingsrecord in een bedrijfsdatabase als een initiële record in het statusarchief schrijven. Deze schrijfbewerkingen maken geen deel uit van dezelfde transactie, dus als slechts één schrijfbewerking wordt voltooid, heeft een applicatierecord mogelijk geen record in de statusopslag, of heeft een record in de statusopslag mogelijk geen applicatierecord. Het huidige patroon zelf lost dit probleem met dubbele schrijfbewerkingen niet op. Veelvoorkomende oplossingen zijn onder meer schrijven binnen een duurzame orkestratie met een compenserende verwijdering bij een mislukking, het toepassen van het Transactional Outbox-patroon, of het gebruik van een stabiele ID, zoals de eigen taak-ID van de toepassing, om elke schrijfbewerking veilig herhaalbaar te maken.

• Werkstroom- en statusversiebeheer. Langlopende taken kunnen zich over meerdere deployments uitstrekken, dus wijzigingen in de workflowlogica of de opgeslagen status kunnen het opnieuw afspelen, herstellen of compenseren van werk dat al in uitvoering is, verhinderen. Versie van beide contracten en behoud compatibele code- en statusafhandeling totdat er geen actieve taak afhankelijk is van deze.

• Compensatieresultaten. Een compenserende transactie kan worden afgerond, mislukken of halverwege vastlopen. De statusmachine die de Scheduler onderhoudt, moet al deze statussen vertegenwoordigen. Als Fout de enige terminalstatus is, ziet een vastgelopen compensatie eruit als een stap die is mislukt voordat de compensatie werd uitgevoerd en verliezen operators het signaal dat ze moeten ingrijpen. Maak onderscheid tussen compensatie wordt uitgevoerd, compensatie voltooid en compensatie mislukt in het state-store-schema in plaats van deze samen te voegen tot één enkele Fout-status.

• Frequentie van supervisor. Hoe vaak de Supervisor wordt uitgevoerd, is een bewuste afweging. Het moet vaak genoeg worden uitgevoerd zodat mislukte stappen of stappen waarvan de time-out is verstreken het werk niet langdurig blokkeren, maar niet zo vaak dat het extra belasting en kosten voor de statusopslag veroorzaakt. Stem het interval af op de gebruikelijke stapduur en de acceptabele detectievertraging voor een vastgelopen stap, en herzie dit naarmate het workflowvolume toeneemt.

• Idempotentie van stappen. Een agent kan een stap meer dan één keer uitvoeren. De Supervisor kan bijvoorbeeld de volledige tijd verlengen en de Scheduler vragen een stap opnieuw uit te voeren waarvan de oorspronkelijke uitvoering al een effect heeft geproduceerd dat de Scheduler nooit heeft gezien. Daarom moet de logica die elke stap implementeert idempotent zijn.

• Operationele zichtbaarheid. Het runtimegedrag van het patroon bevindt zich in statusopslagovergangen in plaats van in synchrone antwoorden. Operators kunnen alleen zien wat de statusopslag en de werknemers verzenden. Bepaal wat de Scheduler, Agents en Supervisor moeten verzenden en welke drempelwaarden waarschuwingen moeten activeren.

• Scheduler start en herstel. Als de Scheduler opnieuw wordt opgestart na een fout of als de werkstroom die de Scheduler uitvoert onverwacht wordt beëindigd, moet de Scheduler de status kunnen bepalen van een taak die wordt verwerkt toen deze is mislukt en de taak vanaf dat moment hervat. De implementatiedetails van dit herstel zijn doorgaans systeemspecifiek. Een Scheduler die bijvoorbeeld is gebouwd op een orchestratieruntime met checkpoints, kan erop vertrouwen dat de runtime de geschiedenis opnieuw afspeelt en de uitvoering hervat, terwijl een aangepaste Scheduler de lopende status zelf uit de statusopslag moet reconstrueren. Als een taak niet kan worden hersteld, moet het werk dat al voor die taak is uitgevoerd mogelijk ongedaan worden gemaakt, wat een compenserende transactie kan vereisen.

Wanneer gebruikt u dit patroon?

Gebruik dit patroon wanneer:

• Een proces draait in een gedistribueerde workload en moet robuust blijven bij zowel communicatiestoringen als operationele storingen in de services en resources die het coördineert.

• Achtergrondtaken organiseren werkstromen met meerdere stappen waarvan de stappen betrekking hebben op externe services of resources, en de werkstromen als geheel moeten worden voltooid of op schone wijze ongedaan worden gemaakt. Veelvoorkomende voorbeelden zijn het verwerken van bestellingen en het beschikbaar stellen van middelen. Zie Best practices voor achtergrondtaken voor meer informatie.

Dit patroon is mogelijk niet geschikt wanneer:

• De taak roept geen externe services aan of heeft geen toegang tot externe resources. Er is geen gedistribueerde foutoppervlak voor de rollen Scheduler, Agent en Supervisor om dit te verhelpen. De coördinatieoverhead van het patroon voegt kosten toe zonder tolerantievoordeel.

Ontwerp van werkbelasting

Evalueer hoe u het Scheduler Agent Supervisor-patroon gebruikt in het ontwerp van een workload om de doelstellingen en principes te verhelpen die worden behandeld in de pijlers van het Azure Well-Architected Framework. De volgende tabel bevat richtlijnen over hoe dit patroon de doelstellingen van elke pijler ondersteunt.

Als dit patroon compromissen binnen een pijler introduceert, moet u deze tegen de doelstellingen van de andere pijlers overwegen.

Voorbeeld

In dit voorbeeld wordt een webtoepassing geïmplementeerd waarmee een e-commercesysteem op Microsoft Azure wordt geïmplementeerd. Gebruikers bladeren door producten en plaatsen orders via een webfront-end en de achtergrondwerkers in het orderverwerkingspad roepen een externe service aan die gevoelig is voor tijdelijke en langdurige fouten. Orderverwerking implementeert het patroon Scheduler Agent Supervisor met behulp van Durable Functions, Azure Service Bus en Azure Cosmos DB.

Een inzendactiviteit schrijft naar de ordersdatabase en een Cosmos DB-statusopslag, een Durable Functions-orchestrator eigent zich statusrecords in behandeling toe en stuurt werk naar een Agent via een paar Service Bus-aanvraag- en antwoordwachtrijen, en een Supervisor scant de statusopslag op verlopen CompleteBy-tijden.

In het volgende diagram ziet u een algemeen overzicht van de Azure oplossing.

1. De toepassing plaatst een aanvraag in een wachtrij om de bestelling af te handelen.
2. Het indieningsproces haalt verzoeken op, voegt bestelgegevens toe aan de orderdatabase en genereert een record voor de order in de statusopslag.
3. De Scheduler zoekt in de statusopslag naar een order waarbij LockedBy op null is ingesteld, en de workflowlogica in de Scheduler verwerkt de order.
4. De werkstroomlogica verzendt aanvragen naar en ontvangt antwoorden van agents via berichtenwachtrijen.
5. Werkstroomtaken maken gebruik van agents om de externe service aan te roepen.
6. De Supervisor zoekt naar orders met een verlopen CompleteBy waarde en werkt deze waarde bij om de Scheduler in staat te stellen het proces opnieuw te bekijken.

Verzending

Wanneer een klant een order plaatst, plaatst de webfront-end een orderbericht in een Service Bus wachtrij. Een verzendfunctie ontvangt het bericht in de PeekLock-modus, voegt de ordergegevens in de orderdatabase in en maakt een record voor het statusarchief voor het orderproces.

Omdat de database met bestellingen en de database die is gemaakt met Azure Cosmos DB verschillende resources zijn en geen transactie delen, beschouwt de functie elke schrijfactie als op zichzelf idempotent. De functie gebruikt de order-id als een stabiele sleutel, maakt een record wanneer deze ontbreekt en accepteert een bestaande record pas nadat is gecontroleerd of de onveranderbare ordergegevens overeenkomen met het bericht. Conflicterende gegevens veroorzaken dat de functie het bericht in een dode letter vastlegt en een operator waarschuwt, in plaats van een record te overschrijven.

De record bevat de volgende velden:

Wanneer de indieningsactiviteit de record voor het eerst schrijft, kopieert deze OrderID van de nieuwe bestelling, stelt CompleteBy en null in op LockedBy, stelt Pending in op ProcessState en stelt FailureCount in op 0.

Scheduling

De Scheduler is een Durable Functions orchestrator. Een startersfunctie pollt Azure Cosmos DB voor records waar LockedBy null is en ProcessState isPending. De functie maakt een pogingsspecifieke orchestratie-instantie-id van OrderID en het nummer van de volgende poging. Een voorwaardelijke update stelt ProcessState in op Processing en LockedBy op die instantie-id voordat de starter de orchestratie inplant. Deze claim voorkomt dat twee starters dezelfde poging inplannen.

Elke update van de orchestratie controleert ook of LockedBy nog steeds overeenkomt met de instantie-id. Met deze controle voorkomt u dat een verlopen poging de status van een vervangingspoging wijzigt. Orderoverstijgend parallelisme ontstaat door veel orchestratie-instanties gelijktijdig uit te voeren, niet door parallelisme binnen één order. De orkestratie stelt CompleteBy in en stuurt de werkstroom aan.

De orchestrator haalt de ordergegevens op uit de orderdatabase en voert de werkstroom uit als een reeks activiteitsfuncties. Wanneer een stap de externe service nodig heeft, wordt een agent aangeroepen.

Execution

De agent kan een activiteitsfunctie zijn wanneer het werk van korte duur is en in dezelfde functie-app wordt uitgevoerd, of een afzonderlijk workerproces dat via een paar Service Bus-aanvraag-/antwoordwachtrijen wordt benaderd wanneer het in een andere runtime of over een vertrouwensgrens heen wordt uitgevoerd. In beide gevallen laat de orchestrator een persistente timer concurreren met het antwoord van de Agent om te bepalen wanneer de CompleteBy deadline is bereikt.

Wanneer de Agent via Service Bus wordt benaderd, ontvangt een door de wachtrij geactiveerde functie het antwoord en gebruikt deze de Durable Functions-client om een externe gebeurtenis te activeren die de instantie-id van de orchestration en een stabiele gebeurtenis-id bevat. De orchestrator ontdubbelt externe gebeurtenissen door dubbele detectie in te schakelen en een stabiele MessageId instelling in te stellen voor elke aanvraag, zodat Service Bus duplicaten kan negeren die worden geïntroduceerd door nieuwe pogingen.

Als de Agent een reactie van de externe service ontvangt voordat de duurzame timer afgaat, retourneert de Agent het resultaat aan de orchestrator. De orchestrator voltooit de stap en werkt ProcessState bij naar Processed alleen als LockedBy nog steeds de huidige orchestratie identificeert. Als de timer als eerste afgaat, beschouwt de orchestrator de stap als mislukt, stopt met wachten en rondt hij af zonder de statusregistratie te wijzigen.

De agent stopt op coöperatieve wijze met het starten van nieuwe neveneffecten na zijn eigen deadline, maar werk dat al in uitvoering is, kan doorgaan. De statusopslagrecord blijft vervolgens in de Processing status met een verlopen CompleteBy waarde, zodat de Supervisor herstel kan regelen. Gebruik idempotentie of een door het doelsysteem afgedwongen fencing-token om te voorkomen dat een overlappende poging een neveneffect dupliceert of ermee conflicteert.

Als de Agent een onherstelbare, niet-voorbijgaande fout detecteert bij het contact maken met de externe service, stuurt de Agent een foutreactie naar de orchestrator. De orchestrator stelt ProcessState in op Error en activeert een gebeurtenis die een operator waarschuwt, zodat deze de fout kan onderzoeken en de mislukte verwerkingsstap opnieuw kan indienen.

Supervisie

De supervisor bevraagt periodiek de Azure Cosmos DB-statusopslag op orders met de status Processing en een verlopen CompleteBy. Omdat OrderID dit de partitiesleutel is, bereikt deze query elke fysieke partitie, zelfs wanneer ProcessState en CompleteBy worden geïndexeerd. Het proces begrenst elke scan door een CompleteBy tijdvenster, een maximumaantal resultaten en paging van vervolgtokens, en bewaakt de kosten van de aanvraageenheid (RU).

Grotere workloads houden een afzonderlijke herstelindex of wachtrij bij die is gepartitioneerd volgens het toegangspatroon van de Supervisor. Wanneer de Supervisor een verlopen record vindt, wordt een voorwaardelijke update gebruikt waarmee de verlopen LockedBy waarde wordt gecontroleerd voordat deze wordt verhoogd FailureCount. Als FailureCount onder een geconfigureerde drempelwaarde ligt, zet de Supervisor LockedBy terug op null, werkt CompleteBy bij met een nieuwe vervaltijd en zet Pending terug op ProcessState, waardoor de starter een nieuwe poging kan plannen. Als FailureCount de drempelwaarde overschrijdt, behandelt de Supervisor de fout als niet-tijdelijk, stelt ProcessState in op Error en genereert een gebeurtenis die een operator waarschuwt.

Statusrapportage

De orchestrator moet mogelijk ook de toepassing die de bestelling heeft ingediend, op de hoogte houden van de voortgang en de uiteindelijke status, die niet in het diagram wordt weergegeven. De toepassing en de orchestrator worden opzettelijk losgekoppeld. De applicatie weet niet welke orchestratie-instantie de bestelling afhandelt en de orchestratie weet niet welke applicatie-instantie deze heeft geplaatst. Vanwege deze ontkoppeling kan de orchestrator geen voortgangsupdates synchroon retourneren.

Om de orderstatus terug te koppelen, stelt elke verzendende toepassing een eigen privé-antwoordwachtrij in Service Bus met toegangsbeheer beschikbaar. Het verzoek dat naar de indieningsactiviteit wordt verzonden, bevat de identificatie van die wachtrij, die door de indieningsactiviteit wordt vastgelegd in het record van de order in de statusopslag, zodat de orchestrator naar de juiste wachtrij kan posten in plaats van naar alle wachtrijen uit te zenden. De orchestrator plaatst vervolgens statusberichten zoals ontvangen aanvraag, order voltooid of order is mislukt in die wachtrij, inclusief de OrderID zodat de toepassing elk bericht kan correleren met de oorspronkelijke aanvraag.

Ondersteunende technologieën

Wijs de logische rollen van het patroon toe aan services die aansluiten bij uw werkstroom en operationele vereisten:

• Scheduler: Gebruik Durable Functions voor code-first orchestratie of Azure Logic Apps voor visuele workflows en integratie op basis van connectors.

• Agentberichten: Gebruik Service Bus wachtrijen voor asynchrone aanvraag- en antwoordberichten.

• Statusarchief: Gebruik Azure Cosmos DB voor documentstatus of Azure SQL Database voor relationele status en transacties tussen records.

• Supervisor: Gebruik een Functions-timertrigger voor lichtgewicht scans of een Container Apps-taak wanneer u een containerruntime nodig hebt.

• Compensatielogboek: Sla compensatierecords op met de taakstatus of in Azure Table Storage of Blob Storage.

Volgende stappen 

• Kies tussen Azure Functions en Azure Logic Apps voor werkstroomindeling.
• Versie Durable Functions indelingen voor het beveiligen van werkstromen tijdens de implementaties.
• Voorkom verlies van berichten en dubbele verwerking in Azure Service Bus door de verwerking van berichten, idempotentie en verwerking van dode letters te combineren.

Gerelateerde bronnen

De volgende patronen zijn mogelijk ook relevant wanneer u dit patroon implementeert:

• Retry-patroon. Een agent kan dit patroon gebruiken om een bewerking die toegang heeft tot een externe service of resource, transparant opnieuw uit te voeren en eerder is mislukt. Gebruik deze wanneer de oorzaak van de fout naar verwachting tijdelijk is en kan worden gecorrigeerd door een nieuwe poging.

• Circuit Breaker-patroon. Een agent die verbinding maakt met een externe service of resource kan dit patroon gebruiken om fouten af te handelen die een variabele hoeveelheid tijd in beslag nemen om te corrigeren. Herhaalde aanroepen stapelen zich dus niet op tegen een afhankelijkheid die waarschijnlijk niet reageert.

• Compenserende Transactie patroon. Als een Scheduler de werkstroom niet kan voltooien, moet het uitgevoerde werk mogelijk ongedaan worden gemaakt. Het patroon Compensating Transaction beschrijft hoe u dat werk ongedaan kunt maken voor bewerkingen die het model van uiteindelijke consistentie volgen, wat gebruikelijk is in de langlopende bedrijfsprocessen die door een Scheduler worden gecoördineerd.

• Leader Election-patroon. Wanneer meerdere Supervisor-exemplaren gelijktijdig worden uitgevoerd, moeten ze coördineren, zodat ze niet concurreren om dezelfde mislukte stap te herstellen. In het patroon Leiderverkiezing wordt beschreven hoe u één coördinator voor dat werk kiest.