Saga-mönstret: Implementering av distribuerade transaktioner för mikrotjänster

I mikrotjänsternas värld kan det vara en betydande utmaning att upprätthålla datakonsistens över flera tjänster. Traditionella ACID-transaktioner (Atomicitet, Konsistens, Isolation, Durabilitet), som är vanliga i monolitiska applikationer, är ofta olämpliga för distribuerade miljöer. Det är här Saga-mönstret kommer in och erbjuder en robust lösning för att hantera distribuerade transaktioner och säkerställa dataintegritet över mikrotjänster.

Vad är Saga-mönstret?

Saga-mönstret är ett designmönster som används för att hantera en sekvens av lokala transaktioner över flera mikrotjänster. Det ger ett sätt att uppnå eventuell konsistens, vilket innebär att även om data kan vara tillfälligt inkonsekvent, kommer det så småningom att konvergera till ett konsekvent tillstånd. Istället för att förlita sig på en enda, atomär transaktion som spänner över flera tjänster, bryter Saga-mönstret ner transaktionen i en serie mindre, oberoende transaktioner, där var och en utförs av en enskild tjänst.

Varje lokal transaktion inom en Saga uppdaterar databasen för en enskild mikrotjänst. Om en av transaktionerna misslyckas, exekverar Sagan en serie kompenserande transaktioner för att ångra de ändringar som gjorts av de föregående transaktionerna, vilket effektivt återställer hela operationen.

Varför använda Saga-mönstret?

Flera faktorer gör Saga-mönstret till ett värdefullt verktyg för att hantera transaktioner i mikrotjänstarkitekturer:

Frikoppling: Sagor främjar lös koppling mellan mikrotjänster, vilket gör att de kan utvecklas oberoende utan att påverka andra tjänster. Detta är en central fördel med mikrotjänstarkitekturer.
Skalbarhet: Genom att undvika långlivade, distribuerade transaktioner förbättrar Sagor skalbarhet och prestanda. Varje mikrotjänst kan hantera sina egna transaktioner oberoende, vilket minskar konkurrens och förbättrar genomströmningen.
Resiliens: Sagor är designade för att vara motståndskraftiga mot fel. Om en transaktion misslyckas kan Sagan återställas, vilket förhindrar datainkonsekvenser och säkerställer att systemet förblir i ett konsekvent tillstånd.
Flexibilitet: Saga-mönstret erbjuder flexibilitet i hanteringen av komplexa affärsprocesser som spänner över flera tjänster. Det låter dig definiera sekvensen av transaktioner och de kompenserande åtgärder som ska vidtas vid fel.

ACID kontra BASE

Att förstå skillnaden mellan ACID och BASE (Basically Available, Soft state, Eventually consistent) är avgörande när man bestämmer om man ska använda Saga-mönstret.

ACID (Atomicitet, Konsistens, Isolation, Durabilitet): Garanterar att transaktioner behandlas på ett tillförlitligt sätt. Atomicitet säkerställer att antingen alla operationer inom en transaktion lyckas eller ingen gör det. Konsistens säkerställer att en transaktion transformerar databasen från ett giltigt tillstånd till ett annat. Isolation säkerställer att samtidiga transaktioner inte stör varandra. Durabilitet säkerställer att när en transaktion har genomförts, förblir den så även vid ett systemfel.
BASE (Basically Available, Soft state, Eventually consistent): Detta är ett annat tillvägagångssätt designat för distribuerade system. Basically Available (I grunden tillgänglig) innebär att systemet är tillgängligt för det mesta. Soft state (Mjukt tillstånd) innebär att systemets tillstånd kan förändras över tid, även utan input. Eventually consistent (Eventuellt konsekvent) innebär att systemet så småningom kommer att bli konsekvent när det slutar ta emot input. Saga-mönstret är i linje med BASE-principerna.

Två huvudsakliga implementeringsstrategier för Saga

Det finns två primära sätt att implementera Saga-mönstret: Koreografi och Orkestrering.

1. Koreografibaserad Saga

I en koreografibaserad Saga deltar varje mikrotjänst i Sagan genom att lyssna på händelser som publiceras av andra mikrotjänster och reagera därefter. Det finns ingen central orkestrerare; varje tjänst känner till sina ansvarsområden och när den ska utföra sina handlingar.

Hur det fungerar:

