Scheduler Agent Supervisor-patroon

Coördineer een set gedistribueerde acties als één bewerking. Probeer de fouten transparant te verwerken als een van de acties mislukt, of maak het uitgevoerde werk ongedaan, zodat de gehele bewerking als één geheel slaagt of mislukt. Hierdoor wordt een gedistribueerd systeem robuuster. Het kan zo herstellen na problemen en kan acties die mislukken door tijdelijke uitzonderingen, langdurige storingen en procesfouten opnieuw uitvoeren.

Context en probleem

Een toepassing voert taken uit die uit een aantal stappen bestaan, waarvan sommige externe services aanroepen of toegang krijgen tot externe resources. De afzonderlijke stappen kunnen los van elkaar staan, maar ze worden ingedeeld door de toepassingslogica waarmee de taak wordt geïmplementeerd.

De toepassing moet er, wanneer mogelijk, voor zorgen dat taken worden uitgevoerd tot ze voltooid zijn en moet problemen oplossen die voor kunnen komen wanneer er toegang wordt gezocht tot externe services of resources. Er kunnen door verschillende oorzaken fouten optreden. Het netwerk kan bijvoorbeeld storing ervaren, de communicatie kan worden onderbroken, een externe service kan mogelijk niet reageren of is instabiel, of een externe bron kan tijdelijk niet toegankelijk zijn vanwege eventuele resourcebeperkingen. In veel gevallen zullen de fouten tijdelijk zijn en kunnen ze afgehandeld worden met behulp van het Retry-patroon.

Als de toepassing een langdurigere fout ontdekt waarvan deze niet gemakkelijk kan herstellen, moet de toepassing het systeem herstellen naar een consistente status en zo de integriteit van de gehele bewerking handhaven.

Oplossing

Het Scheduler Agent Supervisor-patroon definieert de volgende actoren. Deze actoren organiseren de stappen waaruit de taak bestaat.

• De Scheduler zorgt ervoor dat de stappen waaruit de taak bestaat, worden uitgevoerd en organiseert de werking van de stappen. Deze stappen kunnen worden samengevoegd in een pijplijn of werkstroom. De Scheduler moet ervoor zorgen dat de stappen in deze werkstroom in de juiste volgorde worden uitgevoerd. Terwijl elke stap wordt uitgevoerd, registreert de Scheduler de status van de werkstroom, zoals 'stap nog niet gestart', 'stap wordt uitgevoerd' of 'stap voltooid'. De statusinformatie moet ook een bovengrens bevatten van de tijd die is toegestaan om de stap te voltooien, de zogenaamde volledige tijd. Als een stap toegang nodig heeft tot een externe service of resource, roept de Scheduler de juiste Agent aan en geeft de Scheduler de details van het te verrichten werk door. De Scheduler communiceert doorgaans met een agent met behulp van asynchrone aanvraag-/antwoordberichten. Dit kan worden geïmplementeerd met behulp van wachtrijen, maar er kunnen ook andere gedistribueerde berichttechnologieën worden gebruikt.

  De Scheduler voert een soortgelijke functie uit als de Process Manager in het Process Manager-patroon. De feitelijke werkstroom wordt doorgaans gedefinieerd en geïmplementeerd door een werkstroomengine die door de Scheduler wordt beheerd. Door deze aanpak wordt de bedrijfslogica in de werkstroom losgekoppeld van de Scheduler.

• De Agent bevat logica waarin een aanroep naar een externe dienst is ingekapseld, of toegang tot een externe resource waarnaar wordt verwezen door een stap in een taak. Elke Agent verpakt doorgaans aanroepen naar één service of resource en implementeert daarbij geschikte foutenafhandeling en pogingslogica (onderhevig aan time-outbeperking, waarover later meer). Bij het implementeren van logica voor opnieuw proberen geeft u een stabiele id door voor alle nieuwe pogingen, zodat de externe service deze kan gebruiken voor elke ontdubbelingslogica die deze mogelijk heeft. Als de stappen in de werkstroom die door de Scheduler wordt uitgevoerd verschillende services en resources in verschillende stappen gebruiken, kan elke stap verwijzen naar een andere Agent (dit is een implementatiedetail in het patroon).

