Model kompenzační transakce

Tento vzor použijte k vrácení provedené práce, pokud selže jeden nebo více kroků v operaci s nakonec dosaženou konzistencí. Aplikace hostované v cloudu, které implementují složité obchodní procesy a pracovní postupy, běžně používají operace, které se řídí modelem konečné konzistence.

Kontext a problém

Cloudové aplikace často upravují data, která se šíří mezi různými zdroji dat v různých geografických umístěních. Aby se zabránilo kolizi a zlepšení výkonu v distribuovaném prostředí, měly by aplikace místo silné transakční konzistence implementovat konečnou konzistenci. V modelu konečné konzistence se typická obchodní operace skládá z řady samostatných kroků. Během těchto kroků může být celkový pohled na stav systému nekonzistentní. Po dokončení všech kroků by měl být systém ale opět konzistentní.

Zpracování chyb kroku představuje klíčový problém v modelu konečné konzistence. Po selhání může být potřeba vrátit zpět práci z dokončených kroků operace. Nemůžete ale vždy vrátit zpět data, protože ostatní souběžné instance aplikace můžou měnit data. I když souběžné instance nemění data, může být složitější vrátit krok zpět, než obnovit původní stav. Možná budete muset použít obchodní pravidla. Příklad najdete na příkladu cestovního webu.

Pokud operace, která implementuje konečnou konzistenci, zahrnuje více úložišť dat, musíte přistupovat ke každému úložišti dat, aby se změny vrátily zpět. Chcete-li zabránit tomu, aby systém zůstal nekonzistentní, je nutné spolehlivě vrátit zpět práci v každém úložišti dat.

Operace, která implementuje konečnou konzistenci, neukládá vždy do databáze ovlivněná data. Například v prostředí architektury orientované na službu (SOA) může operace vyvolat akci ve službě a změnit stav, který služba uchovává. Pokud chcete operaci vrátit zpět, musíte tuto změnu stavu vrátit zpět, což může zahrnovat opětovné vyvolání služby, aby se vrátily účinky první akce.

Řešení

Implementujte kompenzační transakci, která vrátí zpět účinky dokončených kroků v původní operaci. Možná si myslíte, že systém můžete jednoduše obnovit do původního stavu, ale tento přístup může přepsat změny z jiných souběžných instancí aplikace. Místo toho musí kompenzační transakce inteligentně počítat s souběžnou prací. Tento proces je obvykle specifický pro aplikaci a závisí na původní operaci.

Pracovní postup můžete použít k implementaci nakonec konzistentní operace, která vyžaduje kompenzaci. Při spuštění původní operace systém zaznamenává informace o jednotlivých krocích a o tom, jak ji vrátit zpět. Pokud operace selže, pracovní postup se převine přes dokončené kroky a jednotlivé kroky se vrátí zpět.

Diagram znázorňující pracovní postup s dopředu provedenými kroky a kompenzačními akcemi Uživatel zahájí operaci, která spouští krok 1, krok 2 a krok 3 postupně. Pokud jsou všechny kroky úspěšné, proces se dokončí. Pokud dojde k selhání po některém kroku, kompenzační akce se spustí v obráceném pořadí, aby vrátily dokončenou práci, a tím se vytvoří stav po úhradě škod.

Zatímco každý krok je samostatná akce, společně tvoří nakonec konzistentní operaci. Systém musí provést kroky a odpovídající operace vrácení zpět pro každý krok. Pokud zákazník zruší, tyto operace vrácení zpět se můžou spouštět jako kompenzační transakce.

Selhání pouze v jednom kroku ne vždy vyžaduje obnovení celého systému s pomocí kompenzační transakce. Například ve scénáři cestovního webu si zákazník rezervuje lety F1, F2 a F3, ale nepodaří se rezervovat pokoj v hotelu H1. Nabídnout zákazníkovi pokoj v jiném hotelu je lepší než zrušit lety. Zákazník se stále může rozhodnout zrušit, což aktivuje kompenzační transakci a zruší rezervace letů. Zákazník by ale měl toto rozhodnutí učinit, ne systém. Pokud jsou rozhodnutí vysoce ovlivněná nebo obtížně automatizovaná, zahrňte do rozhodovacího procesu člověka.