Sagan startar när en mikrotjänst publicerar en händelse som indikerar början på transaktionen.
Andra mikrotjänster prenumererar på denna händelse och utför sin lokala transaktion när de tar emot den.
Efter att ha slutfört sin transaktion publicerar varje mikrotjänst en annan händelse som indikerar om dess operation lyckades eller misslyckades.
Andra mikrotjänster lyssnar på dessa händelser och vidtar lämpliga åtgärder, antingen genom att gå vidare till nästa steg i Sagan eller genom att initiera kompenserande transaktioner om ett fel inträffar.

Exempel: Beställning i e-handel (Koreografi)

Beställningstjänst: Tar emot en ny beställningsförfrågan och publicerar en `BeställningSkapad`-händelse.
Lagerhanteringstjänst: Prenumererar på `BeställningSkapad`. När händelsen tas emot kontrolleras lagersaldot. Om det är tillräckligt reserveras varorna och `LagerReserverat` publiceras. Om det är otillräckligt publiceras `LagerReservationMisslyckades`.
Betaltjänst: Prenumererar på `LagerReserverat`. När händelsen tas emot behandlas betalningen. Om den lyckas publiceras `BetalningGenomförd`. Om den misslyckas publiceras `BetalningMisslyckades`.
Frakttjänst: Prenumererar på `BetalningGenomförd`. När händelsen tas emot förbereds försändelsen och `FörsändelseFörberedd` publiceras.
Beställningstjänst: Prenumererar på `FörsändelseFörberedd`. När händelsen tas emot markeras beställningen som slutförd.
Kompensation: Om `BetalningMisslyckades` eller `LagerReservationMisslyckades` publiceras, lyssnar de andra tjänsterna och utför kompenserande transaktioner (t.ex. frigör reserverat lager).

Fördelar med koreografi:

Enkelhet: Lättare att implementera för enkla arbetsflöden.
Decentraliserat: Främjar lös koppling och oberoende utveckling av mikrotjänster.

Nackdelar med koreografi:

Komplexitet: Kan bli komplext att hantera när antalet deltagare i Sagan ökar.
Synlighet: Svårt att spåra den övergripande framstegen och statusen för Sagan.
Koppling: Även om det främjar lös koppling, måste tjänsterna fortfarande vara medvetna om de händelser som publiceras av andra tjänster.

2. Orkestreringsbaserad Saga

I en orkestreringsbaserad Saga hanterar en central orkestrerare (ofta implementerad som en dedikerad tjänst eller en tillståndsmaskin) Sagan och koordinerar exekveringen av lokala transaktioner av de deltagande mikrotjänsterna. Orkestreraren talar om för varje tjänst vad den ska göra och när.

Hur det fungerar:

Sagan startar när en klient begär att orkestreraren ska initiera transaktionen.
Orkestreraren skickar kommandon till de deltagande mikrotjänsterna för att utföra sina lokala transaktioner.
Varje mikrotjänst utför sin transaktion och meddelar orkestreraren om framgång eller misslyckande.
Baserat på resultatet beslutar orkestreraren om man ska gå vidare till nästa steg eller initiera kompenserande transaktioner.

Exempel: Beställning i e-handel (Orkestrering)

Beställningsorkestrerare: Tar emot en ny beställningsförfrågan.
Beställningsorkestrerare: Skickar ett kommando till Lagerhanteringstjänsten för att reservera varor.
Lagerhanteringstjänst: Reserverar varorna och meddelar Beställningsorkestreraren.
Beställningsorkestrerare: Skickar ett kommando till Betaltjänsten för att behandla betalningen.
Betaltjänst: Behandlar betalningen och meddelar Beställningsorkestreraren.
Beställningsorkestrerare: Skickar ett kommando till Frakttjänsten för att förbereda försändelsen.
Frakttjänst: Förbereder försändelsen och meddelar Beställningsorkestreraren.
Beställningsorkestrerare: Markerar beställningen som slutförd.
Kompensation: Om något steg misslyckas skickar Beställningsorkestreraren kompenserande kommandon till relevanta tjänster (t.ex. frigör reserverat lager).

Fördelar med orkestrering:

Centraliserad kontroll: Lättare att hantera och övervaka Sagan från en central punkt.
Förbättrad synlighet: Orkestreraren ger en tydlig bild av den övergripande framstegen och statusen för Sagan.
Minskad koppling: Mikrotjänster behöver bara kommunicera med orkestreraren, vilket minskar direkta beroenden mellan dem.

Nackdelar med orkestrering:

Komplexitet: Kan vara mer komplext att implementera initialt, särskilt för enkla arbetsflöden.
Single Point of Failure: Orkestreraren kan bli en enskild felpunkt, även om detta kan mildras med redundans och feltoleransåtgärder.

Implementering av kompenserande transaktioner