• De Supervisor bewaakt de status van de stappen in de taak die door de Scheduler worden uitgevoerd. Het wordt periodiek uitgevoerd (de frequentie is systeemspecifiek) en onderzoekt de status van de stappen die door de Scheduler worden onderhouden. Als de Supervisor een stap ontdekt die onderbroken of mislukt is, zorgt hij ervoor dat de geschikte Agent de stap herstelt of de juiste corrigerende actie uitvoert (hiervoor moet mogelijk de status van een stap worden bewerkt). Houd er rekening mee dat het herstel of de corrigerende acties door de Scheduler en Agents worden geïmplementeerd. De Supervisor vraagt alleen aan of deze acties kunnen worden uitgevoerd.

De Scheduler, Agent en Supervisor zijn logische onderdelen. De fysieke implementatie van deze onderdelen hangt af van de gebruikte technologie. Verschillende logische agents kunnen bijvoorbeeld worden geïmplementeerd als onderdeel van één webservice.

De Scheduler houdt in een duurzame gegevensopslag, 'statusopslag' genoemd, informatie bij over de voortgang van de taak en de status van elke stap. De Supervisor kan deze informatie gebruiken om te helpen bepalen welke stap er is mislukt. De afbeelding geeft de verhouding tussen de Scheduler, de Agents, de Supervisor en de statusopslag weer.

Wanneer de toepassing gereed is om een taak uit te voeren, verzendt deze een aanvraag naar de Scheduler. De Scheduler registreert de statusinformatie over de taak en de stappen van de taak (bijvoorbeeld 'stap nog niet gestart') in de statusopslag en voert vervolgens de bewerkingen uit die door de werkstroom zijn gedefinieerd. Terwijl de Scheduler elke stap start, werkt deze de informatie over de status van die stap bij in de statusopslag (bijvoorbeeld: 'wordt uitgevoerd').

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 aan de service door moet geven of nodig heeft om toegang te krijgen tot de resource, evenals de voltooiingsdeadline voor de bewerking. Als de Agent zijn bewerking met succes heeft voltooid, stuurt deze een reactie terug aan de Scheduler. De Scheduler werkt de statusinformatie dan bij in de statusopslag (bijvoorbeeld 'stap voltooid') en voert vervolgens de volgende stap uit. Dit proces gaat door totdat de volledige taak is voltooid.

Een Agent kan pogingslogica implementeren die nodig is om zijn werk uit te voeren. Als de Agent zijn werk echter niet voltooit voordat de voltooiingsdeadline verloopt, neemt de Scheduler aan dat de bewerking is mislukt. In dat geval moet de Agent zijn werk onderbreken en niet proberen om iets terug te sturen naar de Scheduler (zelfs geen foutmelding) of om een vorm van herstel uit te voeren. De reden voor deze beperking is dat er, nadat een stap is onderbroken of mislukt, mogelijk een ander exemplaar van de Agent staat ingepland om de mislukte stap uit te voeren (dit proces wordt later beschreven).

Als de taak van de Agent mislukt, ontvangt de Scheduler geen antwoord. Het patroon maakt geen onderscheid tussen een stap die is onderbroken en een stap die daadwerkelijk is mislukt.

Wanneer er een stap wordt onderbroken of een stap mislukt, bevat de statusopslag een record die aangeeft dat de stap wordt uitgevoerd, maar de voltooiingsdeadline is overschreden. De Supervisor zoekt naar dergelijke stappen en probeert ze te herstellen. Een mogelijke strategie is dat de Supervisor de volledige waarde bijwerkt om de beschikbare tijd voor het voltooien van de stap uit te breiden en vervolgens een bericht te verzenden naar de Scheduler die de stap identificeert waarop een time-out is opgetreden. De Scheduler kan vervolgens proberen deze stap te herhalen. Voor dit ontwerp moeten de taken echter idempotent zijn. Het systeem moet infrastructuur bevatten om consistentie te behouden. Zie herhaalbare infrastructuur, Azure-toepassingen ontwerpen voor tolerantie en beschikbaarheid en handleiding voor beslissingen over resourceconsistentie voor meer informatie.

