Model plánovač-agent-správce

Azure

Koordinuje sadu distribuovaných akcí jako jednu operaci. Pokud některá z akcí selže, pokuste se chyby řešit transparentně, nebo vraťte provedené změny, aby celá operace byla buď úspěšná, nebo neúspěšná. Tím se může zvýšit odolnost distribuovaného systému. Ten totiž bude moct provádět obnovení a opakovat akce, které selhaly kvůli přechodným výjimkám, dlouhodobým chybám i selháním procesu.

Kontext a problém

Aplikace provádí úlohy, které zahrnují několik kroků, z nichž některé můžou vyvolat vzdálené služby nebo přistupovat ke vzdáleným prostředkům. Jednotlivé kroky můžou být navzájem nezávislé, ale orchestruje je logika aplikace, která úlohu implementuje.

Kdykoli je to možné, aplikace by měla kontrolovat dokončení úloh a řešit všechny chyby, ke kterým může dojít během přístupu ke vzdáleným službám nebo prostředkům. K selhání může dojít z nejrůznějších důvodů. Například může dojít k výpadku sítě nebo přerušení komunikace, vzdálená služba může přestat odpovídat nebo může být v nestabilním stavu, anebo může být dočasně nedostupný vzdálený prostředek – pravděpodobně kvůli omezením prostředku. V mnoha případech bude selhání přechodné a půjde vyřešit pomocí modelu Opakování.

Pokud aplikace zjistí trvalejší chybu, u které je obnovení funkčnosti náročnější, musí být schopná obnovit systém v konzistentním stavu a zajistit integritu celé operace.

Řešení

Model plánovač-agent-správce definuje následující aktéry: Tyto aktéři řídí kroky, které se mají provést, jako dílčí části jedné úlohy.

• Plánovač zajišťuje uspořádání kroků, které tvoří úlohu, aby byly vykonány, a koordinuje jejich provoz. Tyto kroky je možné zkombinovat do pipeline nebo pracovního postupu. Plánovač zodpovídá za zajištění toho, aby se kroky v tomto pracovním postupu prováděly ve správném pořadí. Jakmile je každý krok proveden, plánovač zaznamená stav pracovního postupu, například krok, který ještě není zahájen, krok probíhající nebo dokončený. Informace o stavu by také měly obsahovat horní limit času, který je pro dokončení kroku, označováno jako čas dokončení. Pokud krok vyžaduje přístup ke vzdálené službě nebo prostředku, vyvolá plánovač odpovídajícího agenta a předá mu podrobnosti o činnosti, která má být provedena. Plánovač obvykle komunikuje s agentem pomocí asynchronního zasílání zpráv požadavků a odpovědí. Tento krok je možné implementovat pomocí front nebo jiných technologií pro distribuované zasílání zpráv.

  Plánovač má podobnou funkci jako správce procesu v modelu správce procesu. Samotný pracovní postup je obvykle definován a implementován modulem pracovních postupů řízeným plánovačem. Tento přístup odděluje obchodní logiku v pracovním postupu od plánovače.

• Agent obsahuje logiku, která zapouzdřuje volání vzdálené služby nebo přístup ke vzdálenému prostředku, k němuž odkazuje krok v úloze. Každý agent obvykle zabalí volání jedné služby nebo prostředku a implementuje odpovídající zpracování chyb a logiku opakování. Omezení časového limitu popsané dále v tomto článku se týká zpracování chyb a logiky opakování. Když implementujete logiku opakování, předejte stabilní identifikátor napříč všemi pokusy o opakování, aby ji vzdálená služba mohla použít pro jakoukoli logiku odstranění duplicitních dat, kterou by mohla mít.

  Pokud kroky v pracovním postupu, který plánovač spouští, používají v různých krocích několik služeb a prostředků, může každý krok odkazovat na jiného agenta. Tento bod je podrobností implementace modelu. Pokyny k návrhu strategií opakování najdete v tématu Zpracování přechodných chyb.

• Správce monitoruje stav kroků v úloze prováděné plánovačem. Spouští se pravidelně (frekvence bude specifická pro systém) a zkoumá stav kroků udržovaných plánovačem. Pokud zjistí, že některý krok selhal nebo vypršel jeho časový limit, zajistí, aby příslušný agent tento krok obnovil nebo provedl vhodnou nápravnou akci (to může zahrnovat změnu stavu kroku). Plánovač a agenti implementují obnovovací nebo nápravné kroky. Správce požaduje, aby tyto akce provedli oni.

Plánovač, agent a správce jsou logické komponenty a jejich fyzická implementace závisí na použité technologii. Například můžete implementovat několik logických agentů do jedné webové služby.

Plánovač uchovává informace o průběhu úlohy a stavu jednotlivých kroků v trvalém úložišti dat označovaném jako úložiště stavů. Správce může na základě těchto informací snadněji určit, zda nedošlo k selhání kroku. Na obrázku je znázorněný vztah mezi plánovačem, agenty, správcem a úložištěm stavů.

Poznámka:

Tento diagram znázorňuje zjednodušenou verzi modelu. Ve skutečné implementaci může být velký počet současně spuštěných instancí plánovače, kdy každá z nich je podmnožinou úloh. Podobně může systém spouštět více instancí jednotlivých agentů nebo dokonce více správců. V takovém případě musí vedoucí koordinovat svou práci s ostatními pečlivě, aby se ujistili, že nebudou soutěžit o obnovení stejných neúspěšných kroků a úkolů. Vzor volby vedoucího poskytuje možné řešení tohoto problému.