Zvažte tyto důležité body:

• Kompenzační transakce nemusí muset vrátit zpět práci v přesném obráceném pořadí původní operace.

• Možná budete moct paralelně provést některé kroky pro vrácení zpět.

• Možná budete muset použít obchodní pravidla. Zrušení rezervace letu například nemusí zákazníka opravovat k úplné refundaci.

Tento přístup je podobný modelu distribuovaných transakcí Saga.

Kompenzační transakce jsou nakonec konzistentní operace a mohou selhat. Systém by měl zaznamenávat průběh, aby mohl obnovit kompenzační transakci z bodu selhání. Při opakování může krok běžet několikrát, takže každý krok navrhujte jako idempotentní příkaz.

Ruční zásah je někdy jediný způsob, jak se zotavit z neúspěšného kroku. V těchto situacích by systém měl vyvolat výstrahu, která obsahuje podrobné informace o příčině selhání.

Problémy a důležité informace

Při rozhodování o implementaci tohoto modelu zvažte následující body:

• Nemusí být snadné určit, kdy krok v operaci, která implementuje konečnou konzistenci, selže. Krok nemusí selhat okamžitě, ale místo toho se zablokuje. Možná budete muset implementovat mechanismus časového limitu.

• Logiku kompenzace není snadné generalizovat. Kompenzační transakce je specifická pro aplikaci. Spoléhá na to, že aplikace má dostatek informací k vrácení účinků jednotlivých kroků v neúspěšné operaci.

• Kompenzační transakce nefungují vždy. Definujte kroky v kompenzační transakci jako idempotentní příkazy, abyste je mohli opakovat, pokud kompenzační transakce sama selže.

• Infrastruktura, která zpracovává kroky, musí splňovat následující kritéria:

  • Je odolný jak v původní operaci, tak v kompenzační transakci.

  • Neztratí informace potřebné ke kompenzaci neúspěšného kroku.

  • Spolehlivě monitoruje průběh logiky kompenzace. Kompenzační transakce se spouštějí poté, co jsou původní operace potvrzeny, a jiné transakce mohou měnit přechodné stavy. Proto se ujistěte, že můžete korelovat a auditovat původní operaci i kompletní kompenzaci.

• Kompenzační transakce nemusí nutně vracet systémová data do stavu na začátku původní operace. Místo toho transakce kompenzuje práci, kterou operace úspěšně dokončila před selháním.

• Ne vždy kroky kompenzační transakce vrátí původní operaci v přesném opačném pořadí. Pokud je například jedno úložiště dat citlivější na nekonzistence než jiné, vraťte změny do úložiště jako první.

• Některá opatření vám můžou pomoct zlepšit úspěšnost. U každého prostředku, který je nutný k dokončení operace, můžete umístit krátkodobý zámek s časovým limitem. Tyto prostředky můžete získat předem a pak provádět práci až po získání všech prostředků. Dokončete všechny akce před vypršením platnosti zámků.

• Logika opakování, která zpracovává více chyb jako přechodných, může pomoct minimalizovat selhání, která aktivují kompenzační transakci. Pokud krok v operaci, která implementuje konečnou konzistenci, selže, zpracujte ho jako přechodnou výjimku a zkuste krok zopakovat. Operaci zastavte a aktivujte kompenzaci pouze v případě, že se krok opakovaně nezdaří nebo ho nemůžete obnovit. Další informace o strategiích opakování naleznete v části Ošetřování přechodných chyb.

• Při implementaci kompenzační transakce čelíte mnoha výzvám podobným implementaci konečné konzistence. Další informace naleznete v tématu Minimalizace koordinace.