De Supervisor moet mogelijk voorkomen dat dezelfde stap opnieuw wordt uitgevoerd als deze voortdurend mislukt of een time-out optreedt. Om dit te doen, kan de Supervisor voor elke stap een telling van nieuwe pogingen onderhouden, samen met de statusinformatie, in het statusarchief. Als dit aantal hoger is dan een vooraf opgegeven drempel, kan de Supervisor een langere tijd wachten voordat er een bericht naar de Scheduler wordt verzonden om de stap opnieuw uit te voeren, in de verwachting dat de fout gedurende deze periode wordt opgelost. De Supervisor kan ook een bericht naar de Scheduler verzenden om aan te vragen of de volledige taak ongedaan kan worden gemaakt door een Compensating Transaction-patroon te implementeren. Deze benadering is afhankelijk van de Scheduler en de Agents die de benodigde informatie verzenden om de compenserende bewerkingen te implementeren voor elke stap die succesvol is voltooid.

Het doel van de Supervisor is niet om de Scheduler en de Agents te bewaken en deze opnieuw te starten wanneer ze mislukken. Dit aspect van het systeem moet worden verwerkt door de infrastructuur waarin deze onderdelen worden uitgevoerd. Analoog hieraan moet de Supervisor ook geen kennis hebben van de bedrijfsactiviteiten die met behulp van de taken van de Scheduler worden uitgevoerd (ook niet van hoe er moet worden gecompenseerd als deze taken mislukken). Dit is het doel van de werkstroomlogica die door de Scheduler wordt geïmplementeerd. De enige verantwoordelijkheid van de Supervisor is om te bepalen of een stap is mislukt en om de stap te herhalen of de volledige taak met inbegrip van de mislukte taak ongedaan te maken.

Als de Scheduler na een fout opnieuw wordt opgestart of de werkstroom die door de Scheduler wordt uitgevoerd, onverwacht wordt beëindigd, moet de Scheduler in staat zijn om de status te bepalen van een actieve taak die tijdens het uitvoeren is mislukt en gereed zijn om deze taak vanaf dat punt op te pakken. De implementatiedetails van dit proces zijn waarschijnlijk systeemspecifiek. Als de taak niet kan worden hersteld, is het mogelijk om het werk dat door de taak al is uitgevoerd, ongedaan te maken. Het is misschien ook nodig om een compenserende transactie te implementeren.

Het belangrijkste voordeel van dit patroon is dat het systeem robuust is in het geval van onverwachte tijdelijke of onherstelbare fouten. Het systeem kan worden gebouwd om zelfherstel te zijn. Als bijvoorbeeld een Agent of de Scheduler mislukt, kan er een nieuwe worden opgestart en kan de Supervisor ervoor zorgen dat een taak wordt hervat. Als de Supervisor mislukt, kan er een ander exemplaar worden gestart en kan dat exemplaar het overnemen vanaf het punt waarop de fout optrad. Als de Supervisor is geprogrammeerd om periodiek te worden uitgevoerd, kan er na een vooraf gedefinieerd interval automatisch een nieuw exemplaar worden gestart. De statusopslag kan worden gerepliceerd om een nog hoger niveau van robuustheid te bereiken.

Problemen en overwegingen

U moet de volgende punten overwegen wanneer u besluit hoe u dit patroon wilt implementeren:

• Het kan moeilijk zijn om dit patroon te implementeren en elke mogelijke fout in het systeem moet uitgebreid worden getest.

• De herstel-/pogingslogica die door de Scheduler wordt geïmplementeerd, is complex en afhankelijk van de statusinformatie in de statusopslag. Wellicht is het ook nodig om de vereiste informatie te registreren die vereist is om een compenserende transactie te implementeren in de duurzame gegevensopslag. Een compenserende transactie kan ook mislukken.

• De frequentie waarmee de Supervisor wordt uitgevoerd, is van belang. De Supervisor moet vaak genoeg worden uitgevoerd om te voorkomen dat een mislukte stap een toepassing voor een langere tijd blokkeert, maar ook niet zo vaak dat hij een te zware belasting vormt.