Když je aplikace připravená spustit úlohu, odešle žádost plánovači. Plánovač zapíše počáteční informace o stavu úlohy a jejích kroků (například to, že krok ještě nebyl spuštěn) do úložiště stavů a potom začne provádět operace definované pracovním postupem. Pokaždé, když plánovač spustí nějaký krok, aktualizuje informace o jeho stavu v úložišti stavů (například zaznamená, že krok probíhá).

Pokud krok odkazuje na vzdálenou službu nebo prostředek, odešle plánovač zprávu příslušnému agentovi. Kromě časového limitu na dokončení operace obsahuje zpráva informace, které má agent předat službě, nebo informace potřebné pro přístup k prostředku. Pokud agent operaci dokončí úspěšně, odešle plánovači odpověď. Plánovač pak může aktualizovat informace o stavu v úložišti stavů (například zapsat, že krok je dokončený), a provést další krok. Tento proces pokračuje, dokud není dokončená celá úloha.

Pokud je potřeba, může agent implementovat jakoukoli logiku opakování pokusů. Pokud ale Agent nedokončí svoji práci před vypršením časového limitu, plánovač předpokládá, že operace selhala. V takovém případě by měl agent zastavit svoji činnost, neměl by plánovači odesílat žádný výstup (ani chybovou zprávu) a ani by se neměl pokoušet o jakoukoli formu obnovení. Důvodem tohoto omezení je, že po vypršení platnosti nebo selhání daného kroku může být naplánována další instance agenta, která se má pokusit tento krok provést (tento proces je popsaný níže).

Pokud agent selže, neobdrží plánovač žádnou odpověď. Model nerozlišuje mezi krokem, u kterého vypršel časový limit, a krokem, který skutečně selhal.

Jak v případě vypršení časového limitu, tak v případě selhání kroku bude v úložišti stavů záznam o tom, že krok stále probíhá, i když už uplynul čas na jeho dokončení. Správce hledá takovéto kroky a pokouší se je obnovit. Jednou z možných strategií je, že správce aktualizuje hodnotu času pro dokončení, aby prodloužil dostupný čas k dokončení kroku, a pak plánovači odešle zprávu s identifikací kroku, který vypršel. Plánovač se pak může pokusit tento krok zopakovat. Tento návrh ale vyžaduje, aby úkoly byly idempotentní. Systém by měl obsahovat infrastrukturu pro zachování konzistence. Další informace najdete v tématu Opakovatelné infrastruktury, Navrhování aplikací Azure pro odolnost a dostupnost a Průvodce rozhodováním o konzistenci zdrojů.

Správce může potřebovat zabránit opakovanému opakování stejného kroku, pokud se trvale nezdaří nebo vyprší časový limit. Za tímto účelem může správce udržovat počet opakování pro každý krok spolu s informacemi o stavu v úložišti stavů. Když tento počet překročí nastavený limit, může se správce rozhodnout počkat určitou dobu, než oznámí plánovači, že je potřeba krok zopakovat (protože předpokládá, že by během této doby mohlo dojít k vyřešení problému). Případně může správce plánovači odeslat zprávu s žádostí, aby celou úlohu zrušil implementováním modelu kompenzační transakce. Tento postup bude záviset na plánovači a agentech poskytujících informace potřebné k implementaci kompenzačních operací pro všechny kroky, které se dokončily úspěšně.

Úlohou správce není monitorovat plánovače a agenty a při jejich selhání je restartovat. Tyto akce by měla v systému zajišťovat infrastruktura, ve které tyto komponenty běží. Stejně tak by správce neměl mít informace o samotných obchodních operacích, které úlohy spouštěné plánovačem provádějí (včetně postupů kompenzace v případě jejich selhání). O tyto aspekty se stará logika pracovního postupu implementovaná plánovačem. Jediným účelem správce je sledovat úspěšné provádění kroků a v případě selhání buď zajistit jejich zopakování, nebo zrušit celou úlohu, která chybný krok obsahuje.

Pokud se plánovač z důvodu chyby restartuje, nebo neočekávaně skončí pracovní postup, který plánovač prováděl, měl by být plánovač schopný určit stav jakéhokoli příchozího úkolu, který zpracovával v okamžiku, kdy došlo k selhání, a pokračovat v jeho provádění od tohoto bodu. Podrobnosti implementace tohoto procesu budou pravděpodobně specifické pro systém. Pokud úlohu nelze obnovit, může být potřeba vrátit zpět akce, které už v rámci této úlohy proběhly. To může také vyžadovat implementaci kompenzační transakce.

Hlavní výhodou tohoto modelu je, že systém je odolný proti neočekávaným selháním, ať už dočasným, nebo neopravitelným. Systém lze vytvořit tak, aby byl samoopravený. Pokud například selže agent nebo plánovač, může být spuštěn nový a správce může zajistit obnovení úlohy. Pokud selže správce, může být spuštěna nová instance, která bude pokračovat od místa, kde došlo k chybě. Pokud je naplánované pravidelné spouštění správce, může se nová instance spustit automaticky po nastaveném intervalu. Pro dosažení ještě větší úrovně odolnosti lze replikovat ukládací systém stavů.

Problémy a důležité informace

Když se budete rozhodovat, jak tento model implementovat, měli byste vzít v úvahu následující skutečnosti:

• Tento model může být obtížné implementovat a vyžaduje důkladné testování všech možných režimů selhání systému.

• Logika obnovení a opakování pokusů implementovaná plánovačem je velmi komplexní a závisí na informacích o stavu uložených v úložišti stavů. Může být také nezbytné zaznamenávat informace potřebné k implementaci kompenzační transakce v trvalém úložišti dat. Kompenzační transakce může také selhat.

