Upravit

Model distribuovaných transakcí Saga

Azure

Model návrhu Saga je způsob, jak spravovat konzistenci dat napříč mikroslužbami ve scénářích distribuovaných transakcí. Saga je posloupnost transakcí, která aktualizuje každou službu a publikuje zprávu nebo událost pro aktivaci dalšího kroku transakce. Pokud krok selže, saga provede kompenzační transakce, které jsou proti předchozím transakcím.

Kontext a problém

Transakce je jedna jednotka logiky nebo práce, která se někdy skládá z více operací. V rámci transakce je událost změnou stavu, ke které dojde u entity, a příkaz zapouzdřuje všechny informace potřebné k provedení akce nebo aktivaci pozdější události.

Transakce musí být atomické, konzistentní, izolované a odolné (ACID). Transakce v rámci jedné služby jsou ACID, ale konzistence dat mezi službami vyžaduje strategii správy transakcí napříč službami.

V architekturách s více službami:

  • Atomicita je nedělitelná a neredukovatelná sada operací, které musí proběhnout všechny, nebo k žádné.
  • Konzistence znamená, že transakce přenese data pouze z jednoho platného stavu do jiného platného stavu.
  • Izolace zaručuje, že souběžné transakce generují stejný stav dat, který by vytvořily sekvenční transakce.
  • Stálost zajišťuje, že potvrzené transakce zůstanou potvrzené i v případě selhání systému nebo výpadku napájení.

Model databáze na mikroslužbu poskytuje mnoho výhod pro architektury mikroslužeb. Zapouzdření dat domény umožňuje každé službě používat svůj nejlepší typ a schéma úložiště dat, škálovat vlastní úložiště dat podle potřeby a být izolován před selháními jiných služeb. Zajištění konzistence dat napříč databázemi konkrétními službami však představuje výzvy.

Distribuované transakce, jako je dvoufázový protokol potvrzení (2PC), vyžadují, aby všichni účastníci transakce potvrzení nebo vrácení zpět, než transakce může pokračovat. Některé implementace účastníků, jako jsou databáze NoSQL a zprostředkovávání zpráv, ale tento model nepodporují.

Dalším omezením distribuovaných transakcí je synchronicity a dostupnost meziprocesové komunikace (IPC ). IPC poskytované operačním systémem umožňuje samostatné procesy pro sdílení dat. K potvrzení distribuovaných transakcí musí být k dispozici všechny zúčastněné služby, což může snížit celkovou dostupnost systému. Implementace architektury s omezeními IPC nebo transakcí jsou kandidáty na model Saga.

Řešení

Model Saga poskytuje správu transakcí pomocí posloupnosti místních transakcí. Místní transakce je atomické pracovní úsilí prováděné účastníkem saga. Každá místní transakce aktualizuje databázi a publikuje zprávu nebo událost, která aktivuje další místní transakci v saga. Pokud místní transakce selže, saga provede řadu kompenzačních transakcí , které vrátí zpět změny provedené předchozími místními transakcemi.

Přehled Saga.

Ve vzorech Saga:

  • Kompenzovatelné transakce jsou transakce, které mohou být potenciálně obráceny zpracováním jiné transakce s opačným efektem.
  • Kontingenční transakce je bod go/no-go v saga. Pokud se kontingenční transakce potvrdí, saga se spustí až do dokončení. Kontingenční transakce může být transakce, která není ani komensovatelná ani opakovatelná, nebo to může být poslední kompenzovatelná transakce nebo první opakovatelná transakce v saga.
  • Opakovatelné transakce jsou transakce, které následují po kontingenční transakci a jsou zaručeny, že budou úspěšné.

Existují dva společné přístupy k implementaci ságy: choreografie a orchestrace. Každý přístup má svou vlastní sadu výzev a technologií pro koordinaci pracovního postupu.

Choreografie

Choreografie je způsob, jak koordinovat ságy, kde si účastníci vyměňují události bez centralizovaného kontrolního bodu. Každá místní transakce s choreografií publikuje události domény, které aktivují místní transakce v jiných službách.

Přehled choreografie

Výhody

  • Vhodné pro jednoduché pracovní postupy, které vyžadují jen málo účastníků a nevyžadují logiku koordinace.
  • Nevyžaduje další implementaci a údržbu služby.
  • Nezavádí jediný bod selhání, protože odpovědnosti jsou rozdělené mezi účastníky ságy.

Nevýhody

  • Pracovní postup může být při přidávání nových kroků matoucí, protože je obtížné sledovat, kteří účastníci saga poslouchají, které příkazy.
  • Existuje riziko cyklické závislosti mezi účastníky saga, protože se musí vzájemně využívat příkazy.
  • Testování integrace je obtížné, protože všechny služby musí být spuštěné, aby bylo možné simulovat transakci.

Orchestrace

Orchestrace je způsob, jak koordinovat sagas, kdy centralizovaný kontroler říká účastníkům saga, jaké místní transakce se mají provést. Orchestrátor saga zpracovává všechny transakce a říká účastníkům, které operace se mají provést na základě událostí. Orchestrátor provádí požadavky saga, ukládá a interpretuje stavy jednotlivých úloh a zpracovává zotavení po selhání s kompenzačními transakcemi.

Přehled orchestrace