• De stappen die door een Agent worden uitgevoerd, kunnen meer dan één keer worden uitgevoerd. De logica die deze stappen implementeert, moet idempotent zijn.

Wanneer dit patroon gebruiken

Gebruik dit patroon wanneer een proces dat in een gedistribueerde omgeving (zoals de cloud) wordt uitgevoerd, bestand moet zijn tegen communicatiefouten en/of operationele fouten.

Dit patroon is mogelijk niet geschikt voor taken die geen externe services aanroepen of geen toegang krijgen tot externe resources.

Workloadontwerp

Een architect moet evalueren hoe het Scheduler Agent Supervisor-patroon kan worden gebruikt in het ontwerp van hun workload om de doelstellingen en principes te verhelpen die worden behandeld in de pijlers van het Azure Well-Architected Framework. Voorbeeld:

Net als bij elke ontwerpbeslissing moet u rekening houden met eventuele compromissen ten opzichte van de doelstellingen van de andere pijlers die met dit patroon kunnen worden geïntroduceerd.

Opmerking

Een webtoepassing die een e-commercesysteem implementeert, is in Microsoft Azure geïmplementeerd. Gebruikers kunnen deze toepassing uitvoeren om door beschikbare producten te bladeren en bestellingen te plaatsen. De gebruikersinterface wordt als webrol uitgevoerd en de onderdelen van het bestelproces van de toepassing worden als een set werkrollen geïmplementeerd. Een deel van de logica van de bestellingsverwerking omvat toegang tot een externe service. Dit aspect van het systeem kan gevoelig zijn voor tijdelijke of langdurige fouten. Daarom hebben de ontwerpers het Scheduler Agent Supervisor-patroon gebruikt om de onderdelen van de bestellingsverwerking van het systeem te implementeren.

Wanneer een klant een bestelling plaatst, genereert de toepassing een bericht waarin de bestelling wordt beschreven en verzendt de toepassing dit bericht naar een wachtrij. Een afzonderlijk indieningsproces, uitgevoerd als werkrol, ontvangt het bericht, voegt de bestellingsinformatie toe in de bestellingsdatabase en maakt een record voor het bestellingsproces in de statusopslag. Houd er rekening mee dat de invoegingen in de bestellingsdatabase en in de statusopslag worden uitgevoerd als onderdeel van dezelfde bewerking. Het indieningsproces is zo ontworpen dat beide invoegingen tegelijkertijd worden voltooid.

De statusinformatie die tijdens het indieningsproces voor de bestelling wordt gemaakt, omvat:

• OrderID. De id van de bestelling in de bestellingsdatabase.

• LockedBy. De exemplaar-id van de werkrol die de bestelling verwerkt. Er kunnen meerdere huidige exemplaren van de werkrol zijn die de Scheduler uitvoeren, maar elke bestelling moet worden verwerkt door één exemplaar.

• CompleteBy. De periode waarin een bestelling moet zijn verwerkt.

• ProcessState. De huidige status van de taak die de bestelling verwerkt. De mogelijke statussen zijn:

  • In behandeling. De bestelling is gemaakt maar de verwerking ervan is nog niet gestart.
  • Wordt verwerkt. De bestelling wordt momenteel verwerkt.
  • Verwerkt. De bestelling is succesvol verwerkt.
  • Fout. De bestellingsverwerking is mislukt.

• FailureCount. Het aantal keer dat er is geprobeerd de bestelling te verwerken.

In deze statusinformatie is het veld OrderID gekopieerd van de bestellings-id van de nieuwe bestelling. De velden LockedBy en CompleteBy zijn ingesteld op null, het veld ProcessState is ingesteld op Pending en het veld FailureCount is ingesteld op 0.

