Sdílet prostřednictvím

Odolný návrh služby Event Hubs a funkcí

  • Článek

Zpracování chyb, návrh na idempotenci a správu chování opakování představují několik důležitých opatření, která můžete provést, aby se zajistilo, že aktivované funkce služby Event Hubs jsou odolné a schopné zpracovávat velké objemy dat. Tento článek se zabývá těmito zásadními koncepty a poskytuje doporučení pro řešení bezserverového streamování událostí.

Azure poskytuje tři hlavní služby zasílání zpráv, které je možné použít se službou Azure Functions k podpoře široké škály jedinečných scénářů řízených událostmi. Vzhledem k tomu, že model rozděleného příjemce a schopnost ingestovat data vysokou rychlostí, azure Event Hubs se běžně používá pro scénáře streamování událostí a velkých objemů 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 Hubs a Service Bus.

Výhody a výzvy streamování

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

  • Streamy nejsou fronty: Event Hubs, Kafka a další podobné nabídky, které jsou založené na modelu dělených příjemců, nepodporují některé z hlavních funkcí ve zprostředkovateli zpráv, jako je Service Bus. Možná největší indikátor těchto rozdílů je fakt, že čtení je nedestruktivní. Tím se zajistí, že data přečtená hostitelem Functions zůstanou následně dostupná. Místo toho jsou zprávy neměnné a zůstanou pro ostatní uživatele, kteří je budou číst, včetně potenciálně stejného příjemce, který ho bude číst znovu. Z tohoto důvodu mohou být řešení, která implementují vzory, jako jsou konkurenční spotřebitelé , lépe obsluhována se zprostředkovatelem zpráv, jako je Service Bus.

  • Chybí podpora nedoručených dopisů: Kanál nedoručených dopisů není nativní funkcí ve službě Event Hubs nebo Kafka. Koncept nedoručených dopisů je často integrovaný do řešení streamování, které bude zohledňovat data, která nelze zpracovat. Tato funkce není záměrně prvkem innate ve službě Event Hubs a přidává se pouze na straně spotřebitele, aby bylo možné vytvořit podobné chování nebo účinek. Pokud potřebujete podporu k nedoručenému dopisu, měli byste případně zkontrolovat svou volbu služby streamování zpráv.

  • Jednotka práce je oddíl: V tradičním zprostředkovateli zpráv je jednotka práce jedinou zprávou. 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 odlišnou zprávu vyžadující zpracování objednávek nebo zpracování finančních transakcí, navrhne příležitost prozkoumat vhodnější službu zasílání zpráv pro optimální výkon nebo zpracování.

  • Žádné filtrování na straně serveru: Jedním z důvodů, proč je služba Event Hubs schopná obrovského škálování a propustnosti, je způsobená nízkou režií na samotnou službu. Funkce, jako je filtrování na straně serveru, indexy a koordinace mezi zprostředkovateli, nejsou součástí architektury služby Event Hubs. Funkce se občas používají k filtrování událostí jejich směrováním do jiných center událostí na základě obsahu v těle nebo hlavičce. Tento přístup je běžný při streamování událostí, ale přináší 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í dostupné, příjemce postupně čte všechna data v oddílu. To zahrnuje data, která nemusí být relevantní nebo mohou být dokonce poškozena. K kompenzaci těchto problémů, které jsou popsány dále v této části, lze využít několik možností a strategií.

Tato důležitá rozhodnutí o návrhu umožňují službě Event Hubs dělat to, co dělá nejlépe: podporují významný nárůst událostí a poskytují robustní a odolnou službu, ze které si uživatelé můžou číst. Každá aplikace příjemce má za úkol udržovat si vlastní posuny na straně klienta nebo kurzor na tyto události. Díky nízké režii je Služba Event Hubs cenově dostupnou a výkonnou možností streamování událostí.

Idempotentnost

Jedním ze základních principů služby Azure Event Hubs je koncept aspoň jednoho doručení. Tento přístup zajišťuje, aby se události vždy doručily. Také to znamená, že příjemci, jako je funkce, mohou přijímat více než jednou, dokonce opakovaně. Z tohoto důvodu je důležité, aby aktivovaná funkce centra událostí podporovala model idempotentního příjemce .

Práce na základě předpokladu alespoň jednoho doručení, zejména v kontextu architektury řízené událostmi, je zodpovědným přístupem za spolehlivé zpracování událostí. Vaše funkce musí být idempotentní, aby výsledek zpracování stejné události několikrát byl stejný jako jeho zpracování jednou.

Duplicitní události

Existuje několik různých scénářů, které by mohly vést k doručení duplicitních událostí do funkce:

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

  • Publikované duplicitní události: Mnoho technik může snížit pravděpodobnost, že se stejná událost publikuje do datového proudu, ale příjemce je stále zodpovědný za zpracování duplicitních idempotentních událostí.

  • 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řijalo. Toto vnímání může mít za následek přesvědčení, že odchozí volání selhalo a zahájilo řadu opakovaných pokusů nebo jiných výsledků funkce. Na konci je možné publikovat duplicitní události nebo se nevytvořil kontrolní bod.

Techniky odstranění duplicitních dat

