Bewerken

Patroon voor gedistribueerde transacties van Saga

Azure

Het Saga-ontwerppatroon is een manier om gegevensconsistentie in microservices te beheren in scenario's met gedistribueerde transacties. Een saga is een reeks transacties die elke service bijwerken en een bericht of gebeurtenis publiceert om de volgende transactiestap te activeren. Als een stap mislukt, voert de saga compenserende transacties uit die de voorgaande transacties tegenwerken.

Context en probleem

Een transactie is één eenheid van logica of werk, die soms uit meerdere bewerkingen bestaat. Binnen een transactie is een gebeurtenis een statuswijziging die plaatsvindt in een entiteit en een opdracht bevat alle informatie die nodig is om een actie uit te voeren of een latere gebeurtenis te activeren.

Transacties moeten atomisch, consistent, geïsoleerd en duurzaam (ACID) zijn. Transacties binnen één service zijn ACID, maar voor gegevensconsistentie tussen services is een strategie voor transactiebeheer tussen services vereist.

In multiservicesarchitecturen:

  • Atomiciteit is een ondeelbare en onherleidbare set bewerkingen die allemaal of geen bewerkingen moeten plaatsvinden.
  • Consistentie betekent dat de transactie de gegevens alleen van de ene geldige status naar een andere geldige status brengt.
  • Isolatie garandeert dat gelijktijdige transacties dezelfde gegevensstatus produceren als sequentieel uitgevoerde transacties.
  • Duurzaamheid zorgt ervoor dat vastgelegde transacties doorgevoerd blijven, zelfs in het geval van een systeemstoring of stroomstoring.

Een database-per-microservicemodel biedt veel voordelen voor microservicearchitecturen. Door domeingegevens in te kapselen, kan elke service het beste gegevensarchieftype en -schema gebruiken, zo nodig een eigen gegevensarchief schalen en worden geïsoleerd van fouten van andere services. Het garanderen van gegevensconsistentie in servicespecifieke databases brengt echter uitdagingen met zich mee.

Gedistribueerde transacties zoals het tweefase doorvoerprotocol (2PC) vereisen dat alle deelnemers aan een transactie doorvoeren of terugdraaien voordat de transactie kan worden voortgezet. Sommige implementaties van deelnemers, zoals NoSQL-databases en berichtbrokering, bieden echter geen ondersteuning voor dit model.

Een andere beperking voor gedistribueerde transacties is synchroniciteit en beschikbaarheid van communicatie tussen processen (IPC ). Door het besturingssysteem geleverde IPC staat afzonderlijke processen toe om gegevens te delen. Om gedistribueerde transacties door te voeren, moeten alle deelnemende services beschikbaar zijn, waardoor de algehele beschikbaarheid van het systeem mogelijk wordt verminderd. Architecturale implementaties met IPC- of transactiebeperkingen zijn kandidaten voor het Saga-patroon.

Oplossing

Het Saga-patroon biedt transactiebeheer met behulp van een reeks lokale transacties. Een lokale transactie is de atomische werkinspanning die wordt uitgevoerd door een saga-deelnemer. Elke lokale transactie werkt de database bij en publiceert een bericht of gebeurtenis om de volgende lokale transactie in de saga te activeren. Als een lokale transactie mislukt, voert de saga een reeks compenserende transacties uit die de wijzigingen ongedaan maken die zijn aangebracht door de voorgaande lokale transacties.

Saga overzicht.

In Saga patronen:

  • Compenseerbare transacties zijn transacties die mogelijk kunnen worden teruggedraaid door een andere transactie te verwerken met het tegenovergestelde effect.
  • Een draaitransactie is het go/no-go-punt in een saga. Als de draaitransactie wordt doorgevoerd, wordt de saga uitgevoerd totdat deze is voltooid. Een draaitransactie kan een transactie zijn die niet kan worden compenseerbaar of opnieuw kan worden geprobeerd, of de laatste compenseerbare transactie of de eerste transactie die opnieuw kan worden geprobeerd in de saga.
  • Transacties die opnieuw kunnen worden geprobeerd , zijn transacties die de draaitransactie volgen en gegarandeerd slagen.

