Azure Functions spolehlivé zpracování událostí

  • Článek

Zpracování událostí je jedním z nejběžnějších scénářů přidružených k bezserverové architektuře. Tento článek popisuje, jak vytvořit spolehlivý procesor zpráv s Azure Functions, aby se zabránilo ztrátě zpráv.

Výzvy datových proudů událostí v distribuovaných systémech

Představte si systém, který odesílá události konstantní rychlostí 100 událostí za sekundu. Při této rychlosti může několik instancí paralelních funkcí během několika minut každou sekundu spotřebovat příchozích 100 událostí.

Jsou však možné některé z následujících méně optimálních podmínek:

  • Co když vydavatel události odešle poškozenou událost?
  • Co když vaše instance Functions narazí na neošetřené výjimky?
  • Co když podřízený systém přejde do režimu offline?

Jak tyto situace zvládnout při zachování propustnosti aplikace?

Díky frontám přichází spolehlivé zasílání zpráv přirozeně. Při spárování s triggerem functions funkce vytvoří zámek ve zprávě fronty. Pokud zpracování selže, zámek se uvolní, aby se jiná instance mohla pokusit o zpracování znovu. Zpracování pak pokračuje, dokud se zpráva úspěšně vyhodnotí nebo se nepřidá do fronty jedů.

I když jedna zpráva ve frontě může zůstat v cyklu opakování, ostatní paralelní spuštění budou dál odstrašovat zbývající zprávy. Výsledkem je, že na celkovou propustnost do značné míry nemá vliv jedna špatná zpráva. Fronty úložiště ale nezaručují řazení a nejsou optimalizované pro vysoké požadavky na propustnost vyžadované službou Event Hubs.

Naproti tomu Azure Event Hubs neobsahuje koncept zamykání. Aby bylo možné používat funkce, jako je vysoká propustnost, více skupin uživatelů a schopnost přehrávání, události služby Event Hubs se chovají spíše jako videopřehrávač. Události se čtou z jednoho bodu ve streamu na oddíl. Z ukazatele můžete číst dopředu nebo dozadu z daného umístění, ale musíte se rozhodnout přesunout ukazatel, aby se události zpracovávaly.

Pokud dojde k chybám ve streamu a rozhodnete se ponechat ukazatel na stejném místě, zpracování událostí se zablokuje, dokud ukazatel nebude pokročilý. Jinými slovy, pokud je ukazatel zastaven, aby se vyřešily problémy se zpracováním jedné události, nezpracované události se začnou hromadit.

Azure Functions se vyhýbá vzájemným zablokováním tím, že posune ukazatel streamu bez ohledu na úspěch nebo selhání. Vzhledem k tomu, že ukazatel stále postupuje, musí vaše funkce správně řešit chyby.

Jak Azure Functions využívá události služby Event Hubs

Azure Functions využívá události centra událostí během procházení následujících kroků:

  1. Ukazatel se vytvoří a zachová ve službě Azure Storage pro každý oddíl centra událostí.
  2. Při přijetí nových zpráv (ve výchozím nastavení v dávce) se hostitel pokusí aktivovat funkci dávkou zpráv.
  3. Pokud funkce dokončí provádění (s výjimkou nebo bez výjimky), ukazatel přejde dál a kontrolní bod se uloží do účtu úložiště.
  4. Pokud podmínky brání dokončení provádění funkce, hostitel ukazatel nepovede. Pokud ukazatel není pokročilý, pak pozdější kontroly nakonec zpracovávají stejné zprávy.
  5. Zopakujte kroky 2–4.

Toto chování odhalí několik důležitých bodů:

Zpracování výjimek

Obecně platí, že každá funkce by měla obsahovat blok try/catch na nejvyšší úrovni kódu. Konkrétně všechny funkce, které využívají události služby Event Hubs, by měly mít catch blok. Tímto způsobem, když je vyvolána výjimka, blok zachycení zpracuje chybu před průběhem ukazatele.

Mechanismy a zásady opakování

Některé výjimky jsou přechodné povahy a neobjevují se znovu při pokusu o operaci o chvíli později. Proto je prvním krokem vždy opakování operace. V rámci provádění funkce můžete využít zásady opakování aplikace funkcí nebo vytvořit logiku opakování.

Zavedení chování při zpracování chyb do funkcí vám umožní definovat základní i pokročilé zásady opakování. Můžete například implementovat zásadu, která se řídí pracovním postupem znázorněným následujícími pravidly:

  • Zkuste vložit zprávu třikrát (potenciálně se zpožděním mezi opakovanými pokusy).
  • Pokud je konečným výsledkem všech opakování selhání, přidejte zprávu do fronty, aby zpracování ve streamu pokračovalo.
  • Poškozené nebo nezpracované zprávy se pak zpracovávají později.