De Scheduler wordt ook uitgevoerd als onderdeel van een werkrol en implementeert de bedrijfslogica waarmee de bestelling wordt verwerkt. Een exemplaar van de Scheduler die naar nieuwe bestellingen zoekt, controleert de statusopslag op records waar het veld LockedBy null is en het veld ProcessState in behandeling is. Wanneer de Scheduler een nieuwe bestelling vindt, vult de Scheduler het veld LockedBy onmiddellijk in met zijn eigen exemplaar-id, wordt het veld CompleteBy ingesteld op een passende tijd en wordt het veld ProcessState ingesteld op 'Wordt verwerkt'. De code is zo ontworpen dat deze exclusief en atomisch is. Op die manier wordt ervoor gezorgd dat twee concurrerende exemplaren van de Scheduler niet kunnen proberen om gelijktijdig dezelfde bestelling te verwerken.

De Scheduler voert vervolgens de bedrijfswerkstroom uit om de bestelling asynchroon te verwerken, waarbij deze de waarde in het veld OrderID doorgeeft vanuit de statusopslag. De werkstroom die de bestelling verwerkt, ontvangt de informatie van de bestelling van de bestellingsdatabase en voert zijn werk uit. Wanneer een stap in de werkstroom van het bestellingsproces een externe service moet aanroepen, wordt er een Agent gebruikt. De werkstroomstap communiceert met de Agent met behulp van een paar Azure Service Bus-berichtwachtrijen die als aanvraag-/antwoordkanaal fungeren. In de afbeelding ziet u een weergave op hoog niveau van de oplossing.

Het bericht dat vanuit een werkstroomstap naar de Agent wordt verzonden, beschrijft de bestelling en bevat de voltooiingsdeadline. Als de Agent een antwoord ontvangt van de externe service voordat de voltooiingsdeadline is verstreken, verzendt deze een antwoordbericht naar de Service Bus-wachtrij waarnaar de werkstroom luistert. Wanneer de werkstroomstap het geldige antwoordbericht ontvangt, wordt de verwerking voltooid en wordt het ProcessState veld van de orderstatus ingesteld op verwerkt. Nu is de bestellingsverwerking met succes voltooid.

Als de voltooiingsdeadline verstrijkt voordat de Agent een antwoord heeft ontvangen van de externe service, stopt de Agent de verwerking en breekt hij de verwerking van de bestelling af. Op dezelfde manier breekt ook de werkstroom de verwerking van de bestelling af als de voltooiingsdeadline is verstreken. In beide gevallen blijft de status van de bestelling in de statusopslag ingesteld op 'Wordt verwerkt', maar de voltooiingsdeadline geeft aan dat de tijd voor de verwerking van de bestelling voorbij is en het proces dus waarschijnlijk is mislukt. Houd er rekening mee dat ook wanneer de Agent die toegang krijgt tot de externe dienst of de werkstroom die de bestelling verwerkt (of beide), onverwacht wordt beëindigd, de informatie in de statusopslag op 'Wordt verwerkt' blijft staan en uiteindelijk de voltooiingsdeadline verstrijkt.

Als de Agent een niet-herstelbare, permanente fout ontdekt terwijl hij contact probeert te maken met de externe dienst, kan de Agent een foutmelding terugsturen naar de werkstroom. De Scheduler kan de status van de bestelling instellen op 'Fout' en een gebeurtenis genereren die een operator waarschuwt. De operator kan proberen om de reden voor de fout handmatig op te lossen en de mislukte verwerkingsstap vervolgens opnieuw indienen.

De Supervisor controleert periodiek de statusopslag op bestellingen met een verstreken voltooiingsdeadline. Als de Supervisor een record vindt, neemt de waarde van het veld FailureCount toe. Als de waarde van het aantal fouten onder een bepaalde drempelwaarde ligt, stelt de Supervisor het veld LockedBy opnieuw in op null, werkt hij het veld CompleteBy bij met een nieuwe verlooptijd en stelt hij het veld ProcessState in op 'In behandeling'. Een exemplaar van de Scheduler kan deze bestelling ophalen en de verwerking ervan uitvoeren zoals was gepland. Als de waarde van het aantal fouten boven een bepaalde drempelwaarde uitkomt, wordt ervan uitgegaan dat de fout permanent is. De Supervisor stelt de status van de bestelling dan in op 'Fout' en genereert een gebeurtenis die een operator waarschuwt.