Er zijn twee algemene saga-implementatiemethoden, choreografie en orchestration. Elke aanpak heeft een eigen set uitdagingen en technologieën om de werkstroom te coördineren.

Choreografie

Choreografie is een manier om saga's te coördineren waarbij deelnemers gebeurtenissen uitwisselen zonder een gecentraliseerd controlepunt. Met choreografie publiceert elke lokale transactie domeinevenementen die lokale transacties in andere services activeren.

Overzicht van choreografie

Voordelen

  • Geschikt voor eenvoudige werkstromen waarvoor weinig deelnemers nodig zijn en waarvoor geen coördinatielogica nodig is.
  • Er is geen extra service-implementatie en onderhoud vereist.
  • Introduceert geen Single Point of Failure, omdat de verantwoordelijkheden worden verdeeld over de saga-deelnemers.

Nadelen

  • Werkstroom kan verwarrend worden bij het toevoegen van nieuwe stappen, omdat het moeilijk is bij te houden welke saga-deelnemers naar welke opdrachten luisteren.
  • Er bestaat een risico op cyclische afhankelijkheid tussen saga-deelnemers omdat ze elkaars opdrachten moeten gebruiken.
  • Integratietests zijn moeilijk omdat alle services moeten worden uitgevoerd om een transactie te simuleren.

Orchestration

Indeling is een manier om saga's te coördineren waarbij een gecentraliseerde controller de saga-deelnemers vertelt welke lokale transacties moeten worden uitgevoerd. De saga orchestrator verwerkt alle transacties en vertelt de deelnemers welke bewerking moet worden uitgevoerd op basis van gebeurtenissen. De orchestrator voert saga-aanvragen uit, slaat de statussen van elke taak op en interpreteert het herstel van fouten met compenserende transacties.

Overzicht van indeling

Voordelen

  • Geschikt voor complexe werkstromen waarbij veel deelnemers of nieuwe deelnemers in de loop van de tijd worden toegevoegd.
  • Geschikt wanneer er controle is over elke deelnemer in het proces, en controle over de stroom van activiteiten.
  • Introduceert geen cyclische afhankelijkheden, omdat de orchestrator eenzijdig afhankelijk is van de saga-deelnemers.
  • Saga-deelnemers hoeven geen kennis te hebben van opdrachten voor andere deelnemers. Duidelijke scheiding van zaken vereenvoudigt bedrijfslogica.

Nadelen

  • Extra ontwerpcomplexiteit vereist een implementatie van een coördinatielogica.
  • Er is een extra foutpunt, omdat de orchestrator de volledige werkstroom beheert.

Problemen en overwegingen

Houd rekening met de volgende punten bij het implementeren van het Saga-patroon:

  • Het Saga-patroon kan in eerste instantie lastig zijn, omdat het een nieuwe manier van denken vereist over het coördineren van een transactie en het onderhouden van gegevensconsistentie voor een bedrijfsproces dat meerdere microservices omvat.
  • Het Saga-patroon is bijzonder moeilijk om fouten op te sporen en de complexiteit neemt toe naarmate de deelnemers toenemen.
  • Gegevens kunnen niet worden teruggedraaid, omdat saga-deelnemers wijzigingen doorvoeren in hun lokale databases.
  • De implementatie moet een reeks potentiële tijdelijke fouten kunnen verwerken en idempotentie bieden voor het verminderen van neveneffecten en het waarborgen van gegevensconsistentie. Idempotentie betekent dat dezelfde bewerking meerdere keren kan worden herhaald zonder het oorspronkelijke resultaat te wijzigen. Zie de richtlijnen voor het garanderen van idempotentie bij het verwerken van berichten en het samen bijwerken van de status voor meer informatie.
  • Het is het beste om waarneembaarheid te implementeren om de saga-werkstroom te bewaken en bij te houden.
  • Het gebrek aan isolatie van gegevens van deelnemers zorgt voor uitdagingen op het duurzaamheidsniveau. De saga-implementatie moet tegenmaatregelen omvatten om afwijkingen te verminderen.