En avgörande aspekt av Saga-mönstret är implementeringen av kompenserande transaktioner. Dessa transaktioner exekveras för att ångra effekterna av tidigare slutförda transaktioner vid ett fel. Målet är att återföra systemet till ett konsekvent tillstånd, även om den övergripande Sagan inte kan slutföras.

Viktiga överväganden för kompenserande transaktioner:

Idempotens: Kompenserande transaktioner bör vara idempotenta, vilket innebär att de kan exekveras flera gånger utan att ändra resultatet. Detta är viktigt eftersom fel kan uppstå när som helst, och den kompenserande transaktionen kan behöva försökas igen.
Hantering av fel: Kompenserande transaktioner kan också misslyckas. Du måste ha en strategi för att hantera fel i kompenserande transaktioner, såsom att försöka igen, logga fel och varna administratörer.
Datakonsistens: Kompenserande transaktioner bör säkerställa att data förblir konsekvent. Detta kan innebära att återställa data till sitt tidigare tillstånd, radera nyskapad data eller uppdatera data för att återspegla annulleringen av transaktionen.

Exempel på kompenserande transaktioner:

Lagerhanteringstjänst: Om Lagerhanteringstjänsten reserverade varor men betalningen misslyckades, skulle den kompenserande transaktionen vara att frigöra de reserverade varorna.
Betaltjänst: Om Betaltjänsten behandlade en betalning men frakten misslyckades, kan den kompenserande transaktionen innebära att utfärda en återbetalning.

Utmaningar och överväganden

Även om Saga-mönstret erbjuder betydande fördelar, medför det också vissa utmaningar och överväganden:

Komplexitet: Att implementera Saga-mönstret kan vara komplext, särskilt för invecklade affärsprocesser. Noggrann planering och design är avgörande.
Eventuell konsistens: Saga-mönstret ger eventuell konsistens, vilket innebär att data kan vara tillfälligt inkonsekvent. Detta kan vara ett problem för applikationer som kräver starka konsistensgarantier.
Testning: Att testa Sagor kan vara utmanande på grund av deras distribuerade natur och potentialen för fel vid olika punkter.
Övervakning: Att övervaka framstegen och statusen för Sagor är avgörande för att identifiera och lösa problem. Du måste ha lämpliga övervakningsverktyg och processer på plats.
Idempotens: Att säkerställa att transaktioner och kompenserande transaktioner är idempotenta är avgörande för att förhindra datainkonsekvenser.
Isolation: Eftersom Sagor involverar flera lokala transaktioner kan isolation vara ett problem. Strategier som semantiska lås eller optimistisk låsning kan krävas.

Användningsfall och exempel

Saga-mönstret är väl lämpat för en mängd olika användningsfall, särskilt i distribuerade system och mikrotjänstarkitekturer. Här är några vanliga exempel:

Orderhantering i e-handel: Som illustreras i exemplen ovan kan Saga-mönstret användas för att hantera hela orderlivscykeln, från skapande av order till betalningshantering och frakt.
Finansiella transaktioner: Saga-mönstret kan användas för att hantera komplexa finansiella transaktioner som involverar flera system, såsom fondöverföringar, låneansökningar och försäkringsanspråk.
Hantering av försörjningskedjan: Saga-mönstret kan användas för att samordna aktiviteter mellan flera enheter i en försörjningskedja, såsom tillverkare, distributörer och återförsäljare.
Sjukvårdssystem: Saga-mönstret kan användas för att hantera patientjournaler och samordna vården mellan olika avdelningar och vårdgivare.

Exempel: Global banktransaktion

Föreställ dig ett scenario som involverar en global banktransaktion mellan två olika banker i olika länder, underkastade olika regler och efterlevnadskontroller. Saga-mönstret kan säkerställa att transaktionen följer de definierade stegen:

Initiera transaktion: Kunden initierar en penningöverföring från sitt konto hos Bank A (i USA) till en mottagares konto hos Bank B (i Tyskland).
Bank A - Kontovalidering: Bank A validerar kundens konto, kontrollerar tillräckliga medel och säkerställer att det inte finns några spärrar eller restriktioner.
Efterlevnadskontroll (Bank A): Bank A genomför en efterlevnadskontroll för att säkerställa att transaktionen inte bryter mot regler mot penningtvätt (AML) eller några internationella sanktioner.
Penningöverföring (Bank A): Bank A debiterar kundens konto och skickar pengarna till ett clearinghus eller en mellanhandbank.
Clearinghusets behandling: Clearinghuset behandlar transaktionen, utför valutaväxling (USD till EUR) och dirigerar medlen till Bank B.
Bank B - Kontovalidering: Bank B validerar mottagarens konto och säkerställer att det är aktivt och berättigat att ta emot medel.
Efterlevnadskontroll (Bank B): Bank B genomför sin egen efterlevnadskontroll, i enlighet med tyska och EU-regler.
Kreditera konto (Bank B): Bank B krediterar mottagarens konto.
Bekräftelse: Bank B skickar ett bekräftelsemeddelande till Bank A, som sedan meddelar kunden att transaktionen är slutförd.