• Důležitým faktorem je frekvence spouštění správce. Měl by být spouštěn dostatečně často, aby zabránil zablokování aplikace díky jakýmkoli selhaným krokům po delší dobu, ale ne tak často, aby se stal přenesenou režii.

• Kroky prováděné agenty je možné spouštět vícekrát než jednou. Logika implementující tyto kroky by měla být idempotentní.

Kdy se má tento model použít

Tento model použijte, když proces, který běží v distribuovaném prostředí, jako je cloud, musí zůstat odolný vůči selhání komunikace i provozním selháním. Tento model je běžný v úlohách na pozadí , které orchestrují vícekrokové pracovní postupy, jako je zpracování objednávek nebo zřizování prostředků.

Tento model nemusí být vhodný pro úlohy, které nevolají vzdálené služby ani nepřistupují ke vzdáleným prostředkům.

Návrh úloh

Architekt by měl vyhodnotit, jak lze vzor Plánovač Supervisor agenta aplikovat v návrhu jejich úlohy, aby se vyřešily cíle a principy, které jsou součástí pilířů Azure Well-Architected Framework. Příklad:

Pilíř	Jak tento model podporuje cíle pilíře
Rozhodnutí o návrhu spolehlivosti pomáhají vaší úloze stát se odolnou proti selhání a zajistit, aby se po selhání obnovila do plně funkčního stavu.	Tento model používá metriky stavu ke zjišťování selhání a přesměrování úloh na agenta, který je v pořádku, aby se snížily účinky selhání. - RE:05 Redundance - RE:07 Samoopravení
Efektivita výkonu pomáhá vaší úloze efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu.	Tento model používá metriky výkonu a kapacity ke zjištění aktuálního využití a směrování úloh do agenta, který má kapacitu. Můžete ji také použít k určení priority provádění práce s vyšší prioritou oproti práci s nižší prioritou. - PE:05 Škálování a dělení - PE:09 Kritické toky

Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.

Příklad

Webová aplikace, která implementuje systém elektronického obchodování, byla nasazena na Microsoft Azure. Uživatelé, kteří tuto aplikaci spouštějí, si můžou prohlížet dostupné produkty a zadávat objednávky. Uživatelské rozhraní běží jako webový front-end a prvky zpracování objednávek aplikace se implementují jako sada pracovních procesů na pozadí. Součástí logiky zpracování objednávek je přístup k vzdálené službě a tento aspekt systému může být příčinou přechodných i dlouhodobých chyb. Proto návrháři použili model plánovač-agent-správce, pomocí kterého do systému implementovali prvky zpracování objednávek.

Když zákazník zadá objednávku, aplikace vytvoří zprávu, která tuto objednávku popisuje, a odešle ji do fronty. Samostatný proces podání, který běží jako podprogram na pozadí, načte zprávu, vloží podrobnosti objednávky do databáze objednávek a vytvoří záznam pro proces objednávky ve stavovém úložišti. Vložení do databáze objednávek a úložiště stavů se provádí jako součást stejné operace. Proces odeslání je navržený tak, aby se oba kroky vložení dokončily současně.

Informace o stavu, které proces odeslání pro objednávku vytvoří, zahrnují tato pole:

• OrderID (ID objednávky). ID objednávky v databázi objednávek.

• LockedBy. ID instance pracovníka, který zpracovává objednávku. Může existovat několik aktuálních instancí pracovního procesu, na kterých běží Plánovač, ale každá objednávka by měla být zpracována pouze jednou instancí.

• CompleteBy Čas, do kdy má být objednávka zpracována.

• ProcessState (Stav procesu) Aktuální stav úlohy, která objednávku zpracovává. Možné stavy:

  • Pending (Čeká na vyřízení). Objednávka byla vytvořena, ale ještě se nezačala zpracovávat.
  • Zpracování Objednávka se právě zpracovává.
  • Zpracováno Objednávka byla úspěšně zpracovaná.
  • Chyba. Zpracování objednávky se nezdařilo.

• FailureCount (Počet chyb). Počet pokusů o zpracování objednávky.

Pole OrderID se v informacích o stavu zkopíruje z pole OrderID nové objednávky. Pole LockedBy a CompleteBy se nastaví na hodnotu null, pole ProcessState na hodnotu Pending a pole FailureCount na hodnotu 0.

Poznámka:

Logika zpracování objednávky v tomto příkladu je poměrně jednoduchá – obsahuje pouze jeden krok, který volá vzdálenou službu. V složitějším vícekrokovém scénáři by proces odeslání pravděpodobně zahrnoval několik kroků, takže v úložišti stavů by se vytvořilo několik záznamů – každý z nich popisuje stav jednotlivého kroku.

Plánovač také běží jako pracovní proces na pozadí a implementuje obchodní logiku, která zpracovává pořadí. Instance dotazování plánovače na nové objednávky hledá v úložišti stavů záznamy, ve kterých má pole LockedBy hodnotu null a pole ProcessState je čekající. Když plánovač zjistí novou objednávku, okamžitě vloží do pole LockedBy ID své vlastní instance, do pole CompleteBy zadá příslušný čas a pole ProcessState změní na stav Processing. Kód je navržený jako výhradní a atomický, aby se předešlo tomu, že se dvě současně spuštěné instance plánovače pokusí zpracovat stejnou objednávku.

Plánovač pak spustí obchodní pracovní postup pro asynchronní zpracování objednávky, předává mu hodnotu pole OrderID z úložiště stavů. Pracovní postup, který objednávku zpracovává, načte podrobnosti objednávky z databáze objednávek a provede požadované operace. Když některý krok pracovního postupu zpracování objednávky potřebuje vyvolat vzdálenou službu, použije agenta. Krok pracovního postupu komunikuje s agentem pomocí dvojice Azure Service Bus front zpráv, které fungují jako kanál pro žádosti a odpovědi. Obrázek znázorňuje základní zobrazení řešení.

