Sdílet prostřednictvím

Spolehlivé zpracování událostí s využitím Azure Functions a event Hubs

Naučte se vytvářet robustní a spolehlivá bezserverová řešení s využitím azure Functions s triggery služby Azure Event Hubs. Tento článek popisuje osvědčené postupy pro kontrolní body, zpracování chyb a implementaci vzorů přerušovače obvodu, aby se zajistilo, že nedojde k žádné ztrátě událostí a vaše aplikace řízené událostmi zůstaly stabilní a pružné.

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

Zvažte systém, který odesílá události konstantní rychlostí 100 událostí za sekundu. Při tomto tempu mohou během několika minut paralelní instance zpracovat příchozích 100 událostí za sekundu.

Zvažte ale tyto výzvy při využívání streamu událostí:

  • Vydavatel události odešle poškozenou událost.
  • Kód funkce narazí na neošetřenou výjimku.
  • Podřízený systém přejde do režimu offline a blokuje zpracování událostí.

Na rozdíl od spouštěče Azure Queue Storage, který zamkne zprávy během zpracování, služba Azure Event Hubs čte z jednotlivých oddílů od jednoho bodu v datovém proudu. Toto chování při čtení, které se podobá přehrávači videa, poskytuje požadované výhody vysoké propustnosti, více skupin příjemců a možnosti přehrání. Události se čtou od kontrolního bodu, a to buď dopředu, nebo dozadu, ale je nutné přesunout kurzor pro zpracování nových událostí. Další informace najdete v dokumentaci ke službě Event Hubs v části Kontrolní bod.

Pokud dojde k chybám ve streamu a vy se rozhodnete ukazatel nepřecházet, bude další zpracování událostí blokováno. Jinými slovy, pokud zastavíte ukazatel kvůli řešení problému při zpracování jediné události, začnou se nezpracované události hromadit.

Funkce se vyhýbá zablokování tím, že vždy posouvá ukazatel proudu bez ohledu na úspěch nebo selhání. Vzhledem k tomu, že ukazatel pokračuje dál, vaše funkce musí správně řešit selhání.

Způsob, jakým trigger služby Event Hubs využívá události

Azure Functions využívá události z centra událostí cyklicky pomocí následujících kroků:

  1. Pro každý oddíl centra událostí se vytvoří a zachová ukazatel ve službě Azure Storage.
  2. Nové události jsou (ve výchozím nastavení) přijímány po dávkách a hostitel se pokouší aktivovat funkci, která zpracovává dodané dávky událostí.
  3. Po dokončení provádění funkce, ať už s výjimkami nebo bez nich, se ukazatel posune a kontrolní bod se uloží do výchozího účtu úložiště hostitele.
  4. Pokud podmínky brání dokončení provádění funkce, hostitel nemůže ukazatel posunout. Pokud ukazatel nemůže postoupit, následné spuštění znovu zpracovává stejné události.

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

  • Neošetřené výjimky můžou způsobit ztrátu událostí:

    Provádění funkcí, které vyvolávají výjimku, pokračuje posunem ukazatele. Nastavení zásad opakování nebo jiné logiky opakování zpožďuje posun ukazatele, dokud se celý pokus neskončí.

  • Funkce zaručuje alespoň jedno doručení:

    Váš kód a závislé systémy možná budou muset zohlednit skutečnost, že stejná událost by mohla být zpracována dvakrát. Další informace najdete v tématu Návrh služby Azure Functions pro stejný vstup.

Zpracování výjimek

I když veškerý kód funkce by měl obsahovat blok try/catch na nejvyšší úrovni kódu, je catch blok ještě důležitější pro funkce, které využívají události event Hubs. Tímto způsobem, když dojde k vyvolání výjimky, blok catch zachytí chybu dříve, než ukazatel postoupí dál.

Mechanismy opakování a zásady

Vzhledem k tomu, že mnoho výjimek v cloudu je přechodných, prvním krokem při zpracování chyb je vždy opakování operace. Můžete použít předdefinované zásady opakování nebo definovat vlastní logiku opakování.

Zásady opakování pokusů

Služba Functions poskytuje integrované zásady opakování pro službu Event Hubs. Při použití zásad opakování jednoduše vyvoláte novou výjimku a hostitel se pokusí událost znovu zpracovat na základě definovaných zásad. Toto chování opakování vyžaduje verzi 5.x nebo novější rozšíření Event Hubs. Další informace najdete v tématu Zásady opakování.

Vlastní logika opakování

Můžete také definovat vlastní logiku opakování v samotné funkci. Můžete například implementovat zásadu, která následuje za pracovním postupem znázorněným následujícími pravidly:

  • Zkuste událost zpracovat třikrát (potenciálně se zpožděním mezi opakovanými pokusy).
  • Pokud je konečný výsledek všech opakování selhání, přidejte událost do fronty, aby mohlo zpracování pokračovat ve streamu.
  • Poškozené nebo nezpracované události se pak zpracovávají později.

Poznámka:

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

Chyby bez výjimek