De volgende afwijkingen kunnen optreden zonder de juiste maatregelen:

  • Verloren updates, wanneer de ene saga schrijft zonder wijzigingen te lezen die door een andere saga zijn aangebracht.
  • Vuile leesbewerkingen, wanneer een transactie of een saga updates leest die zijn gemaakt door een saga die deze updates nog niet heeft voltooid.
  • Fuzzy/niet-repeatable leesbewerkingen, wanneer verschillende saga-stappen verschillende gegevens lezen omdat er een gegevensupdate plaatsvindt tussen de leesbewerkingen.

Voorgestelde tegenmaatregelen om afwijkingen te verminderen of te voorkomen zijn onder andere:

  • Semantische vergrendeling, een vergrendeling op toepassingsniveau waarbij de compensable transactie van een saga gebruikmaakt van een semafoor om aan te geven dat er een update wordt uitgevoerd.
  • Commutatieve updates die in elke volgorde kunnen worden uitgevoerd en hetzelfde resultaat opleveren.
  • Pessimistische weergave: Het is mogelijk dat de ene saga vuile gegevens leest, terwijl een andere saga een compensable transactie uitvoert om de bewerking terug te draaien. Pessimistische weergave wijzigt de volgorde van de saga, zodat de onderliggende gegevens worden bijgewerkt in een transactie die opnieuw kan worden geprobeerd, waardoor de mogelijkheid van een vervuilde leesbewerking wordt geëlimineerd.
  • Waarde voor opnieuw lezen controleert of de gegevens ongewijzigd zijn en werkt vervolgens de record bij. Als de record is gewijzigd, worden de stappen afgebroken en kan de saga opnieuw worden gestart.
  • Een versiebestand registreert de bewerkingen op een record wanneer ze binnenkomen en voert ze vervolgens in de juiste volgorde uit.
  • Per waarde wordt het bedrijfsrisico van elke aanvraag gebruikt om het gelijktijdigheidsmechanisme dynamisch te selecteren. Aanvragen met een laag risico geven de voorkeur aan saga's, terwijl aanvragen met een hoog risico gedistribueerde transacties bevorderen.

Wanneer dit patroon gebruiken

Gebruik het Saga-patroon wanneer u het volgende moet doen:

  • Zorg voor gegevensconsistentie in een gedistribueerd systeem zonder nauwe koppeling.
  • Terugdraaien of compenseren als een van de bewerkingen in de reeks mislukt.

Het Saga patroon is minder geschikt voor:

  • Nauw gekoppelde transacties.
  • Compenserende transacties die plaatsvinden bij eerdere deelnemers.
  • Cyclische afhankelijkheden.

Voorbeeld

Orchestration-based Saga on Serverless is een saga-implementatieverwijzing met behulp van de indelingsbenadering die een scenario voor geldoverdracht simuleert met succesvolle en mislukte werkstromen.

Volgende stappen

De volgende patronen zijn mogelijk ook nuttig bij de implementatie van dit patroon:

  • Choreografie zorgt ervoor dat elk onderdeel van het systeem deelneemt aan het besluitvormingsproces over de werkstroom van een zakelijke transactie, in plaats van te vertrouwen op een centraal controlepunt.
  • Compenserende transacties maken het werk ongedaan dat wordt uitgevoerd door een reeks stappen en definiëren uiteindelijk een consistente bewerking als een of meer stappen mislukken. In de cloud gehoste toepassingen die complexe bedrijfsprocessen en werkstromen implementeren, volgen vaak dit uiteindelijke consistentiemodel.
  • Met Opnieuw proberen kan een toepassing tijdelijke fouten afhandelen wanneer deze verbinding probeert te maken met een service of netwerkresource, door de mislukte bewerking transparant opnieuw uit te voeren. Opnieuw proberen kan de stabiliteit van de toepassing verbeteren.
  • Circuitonderbreker verwerkt fouten die een wisselende hoeveelheid tijd nodig hebben om te herstellen, bij het maken van verbinding met een externe service of resource. Circuitonderbreker kan de stabiliteit en tolerantie van een toepassing verbeteren.
  • Statuseindpuntbewaking implementeert functionele controles in een toepassing waartoe externe hulpprogramma's regelmatig toegang hebben via beschikbaar gemaakte eindpunten. Bewaking van statuseindpunten kan helpen controleren of toepassingen en services correct worden uitgevoerd.