Zpráva odeslaná agentovi z kroku pracovního postupu popisuje objednávku a obsahuje časový limit na dokončení. Pokud agent obdrží odpověď ze vzdálené služby před uplynutím doby určené pro dokončení, zveřejní odpověď ve frontě Service Bus, kde pracovní postup naslouchá. Když krok pracovního postupu obdrží platnou zprávu odpovědi, dokončí své zpracování a plánovač nastaví pole ProcessState stavu objednávky na zpracováno. V tomto okamžiku je zpracování objednávky úspěšně dokončeno.

Pokud vyprší doba dokončení, než agent obdrží odpověď ze vzdálené služby, agent zastaví zpracování a ukončí zpracování objednávky. Stejně tak se pracovní postup zpracovávající objednávku ukončí, pokud překročí časový limit. V obou případech zůstane stav objednávky v úložišti stavů nastavený na zpracovávání, ale čas pro dokončení bude označovat, že čas na zpracování objednávky vypršel, a proces se bude považovat za neúspěšný. Pokud agent přistupující k vzdálené službě nebo pracovní postup, který zpracovává objednávku, neočekávaně ukončen, informace v úložišti stavů zůstanou nastavené na zpracování a nakonec mají prošlou hodnotu dokončení.

Pokud agent během pokusu o kontaktování vzdálené služby zjistí neopravitelnou chybu, která není přechodná, může o této chybě informovat workflow. Plánovač může u objednávky nastavit chybový stav a vyvolat událost, která odešle výstrahu operátorovi. Operátor pak může zkusit příčinu selhání vyřešit ručně a obnovit zpracování příslušného neúspěšného kroku.

Správce pravidelně kontroluje úložiště stavů a hledá objednávky, u kterých vypršel časový limit. Pokud správce nějaký takový záznam najde, inkrementuje pole FailureCount. Pokud je hodnota počtu selhání nižší než zadaná prahová hodnota, pak správce resetuje pole LockedBy na hodnotu null, aktualizuje pole CompleteBy na nový čas vypršení platnosti a v poli ProcessState nastaví hodnotu Pending. Instance plánovače může tuto objednávku převzít a zopakovat pokus o její zpracování. Jakmile hodnota počtu selhání překročí zadanou prahovou hodnotu, předpokládá se, že příčina selhání je trvalá. Správce nastaví u objednávky chybový stav a vyvolá událost, která odešle výstrahu operátorovi.

V tomto příkladu se správce implementuje jako samostatný proces běžící na pozadí. Pomocí různých strategií můžete zajistit spuštění úlohy správce, například použití funkcí aktivovaných časovačem v Azure Functions nebo naplánované úlohy v Azure Container Apps.

I když to tento příklad neukazuje, plánovač může chtít, aby byla aplikace, která objednávku odeslala, informována o průběhu a stavu této objednávky. Aplikace a plánovač jsou navzájem oddělené, aby se předešlo vzniku případných závislostí mezi nimi. Aplikace nemá žádné informace o tom, která instance plánovače objednávku zpracovává, a plánovač nemá žádné informace o tom, která instance aplikace objednávku odeslala.

K povolení reportování stavu objednávky může aplikace použít svoji vlastní privátní frontu odpovědí. Podrobnosti o této frontě odpovědí by byly zahrnuty jako součást žádosti zaslané procesu odeslání, který by tyto informace uložil ve státním úložišti. Plánovač pak do této fronty zveřejní zprávy označující stav objednávky (například přijetí požadavku, dokončení objednávky a selhání objednávky). V těchto zprávách je potřeba uvádět ID objednávek, aby mohly být přiřazeny k původním žádostem z aplikace.

Další kroky

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

• Úvod k asynchronnímu zasílání zpráv: Komponenty modelu plánovač-agent-správce obvykle běží navzájem odděleně a komunikují asynchronně. Popisuje některé z přístupů, které lze použít k implementaci asynchronní komunikaci na základě front zpráv.

• Reference 6: Sága o ságách. Příklad znázorňující, jak vzor CQRS využívá správce procesů (součást průvodce CQRS Journey).

• Plánovač Microsoft Azure

Související prostředky

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

• Model opakování. Agent může tento vzorec použít k transparentnímu opakování operací, které přistupují k vzdálené službě nebo prostředku a dříve selhaly. Používejte ho, pokud očekáváte, že příčina selhání je přechodná a chyba bude opravena.

• Vzor Circuit Breaker. Agent může pomocí tohoto modelu zpracovávat chyby připojení ke vzdálené službě nebo prostředku, jejichž oprava trvá různě dlouho.

• Model kompenzační transakce: Pokud pracovní postup prováděný plánovačem nemůže být dokončen úspěšně, může být potřeba vrátit zpět veškeré dříve provedené akce. Vzorec kompenzační transakce popisuje, jak to lze dosáhnout u operací, které se řídí modelem eventualní konzistence. Tyto typy operací implementuje běžně plánovač, který provádí komplexní obchodní procesy a pracovní postupy.

• Model volby vedoucího procesu. Může být potřeba koordinovat akce více instancí správce, a předejít tak tomu, aby se více instancí pokoušelo obnovit stejný neúspěšný proces. Jak to udělat, popisuje model volby vedoucího procesu.

• Architektura cloudu: Vzorec Scheduler-Agent-Supervisor na blogu Clemense Vasterse

