Hoe coördineert een Saga-patroon omkeerbare AI-acties voor thuis?

Een saga coördineert omkeerbare AI-acties thuis door één workflow op te delen in geordende stappen en compenserende acties uit te voeren wanneer een latere stap mislukt.

Dit is nuttig wanneer een agent meerdere onafhankelijke services aanraakt die geen transactie kunnen delen. De workflow registreert de voortgang, detecteert het punt waarop de fout optrad en draait de stappen die kunnen worden teruggedraaid doelbewust terug.

Een saga splitst één actie thuis op in meerdere lokale stappen

Een saga coördineert een workflow die meerdere onafhankelijke systemen omvat door elke stap te behandelen als een lokale transactie of bijwerking. De volledige bewerking slaagt pas nadat de vereiste stappen zijn voltooid.

Het Saga-patroon wordt gedefinieerd als een reeks lokale transacties die via berichten of orkestratie worden gecoördineerd. Het is nuttig wanneer één globale ACID-transactie niet alle deelnemers kan omvatten. Het Saga-patroon splitst een grotere transactie op in een reeks lokale transacties, wat goed aansluit op acties thuis die uit meerdere stappen bestaan in het overzicht van het Saga-patroon.

Een AI-workflow thuis kan een mediaservice stoppen, een bibliotheek verplaatsen, een mount bijwerken, metadata vernieuwen en de service opnieuw starten.

Elk onderdeel wordt lokaal vastgelegd, ook al is de volledige workflow niet atomair.

Elke omkeerbare stap definieert een compensatie

Een saga rolt niet elke service terug met één databaseopdracht. Stappen die kunnen worden teruggedraaid, definiëren compenserende acties die eerder werk semantisch herstellen of tenietdoen.

Microservices.io legt uit dat een fout compenserende transacties activeert voor eerder voltooide stappen. Compensatie herstelt de consistentie in plaats van de geschiedenis uit te wissen. Azure beschrijft compenserende acties voor omkeerbare sagastappen en ondersteunt daarmee het compensatiemodel dat wordt gebruikt in het Azure Saga-patroon.

MoveFile kan worden gecompenseerd met MoveFileBack en DisableShare met EnableShare. Sommige externe acties hebben mogelijk geen perfecte tegenhanger en moeten dienovereenkomstig worden gemarkeerd.

Een orkestrator kan de voorwaartse en omgekeerde volgorde bepalen

In een op orkestratie gebaseerde saga kent één workflowonderdeel de volgorde, verstuurt het opdrachten, registreert het antwoorden en beslist het of de workflow doorgaat of dat de compensatie begint.

Microservices.io laat zien hoe een saga-orkestrator stappen en compensaties aanroept. Een centrale toestandsmachine is op een thuisserver vaak eenvoudiger te controleren dan een netwerk van onafhankelijke reacties. De Saga-richtlijnen van Temporal laten zien hoe een orkestrator compensaties kan registreren en aanroepen wanneer een latere stap mislukt, wat overeenkomt met de coördinatie in omgekeerde volgorde in het Temporal Saga-patroon.

Wanneer een late stap mislukt, worden compensaties normaal gesproken uitgevoerd in omgekeerde afhankelijkheidsvolgorde.

Als een mount is gewijzigd nadat bestanden zijn verplaatst, moet de workflow de mount herstellen voordat de gegevens worden teruggezet.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Choreografie verspreidt de coördinatie over gebeurtenissen

Met een op choreografie gebaseerde saga reageert elke deelnemer op gebeurtenissen en genereert deze de volgende gebeurtenis. Hierdoor verdwijnt één centrale coördinator, maar wordt de logica van de workflow verspreid over abonnees.

Het Saga-patroon maakt expliciet onderscheid tussen choreografie en orkestratie. Beide kunnen compensaties coördineren, maar de waarneembaarheid verschilt. AWS onderscheidt orkestratie van gebeurtenisgestuurde choreografie, wat de afweging rond coördinatie ondersteunt die wordt beschreven in AWS saga-orkestratie.

Voor een kleine zelfgehoste workflow is orkestratie vaak eenvoudiger te inspecteren. Choreografie kan nog steeds geschikt zijn voor systemen waarin onafhankelijke services al via een eventbus communiceren.

Compensatie vereist idempotentie en een stabiele actie-identiteit

Een compensatie kan na een time-out of crash opnieuw worden uitgevoerd. Daarom moet deze veilig opnieuw kunnen worden uitgevoerd of kunnen vaststellen dat de doeltoestand al is hersteld.

Het sagamodel gaat uit van expliciete semantiek voor lokale transacties en compenserende transacties. Stabiele workflow- en stap-ID's helpen om een nieuwe poging te onderscheiden van een dubbele uitvoering. De Saga-richtlijnen van IBM benadrukken lokale transacties en compenserend gedrag en onderstrepen daarmee waarom pogingen en compensaties stabiele identiteiten en idempotente uitvoering nodig hebben in de implementatierichtlijnen van IBM voor Saga.

Dit sluit aan op de herhaalde tool-aanroeplussen van agents van ZimaSpace: een herstelworkflow moet weten of deze veilig wordt hervat of een bijwerking opnieuw uitvoert.

Een saga kan niet elke actie echt omkeerbaar maken

Sommige huishoudelijke acties hebben onomkeerbare externe gevolgen.

Een afgeleverd bericht, een veilig gewist bestand of een aankoop bij een derde partij kan niet altijd ongedaan worden gemaakt met een omgekeerde API-aanroep.

Saga's vertrouwen op compensatie in plaats van op universeel gedistribueerd terugdraaien. Onomkeerbare stappen moeten daarom laat in de workflow worden uitgevoerd en zorgvuldig worden afgeschermd. De bespreking van patronen voor gedistribueerde transacties door Red Hat benadrukt dat compensatie een corrigerende actie op bedrijfsniveau is en geen universeel terugdraaimechanisme. Daarmee wordt de grens aangegeven in patronen van Red Hat voor gedistribueerde transacties.

De strategie van ZimaSpace om agents eerst alleen-lezen-tools te laten gebruiken biedt een veiliger verloop van observatie naar wijziging; een saga coördineert vervolgens de wijzigingen die bewust zijn toegestaan.