• Definujte jasné body zvratu a nevratné kroky. Ve složitých pracovních postupech nemůžete bezpečně nebo smysluplně vrátit zpět některé operace, jako jsou vnější vedlejší účinky nebo právně závazné akce. Identifikace kompenzovatelných versus nevratných kroků Navrhujte pracovní postup tak, aby došlo k nevratným krokům až po úspěšném ověření všech kritických událostí.

Kdy použít tento vzor

Tento model použijte v těchto případech:

• Obchodní operace zahrnuje více kroků, služeb nebo úložišť dat a musí být vrácena zpět, pokud selže pozdější krok. K tomuto scénáři často dochází v dlouhotrvajících pracovních postupech, které se řídí modelem konečné konzistence a nemůžou spoléhat na atomické transakce.

• Obnova po selhání často vyžaduje logiku specifickou pro doménu, a ne jednoduché vrácení dat zpět. Při zrušení práce použijte kompenzační akce, které vyžadují dodržení obchodních pravidel, jako je zrušení rezervací nebo poskytování částečných refundací.

Tento vzor nemusí být vhodný v těchto případech:

• Operace se dají bezpečně opakovat a většina selhání je přechodná. Samotná logika opakování je v těchto případech často dostatečná a kompenzační transakce přidávají zbytečnou složitost.

• Systém nemůže tolerovat dočasnou nekonzistence nebo kompenzace nemůže spolehlivě obnovit platný stav. Místo toho používejte mechanismy silné konzistence nebo atomické transakce ve všech krocích.

Návrh úloh

Vyhodnoťte, jak použít kompenzační transakci v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected. Následující tabulka obsahuje pokyny, jak tento model podporuje cíle jednotlivých pilířů.

Pilíř	Jak tento model podporuje cíle pilíře
Spolehlivostní rozhodnutí o návrhu pomáhají vaší pracovní zátěži stát se odolná proti poruchám a zajistit, aby se po selhání obnovila do plně funkčního stavu.	Akce kompenzace řeší chyby v kritických cestách pracovních zatížení pomocí procesů, jako jsou přímé vrácení změn dat, rozbíjení zámků transakcí nebo dokonce spuštění chování nativního systému k obrácení účinku. - RE:02 Kritické toky - RE:09 Zotavení po havárii

Pokud tento model představuje kompromisy v rámci pilíře, zvažte je proti cílům ostatních pilířů.

Příklad

Následující diagram znázorňuje praktickou Azure implementaci modelu kompenzační transakce. Další implementace můžou také fungovat pro vaše požadavky na úlohy. Orchestrátor, který běží v Azure Container Apps koordinuje každý krok dlouhotrvajícího pracovního postupu odesláním příkazů prostřednictvím Azure Service Bus. Jakmile bude každý krok vpřed úspěšný, orchestrátor zaznamená stav provádění i odpovídající kompenzační akci v Azure Cosmos DB, aby bylo možné pracovní postup obnovit, korelovat a auditovat.

Diagram znázorňující pracovní postup v Azure Container Apps prostředí Klient odešle požadavek do orchestrátoru, který koordinuje služby A a B a zaznamenává operace. Zprávy kroku 1 a kroku 2 procházejí službou Service Bus. Pokud krok selže, kompenzační akce se spustí v obráceném pořadí. Neúspěšné zprávy se přesunou do fronty nedoručených zpráv. Prostředí se integruje s Microsoft Entra ID pro správu identity a s Application Insights a Azure Monitor pro sledovatelnost.

Tento model nejprve používá opakované pokusy k zachování pokroku. Pokud krok selže, orchestrátor použije logiku opakování pro přechodné chyby a pokusí se pokračovat v původní operaci. Kompenzace je vyvolána pouze tehdy, když nelze dosáhnout žádného dalšího pokroku, například když jsou vyčerpány všechny opakování nebo je selhání klasifikováno jako trvalé.

Obchodní pravidla můžou také upřednostňovat pokrok před okamžitou kompenzací. Pokud krok selže, orchestrátor může místo vrácení pracovního postupu vybrat alternativní cestu, například nahradit ekvivalentní službu nebo náhradní možnost. V případech s vysokým dopadem nebo nejednoznačných můžete pracovní postup pozastavit ke kontrole člověkem, než se rozhodnete, zda pokračovat alternativní cestou nebo spustit kompenzaci. Tento přístup považuje kompenzaci za poslední možnost a umožňuje pravidlům domény řídit rozhodnutí o obnovení.