• Model správce procesu

Koordinuje sadu distribuovaných akcí jako jednu operaci. Pokud některá z akcí selže, pokuste se chyby řešit transparentně, nebo vraťte provedené změny, aby celá operace byla buď úspěšná, nebo neúspěšná. Tím se může zvýšit odolnost distribuovaného systému. Ten totiž bude moct provádět obnovení a opakovat akce, které selhaly kvůli přechodným výjimkám, dlouhodobým chybám i selháním procesu.

Kontext a problém

Aplikace provádí úlohy, které zahrnují několik kroků, z nichž některé můžou vyvolat vzdálené služby nebo přistupovat ke vzdáleným prostředkům. Jednotlivé kroky můžou být navzájem nezávislé, ale orchestruje je logika aplikace, která úlohu implementuje.

Kdykoli je to možné, aplikace by měla kontrolovat dokončení úloh a řešit všechny chyby, ke kterým může dojít během přístupu ke vzdáleným službám nebo prostředkům. K selhání může dojít z nejrůznějších důvodů. Například může dojít k výpadku sítě nebo přerušení komunikace, vzdálená služba může přestat odpovídat nebo může být v nestabilním stavu, anebo může být dočasně nedostupný vzdálený prostředek – pravděpodobně kvůli omezením prostředku. V mnoha případech bude selhání přechodné a půjde vyřešit pomocí modelu Opakování.

Pokud aplikace zjistí trvalejší chybu, u které je obnovení funkčnosti náročnější, musí být schopná obnovit systém v konzistentním stavu a zajistit integritu celé operace.

Řešení

Model plánovač-agent-správce definuje následující aktéry: Tyto aktéři řídí kroky, které se mají provést, jako dílčí části jedné úlohy.

• Plánovač zajišťuje uspořádání kroků, které tvoří úlohu, aby byly vykonány, a koordinuje jejich provoz. Tyto kroky je možné zkombinovat do pipeline nebo pracovního postupu. Plánovač zodpovídá za zajištění toho, aby se kroky v tomto pracovním postupu prováděly ve správném pořadí. Jakmile je každý krok proveden, plánovač zaznamená stav pracovního postupu, například krok, který ještě není zahájen, krok probíhající nebo dokončený. Informace o stavu by také měly obsahovat horní limit času, který je pro dokončení kroku, označováno jako čas dokončení. Pokud krok vyžaduje přístup ke vzdálené službě nebo prostředku, vyvolá plánovač odpovídajícího agenta a předá mu podrobnosti o činnosti, která má být provedena. Plánovač obvykle komunikuje s agentem pomocí asynchronního zasílání zpráv požadavků a odpovědí. Tento krok je možné implementovat pomocí front nebo jiných technologií pro distribuované zasílání zpráv.

  Plánovač má podobnou funkci jako správce procesu v modelu správce procesu. Samotný pracovní postup je obvykle definován a implementován modulem pracovních postupů řízeným plánovačem. Tento přístup odděluje obchodní logiku v pracovním postupu od plánovače.

• Agent obsahuje logiku, která zapouzdřuje volání vzdálené služby nebo přístup ke vzdálenému prostředku, k němuž odkazuje krok v úloze. Každý agent obvykle zabalí volání jedné služby nebo prostředku a implementuje odpovídající zpracování chyb a logiku opakování. Omezení časového limitu popsané dále v tomto článku se týká zpracování chyb a logiky opakování. Když implementujete logiku opakování, předejte stabilní identifikátor napříč všemi pokusy o opakování, aby ji vzdálená služba mohla použít pro jakoukoli logiku odstranění duplicitních dat, kterou by mohla mít.

  Pokud kroky v pracovním postupu, který plánovač spouští, používají v různých krocích několik služeb a prostředků, může každý krok odkazovat na jiného agenta. Tento bod je podrobností implementace modelu. Pokyny k návrhu strategií opakování najdete v tématu Zpracování přechodných chyb.

• Správce monitoruje stav kroků v úloze prováděné plánovačem. Spouští se pravidelně (frekvence bude specifická pro systém) a zkoumá stav kroků udržovaných plánovačem. Pokud zjistí, že některý krok selhal nebo vypršel jeho časový limit, zajistí, aby příslušný agent tento krok obnovil nebo provedl vhodnou nápravnou akci (to může zahrnovat změnu stavu kroku). Plánovač a agenti implementují obnovovací nebo nápravné kroky. Správce požaduje, aby tyto akce provedli oni.

Plánovač, agent a správce jsou logické komponenty a jejich fyzická implementace závisí na použité technologii. Například můžete implementovat několik logických agentů do jedné webové služby.

Plánovač uchovává informace o průběhu úlohy a stavu jednotlivých kroků v trvalém úložišti dat označovaném jako úložiště stavů. Správce může na základě těchto informací snadněji určit, zda nedošlo k selhání kroku. Na obrázku je znázorněný vztah mezi plánovačem, agenty, správcem a úložištěm stavů.

Poznámka:

Tento diagram znázorňuje zjednodušenou verzi modelu. Ve skutečné implementaci může být velký počet současně spuštěných instancí plánovače, kdy každá z nich je podmnožinou úloh. Podobně může systém spouštět více instancí jednotlivých agentů nebo dokonce více správců. V takovém případě musí vedoucí koordinovat svou práci s ostatními pečlivě, aby se ujistili, že nebudou soutěžit o obnovení stejných neúspěšných kroků a úkolů. Vzor volby vedoucího poskytuje možné řešení tohoto problému.