K některým problémům může dojít bez vyvolání výjimky. Představte si například případ, kdy vyprší časový limit požadavku nebo dojde k chybovému ukončení instance, ve které je funkce spuštěná. Pokud se funkce nepodaří dokončit bez výjimky, ukazatel posunu se nikdy neposune. Pokud ukazatel nepřejde, všechny instance, které se spustí po neúspěšném spuštění, budou nadále číst stejné události. Tato situace poskytuje alespoň jednou záruku.

Zajištění, že každá událost je zpracována alespoň jednou, znamená to, že některé události mohou být zpracovány více než jednou. Vaše aplikace funkcí musí o této možnosti vědět a musí být postaveny na principech idempotenci.

Zpracování stavů selhání

Vaše aplikace může vyhovujícím způsobem zvládnout několik chyb při zpracování událostí. Měli byste však být také připraveni na zpracování trvalého stavu selhání, ke kterému může dojít v důsledku selhání v podřízeném zpracování. V takovém stavu selhání, například podřízené úložiště dat, které je offline, by vaše funkce měla zastavit aktivaci událostí, dokud systém nedosáhne stavu v pořádku.

Model jističe

Když implementujete model jističe , může aplikace efektivně pozastavit zpracování událostí a později ho obnovit po vyřešení problémů.

K implementaci jističe v procesu streamu událostí jsou potřeba dvě komponenty:

  • Sdílený stav ve všech instancích ke sledování a monitorování stavu okruhu.
  • Primární proces, který může spravovat stav okruhu buď jako open, nebo jako closed.

Podrobnosti implementace se mohou lišit, ale ke sdílení stavu mezi instancemi potřebujete mechanismus úložiště. Stav můžete uložit ve službě Azure Storage, mezipaměti Redis nebo jakékoli jiné trvalé službě, ke které mají přístup instance vaší aplikace funkcí.

Durable Functions i Azure Logic Apps poskytují infrastrukturu pro správu pracovních postupů a stavů okruhů. Tento článek popisuje použití Logic Apps k pozastavení a restartování provádění funkcí, což vám dává kontrolu potřebnou k implementaci vzoru jističe.

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

Trvalý sdílený externí stav je vyžadován ke sledování zdraví okruhu, když více instancí současně zpracovává události. Pak můžete monitorovat tento trvalý stav na základě pravidel, která označují stav selhání, například:

Pokud ve všech instancích dojde k více než 100 selháním událostí během 30sekundového období, přerušte okruh a zastavte aktivaci u nových událostí.

Podrobnosti implementace pro tuto logiku monitorování se liší v závislosti na konkrétních potřebách aplikace, ale obecně musíte vytvořit systém, který:

  1. Zaznamenává chyby do trvalého úložiště.
  2. Zkontrolujte klouzavý počet, když se zaznamenají nová selhání, abyste zjistili, jestli je prahová hodnota selhání události splněna.
  3. Po splnění této prahové hodnoty vygenerujte událost, která systému říká, aby přerušil okruh.

Správa stavu okruhu pomocí Azure Logic Apps

Azure Logic Apps nabízí integrované konektory pro různé služby, funkce a stavové orchestrace a je přirozenou volbou pro správu stavu okruhu. Po zjištění, kdy se okruh musí přerušit, můžete vytvořit aplikaci logiky pro implementaci tohoto pracovního postupu:

  1. Aktivujte pracovní postup Event Gridu, který zastaví zpracování funkce.
  2. Odešlete e-mail s oznámením, který obsahuje možnost restartování pracovního postupu.

Informace o zakázání a opětovném povolení konkrétních funkcí pomocí nastavení aplikace najdete v tématu Postup zakázání funkcí ve službě Azure Functions.

Příjemce e-mailu může zjistit stav okruhu a případně ho restartovat prostřednictvím odkazu v e-mailu s oznámením. Při restartování funkce se události zpracovávají z posledního kontrolního bodu centra událostí.

Při použití tohoto přístupu se neztratí žádné události, události se zpracovávají v pořadí a okruh můžete přerušit, pokud je to potřeba.

Strategie migrace pro Event Grid spouště

Když migrujete existující aplikaci funkcí mezi oblastmi nebo mezi některými plány, musíte aplikaci během procesu migrace znovu vytvořit. V takovém případě během procesu migrace můžete mít dvě aplikace, které můžou využívat stejný datový proud událostí a zapisovat do stejného výstupního cíle.

Měli byste zvážit použití skupin příjemců , abyste se vyhnuli ztrátě nebo duplikaci dat událostí během procesu migrace:

  1. Vytvořte novou skupinu příjemců pro novou cílovou aplikaci.

  2. Nakonfigurujte trigger v nové aplikaci tak, aby používal tuto novou skupinu příjemců.

    To umožňuje, aby obě aplikace zpracovávaly události nezávisle během ověřování.

  3. Ověřte, že nová aplikace správně zpracovává události.

  4. Zastavte původní aplikaci nebo odeberte její předplatné nebo skupinu příjemců.

  • Last updated on