Vad är Saga-mönstret?

I en mikrotjänstarkitektur behöver en enskild affärsåtgärd ofta interagera med flera oberoende tjänster och deras databaser.

Traditionella databastran­saktioner, så kallade ACID-transaktioner, är utmärkta för att säkerställa konsistens i en enskild databas. De sträcker sig däremot inte enkelt över olika tjänster eller databaser.

Föreställ Er ett nätköp: en order skapas, betalningen behandlas och lagersaldot uppdateras. Vad händer om betalningen lyckas men lageruppdateringen misslyckas?

Utan en mekanism för att samordna dessa steg kan systemet hamna i ett inkonsistent tillstånd, där kunden exempelvis har betalat för en vara som fortfarande finns i lager men inte har tilldelats kundens order.

Saga-mönstret är ett sätt att hantera affärstransaktioner som sträcker sig över flera tjänster och samtidigt säkerställa datakonsistens mellan dem.

En Saga är en sekvens av lokala transaktioner. Varje lokal transaktion uppdaterar data inom en enda tjänst och publicerar en händelse som utlöser nästa steg i Sagan.

En lokal transaktion är en standardiserad, atomisk databastran­saktion som sker helt inom en enda mikrotjänst.

• Den startas och bekräftas, eller återställs, inom gränserna för tjänstens databas.
• Den säkerställer att data inom den specifika tjänsten förblir konsistent.

Sagan samordnar dessa lokala transaktioner för att uppnå ett större distribuerat affärsmål.

Vad händer om en av de lokala transaktionerna i en Saga misslyckas efter att tidigare steg redan har genomförts?

Saga-mönstret hanterar detta genom att köra kompensationstransaktioner. En kompensationstransaktion är utformad för att upphäva effekterna av en tidigare slutförd lokal transaktion.

Sagas skiljer sig från traditionella ACID-transaktioner (Atomicity, Consistency, Isolation, Durability):

• ACID: Allt eller inget, omedelbar konsekvens och stark isolering.
• Saga: Uppnår eventual consistency mellan tjänster. Den byter omedelbar atomicitet mot tillgänglighet och skalbarhet i distribuerade system.

Sagas tillhandahåller transaktionsintegritet över tid, även om transaktionerna inte är atomära direkt.

Sagas är särskilt användbara när:

• Ni behöver upprätthålla datakonsistens mellan flera oberoende mikrotjänster.
• Ni inte kan använda en distribuerad tvåfascommit, vilket ofta är fallet i mikrotjänster.
• Era affärsprocesser är komplexa och sträcker sig över flera systemgränser.

De hjälper till att hantera långvariga, distribuerade affärsprocesser på ett smidigt sätt.

Vi tar ett vanligt e-handelsscenario som exempel: att lägga en onlinebeställning.

Det kan involvera flera tjänster:

• Order Service
• Payment Service
• Inventory Service
• Shipping Service

En Saga kan samordna stegen för att säkerställa att hela processen slutförs korrekt eller återställs på rätt sätt.

Så här kan en order-Saga fungera:

1. Order Service: Skapar ordern (lokal transaktion).
2. Payment Service: Behandlar betalningen (lokal transaktion).
3. Inventory Service: Minskar lagersaldot för artikeln (lokal transaktion).
4. Shipping Service: Schemalägger leveransen (lokal transaktion).

Om exempelvis Inventory Service misslyckas med att minska lagersaldot utlöser Sagan kompensation för Payment Service och Order Service.

Ni har lärt er att Saga-mönstret hjälper till att hantera distribuerade affärstransaktioner över flera mikrotjänster.

• Det består av en sekvens av lokala transaktioner, där varje transaktion är atomär inom sin egen tjänst.
• Det använder kompensationstransaktioner för att upphäva tidigare steg om ett senare steg misslyckas.
• Sagas tillhandahåller eventual consistency, vilket gör dem lämpliga för komplexa, distribuerade processer där omedelbara ACID-egenskaper inte är möjliga.

Härnäst utforskar vi olika sätt att implementera Sagas: Choreography och Orchestration.