Když je aplikace připravená spustit úlohu, odešle žádost plánovači. Plánovač zapíše počáteční informace o stavu úlohy a jejích kroků (například to, že krok ještě nebyl spuštěn) do úložiště stavů a potom začne provádět operace definované pracovním postupem. Pokaždé, když plánovač spustí nějaký krok, aktualizuje informace o jeho stavu v úložišti stavů (například zaznamená, že krok probíhá).

Pokud krok odkazuje na vzdálenou službu nebo prostředek, odešle plánovač zprávu příslušnému agentovi. Kromě časového limitu na dokončení operace obsahuje zpráva informace, které má agent předat službě, nebo informace potřebné pro přístup k prostředku. Pokud agent operaci dokončí úspěšně, odešle plánovači odpověď. Plánovač pak může aktualizovat informace o stavu v úložišti stavů (například zapsat, že krok je dokončený), a provést další krok. Tento proces pokračuje, dokud není dokončená celá úloha.

Pokud je potřeba, může agent implementovat jakoukoli logiku opakování pokusů. Pokud ale Agent nedokončí svoji práci před vypršením časového limitu, plánovač předpokládá, že operace selhala. V takovém případě by měl agent zastavit svoji činnost, neměl by plánovači odesílat žádný výstup (ani chybovou zprávu) a ani by se neměl pokoušet o jakoukoli formu obnovení. Důvodem tohoto omezení je, že po vypršení platnosti nebo selhání daného kroku může být naplánována další instance agenta, která se má pokusit tento krok provést (tento proces je popsaný níže).

Pokud agent selže, neobdrží plánovač žádnou odpověď. Model nerozlišuje mezi krokem, u kterého vypršel časový limit, a krokem, který skutečně selhal.

Jak v případě vypršení časového limitu, tak v případě selhání kroku bude v úložišti stavů záznam o tom, že krok stále probíhá, i když už uplynul čas na jeho dokončení. Správce hledá takovéto kroky a pokouší se je obnovit. Jednou z možných strategií je, že správce aktualizuje hodnotu času pro dokončení, aby prodloužil dostupný čas k dokončení kroku, a pak plánovači odešle zprávu s identifikací kroku, který vypršel. Plánovač se pak může pokusit tento krok zopakovat. Tento návrh ale vyžaduje, aby úkoly byly idempotentní. Systém by měl obsahovat infrastrukturu pro zachování konzistence. Další informace najdete v tématu Opakovatelné infrastruktury, Navrhování aplikací Azure pro odolnost a dostupnost a Průvodce rozhodováním o konzistenci zdrojů.

Správce může potřebovat zabránit opakovanému opakování stejného kroku, pokud se trvale nezdaří nebo vyprší časový limit. Za tímto účelem může správce udržovat počet opakování pro každý krok spolu s informacemi o stavu v úložišti stavů. Když tento počet překročí nastavený limit, může se správce rozhodnout počkat určitou dobu, než oznámí plánovači, že je potřeba krok zopakovat (protože předpokládá, že by během této doby mohlo dojít k vyřešení problému). Případně může správce plánovači odeslat zprávu s žádostí, aby celou úlohu zrušil implementováním modelu kompenzační transakce. Tento postup bude záviset na plánovači a agentech poskytujících informace potřebné k implementaci kompenzačních operací pro všechny kroky, které se dokončily úspěšně.

Úlohou správce není monitorovat plánovače a agenty a při jejich selhání je restartovat. Tyto akce by měla v systému zajišťovat infrastruktura, ve které tyto komponenty běží. Stejně tak by správce neměl mít informace o samotných obchodních operacích, které úlohy spouštěné plánovačem provádějí (včetně postupů kompenzace v případě jejich selhání). O tyto aspekty se stará logika pracovního postupu implementovaná plánovačem. Jediným účelem správce je sledovat úspěšné provádění kroků a v případě selhání buď zajistit jejich zopakování, nebo zrušit celou úlohu, která chybný krok obsahuje.

Pokud se plánovač z důvodu chyby restartuje, nebo neočekávaně skončí pracovní postup, který plánovač prováděl, měl by být plánovač schopný určit stav jakéhokoli příchozího úkolu, který zpracovával v okamžiku, kdy došlo k selhání, a pokračovat v jeho provádění od tohoto bodu. Podrobnosti implementace tohoto procesu budou pravděpodobně specifické pro systém. Pokud úlohu nelze obnovit, může být potřeba vrátit zpět akce, které už v rámci této úlohy proběhly. To může také vyžadovat implementaci kompenzační transakce.

Hlavní výhodou tohoto modelu je, že systém je odolný proti neočekávaným selháním, ať už dočasným, nebo neopravitelným. Systém lze vytvořit tak, aby byl samoopravený. Pokud například selže agent nebo plánovač, může být spuštěn nový a správce může zajistit obnovení úlohy. Pokud selže správce, může být spuštěna nová instance, která bude pokračovat od místa, kde došlo k chybě. Pokud je naplánované pravidelné spouštění správce, může se nová instance spustit automaticky po nastaveném intervalu. Pro dosažení ještě větší úrovně odolnosti lze replikovat ukládací systém stavů.

Problémy a důležité informace

Když se budete rozhodovat, jak tento model implementovat, měli byste vzít v úvahu následující skutečnosti:

• Tento model může být obtížné implementovat a vyžaduje důkladné testování všech možných režimů selhání systému.

• Logika obnovení a opakování pokusů implementovaná plánovačem je velmi komplexní a závisí na informacích o stavu uložených v úložišti stavů. Může být také nezbytné zaznamenávat informace potřebné k implementaci kompenzační transakce v trvalém úložišti dat. Kompenzační transakce může také selhat.

