Saga: orchestration, choreography és kompenzáció

Célok

A lecke végére el tudod magyarázni, mit old meg a saga, miben különbözik az orchestration és a choreography, és miért nem elosztott rollback a kompenzáció.

Miért kell?

Ha egy üzleti művelet több adatgazdát érint, nincs közös tranzakció, amely vagy mindent véglegesít, vagy semmit (5.1). A saga azt a kérdést kezeli, hogyan érhető el mégis egy összefüggő végeredmény, ha a lépések külön helyi tranzakciókban történnek.

Mi a saga?

A microservices.io meghatározása szerint a saga helyi tranzakciók sorozata. Minden lépés a saját szolgáltatásának adatbázisát módosítja, és üzenetet vagy eseményt tesz közzé, amely a következő lépést indítja. Ha egy lépés megsérti valamelyik üzleti szabályt, a saga kompenzáló tranzakciókat futtat, amelyek az addigi változtatásokat üzletileg ellensúlyozzák.

flowchart TD
  A["1. lépés:<br/>helyi tranzakció"] --> B["2. lépés:<br/>helyi tranzakció"]
  B --> C{"Sikerült?"}
  C -->|"Igen"| D["3. lépés"]
  C -->|"Nem"| K["Kompenzálás:<br/>az 1. lépés ellensúlyozása"]

Két koordinációs mód

Mód	Hogyan működik?	Előny	Költség
Choreography	Minden helyi tranzakció eseményt tesz közzé, amely más szolgáltatásban helyi tranzakciót indít; nincs központi vezérlő	Kevés lépésnél kis központi függés	Sok ág és ciklus mellett nehezen követhető; új fogyasztó új visszacsatolást hozhat létre
Orchestration	Egy vezénylő (orchestrator) megmondja a résztvevőknek, melyik helyi tranzakciót hajtsák végre	Áttekinthető folyamat, egy helyen leírt szabály	A vezénylő szerződése, rendelkezésre állása; tartós állapotát újraindítás után is folytatni kell tudni

Az orchestrator se vegye át a szolgáltatások saját belső szabályait.

A kompenzáció üzleti művelet

A kompenzáció nem időutazás. Egy terhelés visszatérítése új pénzügyi művelet, nem az eredeti rekord eltüntetése. Egy foglalás felszabadítása után más is elviheti az erőforrást. A kompenzáló lépés is hibázhat és ismétlődhet, ezért saját idempotencia, ismétlés és végső egyeztetési út kell hozzá (6.5). Ha automatikus helyreállítás nem lehetséges, a rendszernek felismerhető, követhető állapotot kell adnia.

Mit nem ad a saga?

A microservices.io három hátrányt említ:

• Nincs automatikus rollback: a kompenzáló tranzakciókat a fejlesztőnek kell megterveznie.
• Nincs izoláció: párhuzamos sagák és tranzakciók anomáliákat láthatnak, ezért ellenintézkedések kellenek (5.4).
• Az eredményt jelenteni kell: az aszinkron saga eredményét a kliensnek külön csatornán (késleltetett válasz, polling, értesítés) kell megtudnia.

Ezen túl egy szolgáltatás nem tud elosztott tranzakciót használni az adatbázisa és az üzenetközvetítő között, ezért az adatmentés és az üzenetküldés atomi összekapcsolására külön minta (outbox vagy event sourcing) szükséges (5.3).

Szempontok szerint

Szempont	Saga
Csatolás	A lépések szerződései és az események jelentése közös függés
Konzisztencia	Köztes állapotok láthatók; végső egyezés
Hibakezelés	Kompenzáció, ismétlés, ismeretlen eredmény kezelése
Költség	A folyamat állapotának nyilvántartása és megfigyelése

Gyakori tévhitek

Állítás	Pontosítás
„A saga ugyanaz, mint egy elosztott tranzakció.”	Nincs izoláció és nincs automatikus visszavonás.
„A kompenzáció visszaállítja az előző állapotot.”	Új üzleti műveletet hajt végre, amely ellensúlyozza a korábbit.
„A choreography egyszerűbb, mert nincs vezénylő.”	A folyamat attól még létezik, csak nehezebben követhető.
„A saga garantálja, hogy mindig sikerül.”	Garantálja, hogy a hiba kezelt, követhető állapotba jut.

Röviden

• A saga helyi tranzakciók sorozata kompenzálással.
• Két koordinációs mód: choreography és orchestration.
• A kompenzáció új üzleti művelet, nem visszavonás.
• Nincs izoláció és nincs automatikus rollback; az eredményt külön jelenteni kell.

Ellenőrző kérdések

1. Miért nem rollback a kompenzáció?
2. Mikor érdemesebb vezénylőt használni choreography helyett?
3. Mi történik, ha a kompenzáló művelet is hibázik?

Források

• Saga pattern (microservices.io) — meghatározás, két mód, hátrányok.