In dit voorbeeld is de Supervisor geïmplementeerd in een afzonderlijke werkrol. U kunt verschillende strategieën gebruiken om de taak van de Supervisor uit te voeren, waaronder het gebruik van de Azure Scheduler-service (niet te verwarren met het Scheduler-onderdeel in dit patroon). Bezoek de pagina Scheduler voor meer informatie over de Azure Scheduler-service.

Hoewel het in dit voorbeeld niet wordt weergegeven, kan het nodig zijn dat de Scheduler de toepassing die de bestelling heeft ingediend, op de hoogte houdt van de voortgang en status van de bestelling. De toepassing en de Scheduler zijn van elkaar geïsoleerd om eventuele onderlinge afhankelijkheden te voorkomen. De toepassing heeft geen kennis van welk Scheduler-exemplaar de bestelling verwerkt en de Scheduler weet niet welk specifiek exemplaar van een toepassing de bestelling heeft geplaatst.

Als u wilt dat de bestelstatus wordt gerapporteerd, kan de toepassing zijn eigen individuele antwoordwachtrij gebruiken. De details van deze antwoordwachtrij worden in dat geval opgenomen als onderdeel van de verzonden aanvraag naar het indieningsproces, waarna deze informatie in de statusopslag wordt opgenomen. De Scheduler plaatst dan berichten aan deze wachtrij waarin de status van de bestelling wordt gemeld (aanvraag ontvangen, bestelling voltooid, bestelling mislukt enz.). In deze berichten moet de bestellings-id zijn opgenomen, zodat deze door de toepassing kan worden gecorreleerd met de oorspronkelijke aanvraag.

Volgende stappen

De volgende richtlijnen zijn mogelijk ook relevant bij de implementatie van dit patroon:

• Asynchronous Messaging Primer (Inleiding in asynchrone berichtpatronen). De onderdelen in het Scheduler Agent Supervisor-patroon worden doorgaans afzonderlijk uitgevoerd en communiceren asynchroon. In het patroon wordt een aantal van de benaderingen beschreven die kunnen worden gebruikt om asynchrone communicatie op basis van berichtwachtrijen te implementeren.

• Reference 6: A Saga on Sagas (Referentiemateriaal 6: een saga van saga's). Een voorbeeld waarin wordt getoond hoe het CQRS-patroon gebruikmaakt van een procesbeheerder (onderdeel van CQRS-richtlijnen).

• Microsoft Azure Scheduler

Verwante resources

De volgende patronen zijn mogelijk ook relevant bij het implementeren van dit patroon:

• Retry-patroon. Een Agent kan dit patroon gebruiken om transparant een eerder mislukte bewerking opnieuw uit te voeren waarmee toegang wordt verkregen tot een externe dienst of resource. Geschikt voor gebruik wanneer de verwachting is dat de fout tijdelijk is en kan worden gecorrigeerd.

• Circuitonderbrekerpatroon. Een Agent kan dit patroon gebruiken om fouten af te handelen waarvoor een wisselende hoeveelheid tijd nodig is om ze te corrigeren, wanneer er verbinding wordt gemaakt met een externe service of resource.

• Patroon Compenserende transactie. Als de werkstroom die door een Scheduler wordt uitgevoerd, niet succesvol kan worden voltooid, kan het nodig zijn om eerder uitgevoerd werk ongedaan te maken. In het Compensating Transaction-patroon wordt beschreven hoe u dit kunt doen voor bewerkingen die gebaseerd zijn op het Uiteindelijke consistentie-model. Deze typen bewerkingen worden vaak geïmplementeerd door een Scheduler die complexe bedrijfsprocessen en werkstromen uitvoert.

• Leader Election-patroon. Het kan nodig zijn om de acties van meerdere exemplaren van een Scheduler te coördineren om te voorkomen dat deze proberen dezelfde mislukte processen te herstellen. In het Leader Election-patroon wordt beschreven hoe u dit doet.

• Cloudarchitectuur: het Scheduler-Agent-Supervisor-patroon in het blog van Clemens Vasters

• Process Manager-patroon