• Důležitým faktorem je frekvence spouštění správce. Měl by být spouštěn dostatečně často, aby zabránil zablokování aplikace díky jakýmkoli selhaným krokům po delší dobu, ale ne tak často, aby se stal přenesenou režii.

• Kroky prováděné agenty je možné spouštět vícekrát než jednou. Logika implementující tyto kroky by měla být idempotentní.

Kdy se má tento model použít

Tento model použijte, když proces, který běží v distribuovaném prostředí, jako je cloud, musí zůstat odolný vůči selhání komunikace i provozním selháním. Tento model je běžný v úlohách na pozadí , které orchestrují vícekrokové pracovní postupy, jako je zpracování objednávek nebo zřizování prostředků.

Tento model nemusí být vhodný pro úlohy, které nevolají vzdálené služby ani nepřistupují ke vzdáleným prostředkům.

Návrh úloh

Architekt by měl vyhodnotit, jak lze vzor Plánovač Supervisor agenta aplikovat v návrhu jejich úlohy, aby se vyřešily cíle a principy, které jsou součástí pilířů Azure Well-Architected Framework. Příklad:

Pilíř	Jak tento model podporuje cíle pilíře
Rozhodnutí o návrhu spolehlivosti pomáhají vaší úloze stát se odolnou proti selhání a zajistit, aby se po selhání obnovila do plně funkčního stavu.	Tento model používá metriky stavu ke zjišťování selhání a přesměrování úloh na agenta, který je v pořádku, aby se snížily účinky selhání. - RE:05 Redundance - RE:07 Samoopravení
Efektivita výkonu pomáhá vaší úloze efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu.	Tento model používá metriky výkonu a kapacity ke zjištění aktuálního využití a směrování úloh do agenta, který má kapacitu. Můžete ji také použít k určení priority provádění práce s vyšší prioritou oproti práci s nižší prioritou. - PE:05 Škálování a dělení - PE:09 Kritické toky

Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.

Příklad

Webová aplikace, která implementuje systém elektronického obchodování, byla nasazena na Microsoft Azure. Uživatelé, kteří tuto aplikaci spouštějí, si můžou prohlížet dostupné produkty a zadávat objednávky. Uživatelské rozhraní běží jako webový front-end a prvky zpracování objednávek aplikace se implementují jako sada pracovních procesů na pozadí. Součástí logiky zpracování objednávek je přístup k vzdálené službě a tento aspekt systému může být příčinou přechodných i dlouhodobých chyb. Proto návrháři použili model plánovač-agent-správce, pomocí kterého do systému implementovali prvky zpracování objednávek.

Když zákazník zadá objednávku, aplikace vytvoří zprávu, která tuto objednávku popisuje, a odešle ji do fronty. Samostatný proces podání, který běží jako podprogram na pozadí, načte zprávu, vloží podrobnosti objednávky do databáze objednávek a vytvoří záznam pro proces objednávky ve stavovém úložišti. Vložení do databáze objednávek a úložiště stavů se provádí jako součást stejné operace. Proces odeslání je navržený tak, aby se oba kroky vložení dokončily současně.

Informace o stavu, které proces odeslání pro objednávku vytvoří, zahrnují tato pole:

• OrderID (ID objednávky). ID objednávky v databázi objednávek.

• LockedBy. ID instance pracovníka, který zpracovává objednávku. Může existovat několik aktuálních instancí pracovního procesu, na kterých běží Plánovač, ale každá objednávka by měla být zpracována pouze jednou instancí.

• CompleteBy Čas, do kdy má být objednávka zpracována.

• ProcessState (Stav procesu) Aktuální stav úlohy, která objednávku zpracovává. Možné stavy:

  • Pending (Čeká na vyřízení). Objednávka byla vytvořena, ale ještě se nezačala zpracovávat.
  • Zpracování Objednávka se právě zpracovává.
  • Zpracováno Objednávka byla úspěšně zpracovaná.
  • Chyba. Zpracování objednávky se nezdařilo.

• FailureCount (Počet chyb). Počet pokusů o zpracování objednávky.

Pole OrderID se v informacích o stavu zkopíruje z pole OrderID nové objednávky. Pole LockedBy a CompleteBy se nastaví na hodnotu null, pole ProcessState na hodnotu Pending a pole FailureCount na hodnotu 0.

Poznámka:

Logika zpracování objednávky v tomto příkladu je poměrně jednoduchá – obsahuje pouze jeden krok, který volá vzdálenou službu. V složitějším vícekrokovém scénáři by proces odeslání pravděpodobně zahrnoval několik kroků, takže v úložišti stavů by se vytvořilo několik záznamů – každý z nich popisuje stav jednotlivého kroku.

Plánovač také běží jako pracovní proces na pozadí a implementuje obchodní logiku, která zpracovává pořadí. Instance dotazování plánovače na nové objednávky hledá v úložišti stavů záznamy, ve kterých má pole LockedBy hodnotu null a pole ProcessState je čekající. Když plánovač zjistí novou objednávku, okamžitě vloží do pole LockedBy ID své vlastní instance, do pole CompleteBy zadá příslušný čas a pole ProcessState změní na stav Processing. Kód je navržený jako výhradní a atomický, aby se předešlo tomu, že se dvě současně spuštěné instance plánovače pokusí zpracovat stejnou objednávku.

Plánovač pak spustí obchodní pracovní postup pro asynchronní zpracování objednávky, předává mu hodnotu pole OrderID z úložiště stavů. Pracovní postup, který objednávku zpracovává, načte podrobnosti objednávky z databáze objednávek a provede požadované operace. Když některý krok pracovního postupu zpracování objednávky potřebuje vyvolat vzdálenou službu, použije agenta. Krok pracovního postupu komunikuje s agentem pomocí dvojice Azure Service Bus front zpráv, které fungují jako kanál pro žádosti a odpovědi. Obrázek znázorňuje základní zobrazení řešení.