V typické sekvenci orchestrátor odesílá podrobné zprávy prostřednictvím Service Bus (kroky 1 a 2), přijímá úspěšné výsledky a ukládá metadata předávání a kompenzace v Azure Cosmos DB.

Kompenzaci můžete aktivovat dvěma způsoby:

• Pokud pozdější krok ve stejné úloze selže a musíte vrátit zpět předchozí úspěšné kroky. K této kompenzaci může dojít okamžitě, když krok vrátí obchodní chybu, jako je chyba při ověřování pravidla, nebo po vyčerpání technických pokusů, a zpráva se přesune do fronty nedoručených zpráv.

• Když další klient explicitně požádá o zrušení dokončené operace.

V obou případech orchestrátor přečte uložené záznamy kompenzace a odešle příkazy kompenzace do odpovídající služby. Pokud krok náhrady selže přechodně, Service Bus může incident vyřešit opakováním bez nutnosti eskalace.

Pokud opakované opakování stále selže, Service Bus zprávu přesune do fronty nedoručených zpráv a zachová podrobnosti o selhání. Orchestrátor nebo specializovaný procesor chybových zpráv vyvolá upozornění a vysílá strukturovanou telemetrii, včetně důvodu selhání a ID korelace, do Azure Monitoru a Log Analytics, které se mohou zobrazit ve službě Application Insights. Tato provozní cesta pomáhá týmům diagnostikovat selhání, určit potřebu ručního zásahu a udržovat sledovatelnost napříč původními i kompenzačními toky.

Pracovní postup může automaticky zahájit kompenzaci pro jasné, nízkorizikové podmínky nebo pozastavit pro kontrolu člověkem, pokud je situace nejednoznačná, má vysoký dopad, nebo vyžaduje ruční rozhodnutí.

Používejte spravované identity a ověřování založené na Microsoft Entra ID mezi komponentami, abyste se vyhnuli sdíleným tajným kódům a vynucujte přístup s nejnižšími oprávněními. Při vytváření zjednodušeného referenčního diagramu by měly být tyto kontroly identit a autorizace považovány za základní záležitosti implementace, ne jako explicitní kroky toku. Udržujte diagram zaměřený na orchestraci, opakování, kompenzaci a řešení selhání.

Související prostředky

• Důležité informace o datech pro mikroslužby: Zjistěte, proč konečná konzistence a částečná selhání jsou součástí distribuovaných systémů. Model kompenzační transakce poskytuje konkrétní mechanismus pro zpracování těchto selhání v případě, že operace zahrnují více služeb.

• Transactional Outbox pattern with Azure Cosmos DB: Tento model použijte při kompenzačních transakcích, které potřebují spolehlivě publikovat události nebo příkazy. Pomáhá zajistit, aby změny stavu a zprávy byly zaznamenány atomicky, což brání ztrátě zpráv.

• Návrh pro samoopravení: V rámci samoopraveného přístupu pro vaše aplikace používejte kompenzační transakce.

• Model Scheduler Agent Supervisor: Tento model použijte pro vytvoření odolných systémů, které zajišťují obchodní operace napříč distribuovanými službami a zdroji. Tyto systémy někdy potřebují kompenzační transakce k vrácení práce zpět.

• Model opakování: Tento model použijte ke zpracování přechodných selhání a minimalizaci nutnosti kompenzačních transakcí.

• Model distribuovaných transakcí Saga: Tento model použijte ke správě konzistence dat napříč mikroslužbami v distribuovaných transakcích. Saga používá kompenzační transakce pro zotavení po selhání.

• Vzor Kanály a filtry: Tento vzor použijte s vzorem Kompenzační transakce jako alternativu k distribuovaným transakcím při dekomponování složitých úloh na opakovaně použitelné kroky.