Výhody

  • Vhodné pro složité pracovní postupy zahrnující mnoho účastníků nebo nové účastníky přidané v průběhu času.
  • Vhodné, pokud existuje kontrola nad každým účastníkem procesu a kontrola nad tokem aktivit.
  • Nezavádí cyklické závislosti, protože orchestrátor jednostranně závisí na účastnících ságy.
  • Účastníci Saga nepotřebují vědět o příkazech pro ostatní účastníky. Jasné oddělení zájmů zjednodušuje obchodní logiku.

Nevýhody

  • Další složitost návrhu vyžaduje implementaci koordinační logiky.
  • Existuje další bod selhání, protože orchestrátor spravuje celý pracovní postup.

Problémy a důležité informace

Při implementaci modelu Saga vezměte v úvahu následující body:

  • Model Saga může být zpočátku náročný, protože vyžaduje nový způsob myšlení o tom, jak koordinovat transakci a udržovat konzistenci dat pro obchodní proces zahrnující více mikroslužeb.
  • Model Saga je obzvláště obtížné ladit a složitost roste s rostoucím nárůstem účastníků.
  • Data se nedají vrátit zpět, protože účastníci saga zavádějí změny ve svých místních databázích.
  • Implementace musí být schopná zpracovat sadu potenciálních přechodných selhání a poskytovat idempotenci pro snížení vedlejších účinků a zajištění konzistence dat. Idempotenci znamená, že stejnou operaci lze opakovat vícekrát beze změny počátečního výsledku. Další informace najdete v doprovodných materiálech k zajištění idempoteence při společném zpracování zpráv a aktualizaci stavu.
  • Nejlepší je implementovat pozorovatelnost pro monitorování a sledování pracovního postupu saga.
  • Nedostatečná izolace dat účastníků přináší problémy s odolností. Implementace saga musí obsahovat protiopatření, aby se snížily anomálie.

K následujícím anomáliím může dojít bez správných opatření:

  • Ztracené aktualizace, když jedna saga zapisuje bez čtení změn provedených jinou ságou.
  • Nečte se, když transakce nebo sága čte aktualizace provedené ságou, která ještě tyto aktualizace nedokončila.
  • Nepřerušitelná nebo neopakovatelná čtení, když různé kroky saga čtou různá data, protože mezi čtením dojde k aktualizaci dat.

Mezi navrhovaná protiopatření ke snížení nebo prevenci anomálií patří:

  • Sémantický zámek, zámek na úrovni aplikace, kde komenzovatelná transakce saga používá semafor k označení probíhající aktualizace.
  • Komutativní aktualizace , které lze provést v libovolném pořadí a dosáhnout stejného výsledku.
  • Pesimistické zobrazení: Je možné, že jedna saga čte špinavá data, zatímco jiná saga spouští komenzovatelnou transakci, která vrátí operaci zpět. Pesimistické zobrazení změní pořadí saga tak, aby se podkladová data aktualizovala v opakovatelné transakci, což eliminuje možnost špinavého čtení.
  • Znovu načtená hodnota ověří, že se data nezměnila, a pak záznam aktualizuje. Pokud se záznam změnil, kroky se přeruší a saga se může restartovat.
  • Soubor verze zaznamenává operace se záznamem, jakmile přicházejí, a pak je provede ve správném pořadí.
  • Podle hodnoty používá obchodní riziko každého požadavku k dynamickému výběru mechanismu souběžnosti. Požadavky s nízkým rizikem upřednostňují ságy, zatímco požadavky s vysokým rizikem upřednostňují distribuované transakce.

Kdy se má tento model použít

Vzor Saga použijte, když potřebujete:

  • Zajistěte konzistenci dat v distribuovaném systému bez úzkého propojení.
  • Vrácení zpět nebo kompenzace v případě, že některá z operací v posloupnosti selže.

Model Saga je méně vhodný pro:

  • Úzce propojené transakce.
  • Kompenzační transakce, ke kterým dochází u dřívějších účastníků.
  • Cyklické závislosti.

Příklad

Saga založená na orchestraci na bezserverové platformě je referenční informace o implementaci ságy využívající přístup orchestrace, který simuluje scénář převodu peněz s úspěšnými a neúspěšnými pracovními postupy.

Další kroky

Při implementaci tohoto modelu můžou být relevantní také následující modely:

  • Každá součást systému se účastní procesu rozhodování o pracovním postupu obchodní transakce, místo toho, aby se spoléhala na centrální kontrolní bod.
  • Kompenzační transakce vrátí zpět práci prováděnou řadou kroků a nakonec definují konzistentní operaci, pokud jeden nebo více kroků selže. Aplikace hostované v cloudu, které implementují složité obchodní procesy a pracovní postupy, se často řídí tímto modelem konečné konzistence.
  • Opakování umožňuje aplikaci zpracovat přechodné chyby při pokusu o připojení ke službě nebo síťovému prostředku transparentním opakováním neúspěšné operace. Opakování může zlepšit stabilitu aplikace.
  • Jistič zpracovává chyby, které při připojování ke vzdálené službě nebo prostředku zaberou proměnlivou dobu, než se zotaví. Jistič může zlepšit stabilitu a odolnost aplikace.
  • Monitorování koncového bodu stavu implementuje v aplikaci funkční kontroly, ke kterým mají externí nástroje v pravidelných intervalech přístup prostřednictvím vystavených koncových bodů. Monitorování koncového bodu stavu může pomoct ověřit, že aplikace a služby fungují správně.