Kompenserande transaktioner:

Om efterlevnadskontrollen hos Bank A misslyckas, avbryts transaktionen och kundens konto debiteras inte.
Om efterlevnadskontrollen hos Bank B misslyckas, returneras medlen till Bank A och kundens konto krediteras tillbaka.
Om det uppstår problem med valutaväxling eller dirigering hos clearinghuset, återförs transaktionen och medlen returneras till Bank A.

Verktyg och tekniker

Flera verktyg och tekniker kan hjälpa till vid implementering av Saga-mönstret:

Meddelandeköer: Apache Kafka, RabbitMQ och Amazon SQS kan användas för att publicera och prenumerera på händelser i en koreografibaserad Saga.
Arbetsflödesmotorer: Camunda, Zeebe och Apache Airflow kan användas för att implementera orkestrerare och hantera komplexa arbetsflöden.
Event Sourcing: Event Sourcing kan användas för att spåra historiken av händelser i en Saga och underlätta återställning vid fel.
Distribuerade transaktionshanterare: Vissa distribuerade transaktionshanterare, såsom Atomikos, kan användas för att samordna transaktioner över flera tjänster. De kanske dock inte är lämpliga för alla mikrotjänstarkitekturer på grund av deras inneboende begränsningar i distribuerade miljöer.
Saga-ramverk: Det finns också Saga-ramverk som tillhandahåller abstraktioner och verktyg för att implementera Saga-mönstret.

Bästa praxis för implementering av Saga-mönstret

För att effektivt implementera Saga-mönstret, överväg följande bästa praxis:

Noggrann design: Analysera dina affärskrav grundligt och designa Sagan därefter. Identifiera de deltagande mikrotjänsterna, sekvensen av transaktioner och de kompenserande åtgärderna.
Idempotens: Se till att alla transaktioner och kompenserande transaktioner är idempotenta.
Felhantering: Implementera robusta felhanteringsmekanismer för att hantera fel vid vilken punkt som helst i Sagan.
Övervakning och loggning: Implementera omfattande övervakning och loggning för att spåra framstegen och statusen för Sagor.
Testning: Testa dina Sagor noggrant för att säkerställa att de fungerar korrekt och hanterar fel på ett smidigt sätt.
Semantiska lås: Implementera semantiska lås för att förhindra samtidiga uppdateringar av samma data av olika Sagor.
Optimistisk låsning: Använd optimistisk låsning för att upptäcka och förhindra konflikter mellan samtidiga transaktioner.
Välj rätt implementeringsstrategi: Överväg noggrant avvägningarna mellan koreografi och orkestrering och välj den strategi som bäst passar dina behov.
Definiera tydliga kompensationspolicyer: Upprätta tydliga policyer för hantering av kompensation, inklusive villkoren under vilka kompensation utlöses och de specifika åtgärder som ska vidtas.

Slutsats

Saga-mönstret är ett kraftfullt verktyg för att hantera distribuerade transaktioner i mikrotjänstarkitekturer. Genom att bryta ner transaktioner i en serie mindre, oberoende transaktioner och tillhandahålla en mekanism för att kompensera för fel, gör Saga-mönstret det möjligt för dig att upprätthålla datakonsistens och bygga motståndskraftiga, skalbara och frikopplade system. Även om Saga-mönstret kan vara komplext att implementera, gör de fördelar det erbjuder i termer av flexibilitet, skalbarhet och resiliens det till en värdefull tillgång för alla mikrotjänstarkitekturer.

Att förstå nyanserna i Saga-mönstret, avvägningarna mellan koreografi och orkestrering, och vikten av kompenserande transaktioner kommer att ge dig kraften att designa och implementera robusta distribuerade system som möter kraven i dagens komplexa affärsmiljöer. Att anamma Saga-mönstret är ett steg mot att bygga verkligt motståndskraftiga och skalbara mikrotjänstarkitekturer, kapabla att hantera även de mest komplexa distribuerade transaktionerna med förtroende. Kom ihåg att överväga dina specifika behov och sammanhang när du tillämpar detta mönster, och att kontinuerligt förfina din implementering baserat på verklig erfarenhet och feedback.