Poznámka

Polly je příkladem knihovny odolnosti a zpracování přechodných chyb pro aplikace v jazyce C#.

Chyby bez výjimek

K některým problémům dochází i v případě, že není k dispozici chyba. Představte si například selhání, ke kterému dochází uprostřed provádění. Pokud v tomto případě funkce nedokončí provádění, ukazatel posunu nikdy nepostupuje. Pokud ukazatel nepřejde dál, pak všechny instance, které se spustí po neúspěšném spuštění, budou dál číst stejné zprávy. Tato situace poskytuje záruku "alespoň jednou".

Jistota, že každá zpráva bude zpracována alespoň jednou, znamená, že některé zprávy mohou být zpracovány více než jednou. Vaše aplikace funkcí si musí být této možnosti vědomy a musí být postaveny na principech idempotence.

Zastavení a restartování spouštění

I když může být přijatelných několik chyb, co když u vaší aplikace dochází k významným selháním? Možná budete chtít přestat spouštět události, dokud systém nedosáhne stavu v pořádku. Možnost pozastavit zpracování se často dosahuje pomocí vzoru jističe. Model jističe umožňuje aplikaci "přerušit okruh" procesu události a pokračovat později.

K implementaci jističe v procesu události jsou potřeba dvě části:

  • Sdílený stav napříč všemi instancemi za účelem sledování a monitorování stavu okruhu
  • Hlavní proces, který může spravovat stav okruhu (otevřený nebo uzavřený)

Podrobnosti o implementaci se můžou lišit, ale ke sdílení stavu mezi instancemi potřebujete mechanismus úložiště. Můžete se rozhodnout uložit stav do Azure Storage, mezipaměti Redis nebo jakéhokoli jiného účtu, ke kterému má přístup kolekce funkcí.

Azure Logic Apps nebo durable functions se přirozeně hodí ke správě pracovního postupu a stavu okruhu. Stejně dobře můžou fungovat i jiné služby, ale v tomto příkladu se používají aplikace logiky. Pomocí aplikací logiky můžete pozastavit a restartovat provádění funkce a získat tak kontrolu potřebnou k implementaci vzoru jističe.

Definování prahové hodnoty selhání napříč instancemi

Aby bylo možné zohlednit více instancí zpracovávajících události současně, je potřeba zachovat sdílený externí stav pro monitorování stavu okruhu.

Pravidlo, které se můžete rozhodnout implementovat, může vynutit:

  • Pokud během 30 sekund ve všech instancích dojde k více než 100 případným selháním, přerušte okruh a zastavte aktivaci u nových zpráv.

Podrobnosti o implementaci se budou lišit vzhledem k vašim potřebám, ale obecně můžete vytvořit systém, který:

  1. Protokolování selhání do účtu úložiště (Azure Storage, Redis atd.)
  2. Při zaprotokolování nového selhání zkontrolujte průběžný počet a zjistěte, jestli je dosaženo prahové hodnoty (například více než 100 za posledních 30 sekund).
  3. Pokud je prahová hodnota splněna, vygenerujte událost, která Azure Event Grid systému řekne, aby přerušil okruh.

Správa stavu okruhu pomocí Azure Logic Apps

Následující popis ukazuje jeden ze způsobů, jak můžete vytvořit aplikaci logiky Azure, která zastaví zpracování aplikace Functions.

Azure Logic Apps se dodává s integrovanými konektory pro různé služby, nabízí stavovou orchestraci a je přirozenou volbou pro správu stavu okruhu. Po zjištění potřeby přerušení okruhu můžete vytvořit aplikaci logiky pro implementaci následujícího pracovního postupu:

  1. Aktivace pracovního postupu Event Gridu a zastavení funkce Azure (s konektorem prostředků Azure)
  2. Odeslání e-mailu s oznámením, který obsahuje možnost restartování pracovního postupu

Příjemce e-mailu může prozkoumat stav okruhu a v případě potřeby ho restartovat prostřednictvím odkazu v e-mailu s oznámením. Při restartování funkce pracovním postupem se zprávy zpracovávají z posledního kontrolního bodu centra událostí.

Při použití tohoto přístupu se neztratí žádné zprávy, všechny zprávy se zpracují v pořadí a můžete přerušit okruh tak dlouho, jak je to nutné.

Zdroje informací

Další kroky

Další informace naleznete v následujících zdrojích: