Odolný Event Hubs a functions

  • Článek
  • 9 min ke čtení

Zpracování chyb, návrh idempotence a správa chování při opakování jsou několika důležitými opatřeními, která můžete udělat, abyste zajistili, že funkce aktivované pomocí funkce Event Hubs budou odolné a schopné zpracování velkých objemů dat. Tento článek popisuje tyto klíčové koncepty a nabízí doporučení pro řešení bez serveru pro streamování událostí.

Azure poskytuje tři hlavní služby zasílání zpráv, které je možné Azure Functions pro podporu široké škály jedinečných scénářů řízených událostmi. Vzhledem k modelu rozděleným na oddíly a schopnosti ingestovat data vysokou rychlostí se Azure Event Hubs pro scénáře streamování událostí a velkých dat. Podrobné porovnání služeb zasílání zpráv Azure najdete v tématu Volba mezi službami zasílání zpráv Azure – Event Grid, Event Hubsa Service Bus .

Výhody a problémy související se streamováním

Pochopení výhod a nevýhod datových proudů vám pomůže pochopit, jak služba jako Event Hubs funguje. Tento kontext potřebujete také při rozhodování o architektuře, řešení potíží a optimalizaci výkonu. Vezměte v úvahu následující klíčové koncepty řešení s Event Hubs a Functions:

  • Toky nejsou fronty: Event Hubs, Kafka a další podobné nabídky, které jsou postavené na děleném modelu příjemce, vnitřně nepodporují některé hlavní funkce ve zprostředkovateli zpráv, jako je Service Bus. Pravděpodobně největším indikátorem je skutečnost, že čtení jsou nedestruktivní. To znamená, že data, která čte hostitel služby Functions, se následně odstraní. Místo toho jsou zprávy neměnné a zůstávají pro ostatní uživatele, včetně potenciálně stejného zákazníka, který je znovu čte. Z tohoto důvodu jsou řešení, která implementují vzory, jako jsou konkurenční spotřebitelé, lépe hodí pro tradičního zprostředkovatele zpráv.

  • Chybějící podpora zdědí dead-letter: Kanál bez zprávy není nativní funkcí v systému Event Hubs Kafka. Koncept dead-letteringu je často integrovaný do řešení streamování, aby se zohlednila data, která nelze zpracovat. Tato funkce záměrně není v souboru Event Hubs a přidává se jenom na straně konzumenta, aby se vyrobí podobné chování nebo účinek. Pokud potřebujete podporu pro dead-letter, měli byste si potenciálně zkontrolovat vaši volbu služby streamování zpráv.

  • Pracovní jednotkou je oddíl: V tradičním zprostředkovateli zpráv je pracovní jednotkou jedna zpráva. V řešení streamování se oddíl často považuje za jednotku práce. Pokud se každá událost v centru událostí považuje za samostatnou zprávu, která vyžaduje, aby se s ní zacházelo jako s operací zpracování objednávky nebo finanční transakcí, pravděpodobně se jedná o indikaci použití nesprávné služby zasílání zpráv.

  • Žádné filtrování na straně serveru: Jedním z důvodů Event Hubs je schopnost obrovského škálování a propustnosti, je nízká režie na samotnou službu. Funkce, jako je filtrování na straně serveru, indexy a koordinace mezi zprostředkovateli, nejsou součástí architektury Event Hubs. Funkce se občas používají k filtrování událostí jejich směrováním do jiných Event Hubs na základě obsahu v těle nebo hlavičce. Tento přístup je při streamování událostí běžný, ale má upozornění, že počáteční funkce čte a vyhodnocuje každou událost.

  • Každý čtenář musí číst všechna data: Protože filtrování na straně serveru není k dispozici, příjemce postupně načte všechna data v oddílu. To zahrnuje data, která nemusí být relevantní nebo by dokonce mohla být poškozena. Existuje několik možností a dokonce i strategií, které je možné použít ke kompenzaci těchto výzev, kterým se budeme dále v této části radit.

Tato významná rozhodnutí o Event Hubs umožňují uživatelům dělat to, co dělá nejlépe: podporovat výrazný nárůst událostí a poskytovat robustní a odolnou službu pro uživatele, ze které si mohou číst. Každá spotřebitelská aplikace má za úkol udržovat vlastní posuny na straně klienta nebo kurzor na tyto události. Nízká režie Event Hubs cenově dostupnou a výkonnou možnost streamování událostí.

Idempotence

Jedním ze základních principů Azure Event Hubs koncept alespoň jednoho doručení. Tento přístup zajišťuje, že se události budou vždy doručovat. Také to znamená, že spotřebiteli, jako je funkce, mohou události přijata více než jednou, dokonce opakovaně. Z tohoto důvodu je důležité, aby funkce aktivovaná centrem událostí podporuje model idempotentního příjemce.

Práce s předpokladem alespoň jednoho doručení, zejména v kontextu architektury řízené událostmi, je zodpovědným přístupem pro spolehlivé zpracování událostí. Vaše funkce musí být idempotentní, aby byl výsledek vícenásobného zpracování stejné události stejný jako při zpracování jednou.

Duplicitní události

Existuje několik různých scénářů, které mohou mít za následek doručení duplicitních událostí do funkce:

  • Kontrolní body: Pokud Azure Functions dojde k chybě hostitele nebo prahová hodnota nastavená pro četnost dávkových kontrolních bodů není splněna, kontrolní bod se nevytvaruje. V důsledku toho posun příjemce není pokročilý a při příštím vyvolání funkce bude pokračovat od posledního kontrolního bodu. Je důležité si uvědomit, že vytváření kontrolních bodů pro každého příjemce probíhá na úrovni oddílu.

  • Publikované duplicitní události: Existuje mnoho technik, které by mohly zmírnit možnost publikování stejné události do datového proudu, ale stále je zodpovědností příjemce idempotentního zpracování duplicit.

  • Chybějící potvrzení: V některých situacích může být odchozí požadavek na službu úspěšný, ale potvrzení (ACK) ze služby se nikdy nepřijí. To může vést k tomu, že odchozí volání selhalo a iniciuje řadu, opakování nebo jiné výsledky z funkce. Nakonec je možné publikovat duplicitní události nebo se nevytyčí kontrolní bod.

Techniky odstranění duplicitních dat

Při navrhování funkcí pro identický vstup by se měl použít výchozí přístup při spárování s vazbou triggeru centra událostí. Měli byste zvážit následující techniky:

  • Hledání duplicit: Před zpracováním udělejte potřebné kroky, abyste ověřili, že se má událost zpracovat. V některých případech to bude vyžadovat šetření, které potvrdí, že je stále platné. Také může být možné, že zpracování události už není potřeba, protože data jsou aktuální nebo je logika, která událost zneplatňuje.

  • Události návrhu pro idempotence: Poskytnutím dalších informací v rámci datové části události může být možné zajistit, aby vícenásobné zpracování nebude mít žádné škodlivé účinky. Vezměme si příklad události, která zahrnuje částku, kterou je třeba využít z bankovního účtu. Pokud se s účtem nezachází zodpovědně, je možné, že se zůstatek účtu sníží vícekrát. Pokud ale stejná událost zahrnuje aktualizovaný zůstatek na účtu, může se použít k provedení operace upsertování zůstatku bankovního účtu. Tento přístup k přenosu stavu při přenosu událostí občas vyžaduje koordinaci mezi producenty a spotřebiteli a měl by se používat, když dává smysl účastnickým službám.

Zpracování chyb a opakování

Zpracování chyb a opakování jsou některé z nejdůležitějších vlastností distribuovaných aplikací řízených událostmi a funkce nejsou výjimkou. V případě řešení streamování událostí je zásadní potřeba správné podpory zpracování chyb, protože pokud se nezvládnou správně, tisíce událostí se mohou rychle změnit na stejný počet chyb.

Pokyny ke zpracování chyb

Bez zpracování chyb může být obtížné implementovat opakování, detekovat výjimky modulu runtime a zkoumat problémy. Každá funkce by měla mít alespoň nějakou úroveň zpracování chyb. Tady je několik doporučených pokynů:

  • Použití nástroje Application Přehledy: Povolte a používejte Přehledy k protokolování chyb a monitorování stavu vašich funkcí. U scénářů, které zpracovávají velké množství událostí, je třeba mít na paměti konfigurovatelné možnosti vzorkování.

  • Přidání strukturovaného zpracování chyb: Použijte příslušné konstruktory zpracování chyb pro každý programovací jazyk k zachycení, protokolování a detekci očekávaných a neošetřených výjimek v kódu funkce. Použijte například blok try/catch v jazyce C, Javě a JavaScriptu a ke zpracování výjimek využijte bloky try a except v # Pythonu.

  • Protokolování: Zachycení výjimky během provádění poskytuje příležitost protokolovat důležité informace, které by bylo možné použít ke spolehlivé detekci, reprodukci a opravě problémů. Za protokolování výjimky, nejen zprávy, ale těla, vnitřní výjimky a dalších užitečných artefaktů, které budou užitečné později.

  • Nezachyťujte a ignorujte výjimky: Jednou z nejhorších věcí, které můžete udělat, je zachytit výjimku a nic s ní nedělat. Pokud zachytíte obecnou výjimku, někam ji za přihlaste. Pokud nezachytáte chyby, je obtížné zkoumat chyby a nahlášené problémy.

Opakování

Implementace logiky opakování v architektuře streamování událostí může být složitá. Podpora tokenů zrušení, počtů opakování a exponenciálních strategií odpůrců je jen několik z důvodů, proč je to náročné. Functions naštěstí poskytuje zásady opakování, které mohou mnohé z těchto úloh, které byste si obvykle kódovat sami, nasaděli.

Při používání zásad opakování s vazbou centra událostí je třeba zvážit několik důležitých faktorů:

  • Vyhněte se neurčitým opakováním: Pokud je nastavení maximálního počtu opakování nastaveno na hodnotu -1, funkce se bude opakovat po neomezenou dobu. Obecně platí, že neurčitý počet opakování by se měl používat s funkcí bez omezení a téměř nikdy by se neměl používat s vazbou triggeru centra událostí.

  • Zvolte vhodnou strategii opakování: Strategie pevného zpoždění může být optimální pro scénáře, které přijímají tlak zpět z jiných služeb Azure. V těchto případech může zpoždění pomoct vyhnout se omezování a dalším omezením, ke kterým u těchto služeb došlo. Exponenciální strategie zpomalování nabízí větší flexibilitu pro intervaly zpoždění opakování a běžně se používá při integraci se službami třetích stran, koncovými body REST a dalšími službami Azure.

  • Udržujte intervaly a počty opakování nízké: Pokud je to možné, zkuste interval opakování udržovat kratší než jednu minutu. Také udržujte maximální počet pokusů o opakování na přiměřeně nízkém počtu. Tato nastavení jsou relevantní zejména při spuštění v plánu Functions Consumption.

  • Model jističe: Čas od času se očekává přechodná chyba a přirozený případ použití při opakování. Pokud však během zpracování funkce dochází k významnému počtu selhání nebo problémů, může mít smysl funkci zastavit, vyřešit problémy a později ji restartovat.

Důležitým aspektem zásad opakování ve Functions je, že se jedná o funkci, která se snaží události znovu zpracovat. Nenahrazuje potřebu zpracování chyb, protokolování a dalších důležitých vzorů, které zajišťují odolnost kódu.

Strategie pro selhání a poškozená data

Existuje několik pozoruhodných přístupů, které můžete použít ke kompenzaci problémů, ke které dochází v důsledku selhání nebo špatných dat v datovém proudu událostí. Tady jsou některé základní strategie:

  • Ukončení odesílání a čtení: Pozastavením čtení a zápisu událostí opravíte základní problém. Výhodou tohoto přístupu je, že data se neztratí a po nashrování opravy může operace pokračovat. Tento přístup může vyžadovat součást jističe v architektuře a případně oznámení ovlivněným službám, aby bylo možné dosáhnout pozastavení. V některých případech může být zastavení funkce nezbytné, dokud se problémy nevyřeší.

  • Zahodí se zprávy: Pokud zprávy nejsou důležité nebo jsou považovány za neposouzné, zvažte jejich přechod a nezpracování. To nefunguje ve scénářích, které vyžadují silnou konzistenci, jako je zaznamenávání přesunů do zápasu nebo transakcí založených na financích. Zpracování chyb uvnitř funkce se doporučuje pro zachytání a zahazování zpráv, které nelze zpracovat.

  • Zkuste to znovu: Existuje mnoho situací, které mohou zaručovat opětovné zpracování události. Nejběžnějším scénářem je přechodná chyba při volání jiné služby nebo závislosti. Chyby sítě, limity služeb, dostupnost a silná konzistence jsou pravděpodobně nejčastější případy použití, které odůvodňují pokusy o opětovné zpracování.

  • Dead letter (Neschůdné): Myšlenkou je publikovat událost do jiného centra událostí, aby se stávající tok nepřerušil. Dojem je, že se posunul z horké cesty a mohl by se s ním vypořádat později nebo jiným procesem. Toto řešení se často používá ke zpracování chybně používaných zpráv nebo událostí. Je třeba mít na paměti, že každá funkce nakonfigurovaná s jinou skupinou uživatelů stále narazí na chybná nebo poškozená data ve svém datovém proudu a musí je zpracovat zodpovědně.

  • Opakování a dead letter: Další známou metodou je kombinace mnoha opakování pokusů před konečným publikováním do datového proudu s dead letter po překročení prahové hodnoty.

  • Použití registru schémat: Registr schémat lze použít jako proaktivní nástroj, který pomáhá zlepšit konzistenci a kvalitu dat. Azure Schema Registry může podporovat přechod schémat spolu se sekcí verzí a různými režimy kompatibility s tím, jak se schémata vyvíjejí. V jádru bude schéma sloužit jako kontrakt mezi producenty a spotřebiteli, což by mohlo snížit možnost publikování neplatných nebo poškozených dat do datového proudu.

Nakonec neexistuje dokonalé řešení a důsledky a kompromisy jednotlivých strategií je potřeba důkladně prozkoumat. Na základě požadavků může být nejlepším přístupem použití několika z těchto technik najednou.

Další kroky

Než budete pokračovat, promyslete si tyto související články:

Zabezpečení