Zpráva odeslaná agentovi z kroku pracovního postupu popisuje objednávku a obsahuje časový limit na dokončení. Pokud agent obdrží odpověď ze vzdálené služby před uplynutím doby určené pro dokončení, zveřejní odpověď ve frontě Service Bus, kde pracovní postup naslouchá. Když krok pracovního postupu obdrží platnou zprávu odpovědi, dokončí své zpracování a plánovač nastaví pole ProcessState stavu objednávky na zpracováno. V tomto okamžiku je zpracování objednávky úspěšně dokončeno.

Pokud vyprší doba dokončení, než agent obdrží odpověď ze vzdálené služby, agent zastaví zpracování a ukončí zpracování objednávky. Stejně tak se pracovní postup zpracovávající objednávku ukončí, pokud překročí časový limit. V obou případech zůstane stav objednávky v úložišti stavů nastavený na zpracovávání, ale čas pro dokončení bude označovat, že čas na zpracování objednávky vypršel, a proces se bude považovat za neúspěšný. Pokud agent přistupující k vzdálené službě nebo pracovní postup, který zpracovává objednávku, neočekávaně ukončen, informace v úložišti stavů zůstanou nastavené na zpracování a nakonec mají prošlou hodnotu dokončení.

Pokud agent během pokusu o kontaktování vzdálené služby zjistí neopravitelnou chybu, která není přechodná, může o této chybě informovat workflow. Plánovač může u objednávky nastavit chybový stav a vyvolat událost, která odešle výstrahu operátorovi. Operátor pak může zkusit příčinu selhání vyřešit ručně a obnovit zpracování příslušného neúspěšného kroku.

Správce pravidelně kontroluje úložiště stavů a hledá objednávky, u kterých vypršel časový limit. Pokud správce nějaký takový záznam najde, inkrementuje pole FailureCount. Pokud je hodnota počtu selhání nižší než zadaná prahová hodnota, pak správce resetuje pole LockedBy na hodnotu null, aktualizuje pole CompleteBy na nový čas vypršení platnosti a v poli ProcessState nastaví hodnotu Pending. Instance plánovače může tuto objednávku převzít a zopakovat pokus o její zpracování. Jakmile hodnota počtu selhání překročí zadanou prahovou hodnotu, předpokládá se, že příčina selhání je trvalá. Správce nastaví u objednávky chybový stav a vyvolá událost, která odešle výstrahu operátorovi.

V tomto příkladu se správce implementuje jako samostatný proces běžící na pozadí. Pomocí různých strategií můžete zajistit spuštění úlohy správce, například použití funkcí aktivovaných časovačem v Azure Functions nebo naplánované úlohy v Azure Container Apps.

I když to tento příklad neukazuje, plánovač může chtít, aby byla aplikace, která objednávku odeslala, informována o průběhu a stavu této objednávky. Aplikace a plánovač jsou navzájem oddělené, aby se předešlo vzniku případných závislostí mezi nimi. Aplikace nemá žádné informace o tom, která instance plánovače objednávku zpracovává, a plánovač nemá žádné informace o tom, která instance aplikace objednávku odeslala.

K povolení reportování stavu objednávky může aplikace použít svoji vlastní privátní frontu odpovědí. Podrobnosti o této frontě odpovědí by byly zahrnuty jako součást žádosti zaslané procesu odeslání, který by tyto informace uložil ve státním úložišti. Plánovač pak do této fronty zveřejní zprávy označující stav objednávky (například přijetí požadavku, dokončení objednávky a selhání objednávky). V těchto zprávách je potřeba uvádět ID objednávek, aby mohly být přiřazeny k původním žádostem z aplikace.

Další kroky

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

• Úvod k asynchronnímu zasílání zpráv: Komponenty modelu plánovač-agent-správce obvykle běží navzájem odděleně a komunikují asynchronně. Popisuje některé z přístupů, které lze použít k implementaci asynchronní komunikaci na základě front zpráv.

• Reference 6: Sága o ságách. Příklad znázorňující, jak vzor CQRS využívá správce procesů (součást průvodce CQRS Journey).

• Plánovač Microsoft Azure

Související prostředky

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

• Model opakování. Agent může tento vzorec použít k transparentnímu opakování operací, které přistupují k vzdálené službě nebo prostředku a dříve selhaly. Používejte ho, pokud očekáváte, že příčina selhání je přechodná a chyba bude opravena.

• Vzor Circuit Breaker. Agent může pomocí tohoto modelu zpracovávat chyby připojení ke vzdálené službě nebo prostředku, jejichž oprava trvá různě dlouho.

• Model kompenzační transakce: Pokud pracovní postup prováděný plánovačem nemůže být dokončen úspěšně, může být potřeba vrátit zpět veškeré dříve provedené akce. Vzorec kompenzační transakce popisuje, jak to lze dosáhnout u operací, které se řídí modelem eventualní konzistence. Tyto typy operací implementuje běžně plánovač, který provádí komplexní obchodní procesy a pracovní postupy.

• Model volby vedoucího procesu. Může být potřeba koordinovat akce více instancí správce, a předejít tak tomu, aby se více instancí pokoušelo obnovit stejný neúspěšný proces. Jak to udělat, popisuje model volby vedoucího procesu.

• Architektura cloudu: Vzorec Scheduler-Agent-Supervisor na blogu Clemense Vasterse

• Model správce procesu