Návrh funkcí pro identický vstup by měl být výchozím přístupem, který se použije při spárování s vazbou triggeru centra událostí. Měli byste zvážit následující techniky:

  • Hledáte duplicity: Před zpracováním proveďte nezbytné kroky k ověření, že se má událost zpracovat. V některých případech to vyžaduje šetření, které potvrzuje, že je stále platné. Může také být možné, že zpracování události už není nutné kvůli aktuálnosti dat nebo logice, která událost zneplatňuje.

  • Události návrhu pro idempotenci: Poskytnutím dalších informací v datové části události je možné zajistit, aby zpracování několikrát nemělo škodlivé účinky. Podívejte se na příklad události, která zahrnuje částku na výběr z bankovního účtu. Pokud se nezpracuje zodpovědně, je možné, že by mohl zůstatek účtu vícekrát zvýšit. Pokud ale stejná událost zahrnuje aktualizovaný zůstatek na účet, můžete ho použít k provedení operace upsertu na zůstatek bankovního účtu. Tento přístup k přenosu stavu přenášený událostmi občas vyžaduje koordinaci mezi producenty a spotřebiteli a měl by být použit, pokud dává smysl pro zúčastněné služby.

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. U řešení streamování událostí je potřeba zajistit správnou podporu zpracování chyb, protože tisíce událostí se můžou rychle změnit na stejný počet chyb, pokud se nezpracují správně.

Pokyny pro zpracování chyb

Bez zpracování chyb může být složité implementovat opakování, zjišťovat výjimky za běhu a zkoumat problémy. Každá funkce by měla mít alespoň určitou úroveň nebo zpracování chyb. Několik doporučených pokynů:

  • Použití Application Insights: Povolení a použití Application Insights k protokolování chyb a monitorování stavu vašich funkcí Mějte na paměti konfigurovatelné možnosti vzorkování pro scénáře, které zpracovávají velký objem událostí.

  • Přidání strukturovaného zpracování chyb: Použijte příslušné konstrukty zpracování chyb pro každý programovací jazyk pro 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#, Java a JavaScript a využijte možnosti try a kromě bloků v Pythonu ke zpracování výjimek.

  • Protokolování: Zachytávání výjimky během provádění poskytuje příležitost k protokolování důležitých informací, které je možné použít ke spolehlivému zjišťování, reprodukování a odstraňování problémů. Protokolujte výjimku, nejen zprávu, ale text, vnitřní výjimku a další užitečné artefakty, které jsou užitečné později.

  • Nezachycujte a ignorujte výjimky: Jednou z nejhorších věcí, které můžete udělat, je zachytit výjimku a s ní nic dělat. Pokud zachytíte obecnou výjimku, někam ji za protokolujte. Pokud chyby protokolujete, je obtížné prozkoumat 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čtu opakování a exponenciálních strategií zpětného ukončení je jen pár aspektů, které to ztěžují. Služba Functions naštěstí poskytuje zásady opakování, které můžou usnadnit mnoho z těchto úloh, které byste obvykle kódovaly sami.

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

  • Vyhněte se nekonečným opakovaným pokusům: Pokud je nastavení maximálního počtu opakování nastaveno na hodnotu -1, bude funkce opakovat po neomezenou dobu. Obecně platí, že neomezené opakování by se mělo používat střídmě s funkcemi a téměř nikdy s vazbou triggeru centra událostí.

  • Zvolte odpovídající strategii opakování: Strategie s pevným zpožděním může být optimální pro scénáře, které přijímají zpětný tlak od 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 došlo u těchto služeb. Exponenciální zpětná strategie 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 zachovat interval opakování kratší než jednu minutu. Ponechte také maximální počet pokusů o opakování na přiměřeně nízké číslo. Tato nastavení jsou obzvláště relevantní při spuštění v plánu Consumption služby Functions.

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

Důležitým aspektem zásad opakování ve službě Functions je to, že se jedná o funkci nejlepšího úsilí pro opětovné zpracování událostí. Nenahrazuje potřebu zpracování chyb, protokolování a dalších důležitých vzorů, které zajišťují odolnost kódu.

Strategie selhání a poškozených dat

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

  • Ukončení odesílání a čtení: Pokud chcete opravit základní problém, pozastavte čtení a zápis událostí. Výhodou tohoto přístupu je, že se data neztratí a operace se můžou po jeho vytvoření obnovit. Tento přístup může vyžadovat komponentu 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ýchpřípadechch

  • Vyřaďte zprávy: Pokud zprávy nejsou důležité nebo jsou považovány za důležité, zvažte přechod na další a nezpracovávat je. Tento přístup nefunguje ve scénářích, které vyžadují silnou konzistenci, jako je záznam přesunů v šachové shodě nebo finanční transakce. Pro zachytávání a zahazování zpráv, které nejde zpracovat, se doporučuje zpracování chyb uvnitř funkce.

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

  • Nedoručené dopisy: Cílem je publikovat událost do jiného centra událostí, aby se stávající tok nepřerušil. Vnímání spočívá v tom, že se přesune z horké cesty a může být řešen později nebo jiným procesem. Toto řešení se často používá ke zpracování otrávených zpráv nebo událostí. Každá funkce nakonfigurovaná s jinou skupinou příjemců stále narazí na špatná nebo poškozená data ve svém datovém proudu a musí je zpracovat zodpovědně.

  • Opakování a nedoručených písmen: Kombinace mnoha opakovaných pokusů před konečným publikováním do datového proudu nedoručených písmen po splnění prahové hodnoty je další známá metoda.

  • Použít registr schématu: Registr schématu lze použít jako proaktivní nástroj, který pomáhá zlepšit konzistenci a kvalitu dat. Azure Schema Registry podporuje přechod schémat spolu s režimy správy verzí a různými režimy kompatibility při vývoji schémat. Schéma v podstatě slouží jako smlouva 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.

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

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

Než budete pokračovat, zvažte kontrolu těchto souvisejících článků:

Zabezpečení

Bezserverové zpracování událostí je referenční architektura podrobně popisující typickou architekturu tohoto typu s ukázkami kódu a diskuzí o důležitých aspektech.