Federace více lokalit a více oblastí
Řada sofistikovaných řešení vyžaduje, aby byly stejné streamy událostí dostupné pro spotřebu ve více umístěních, nebo vyžadují shromažďování datových proudů událostí ve více umístěních a jejich sloučení do konkrétního umístění pro spotřebu. Často je také potřeba rozšířit nebo omezit streamy událostí nebo provádět převody formátu událostí, a to i v rámci jedné oblasti a řešení.
Prakticky to znamená, že vaše řešení bude udržovat více služeb Event Hubs, často v různých oblastech a oborech názvů služby Event Hubs a pak mezi nimi replikovat události. Události můžete také vyměňovat se zdroji a cíli, jako jsou Azure Service Bus, Azure IoT Hub nebo Apache Kafka.
Udržování více aktivních služeb Event Hubs v různých oblastech také umožňuje klientům zvolit a přepínat mezi nimi, pokud se jejich obsah slučuje, což ztěžuje celkový systém odolnější vůči problémům s regionální dostupností.
Tato kapitola Federace vysvětluje vzory federace a způsob, jak tyto vzory realizovat pomocí bezserverových modulů runtime Azure Stream Analytics nebo Azure Functions s možností vlastní transformace nebo rozšiřování kódu přímo v cestě toku událostí.
Vzory federace
Existuje mnoho potenciálních motivací, proč můžete chtít přesouvat události mezi různými službami Event Hubs nebo jinými zdroji a cíli, a my v této části vypíšeme nejdůležitější vzory a také propojíme podrobnější pokyny pro příslušný vzor.
- Odolnost proti událostem regionální dostupnosti
- Optimalizace latence
- Ověřování, redukce a rozšiřování
- Integrace s analytickými službami
- Konsolidace a normalizace datových proudů událostí
- Rozdělení a směrování datových proudů událostí
- Projekce protokolů
Odolnost proti událostem regionální dostupnosti
I když maximální dostupnost a spolehlivost představují hlavní provozní priority pro službu Event Hubs, existuje mnoho způsobů, jak může producent nebo příjemce zabránit v komunikaci s přiřazenou "primární" službou Event Hubs kvůli problémům se sítí nebo řešením názvů nebo v případě, že služba Event Hubs může skutečně dočasně nereagovat nebo vracet chyby.
Takové podmínky nejsou "katastrofální" tak, že budete chtít úplně opustit regionální nasazení, protože byste to mohli udělat v situaci zotavení po havárii, ale obchodní scénář některých aplikací už může mít vliv na události dostupnosti, které trvají déle než několik minut nebo dokonce sekund.
Existují dva základní vzory pro řešení takových scénářů:
- Vzor replikace spočívá v replikaci obsahu primární služby Event Hubs do sekundární služby Event Hubs, kdy primární služba Event Hubs obvykle používá aplikaci pro generování i využívání událostí a sekundární služba slouží jako záložní možnost pro případ, že primární služba Event Hubs nebude dostupná. Vzhledem k tomu, že replikace je jednosměrná, od primárního k sekundárnímu, přechod výrobců i příjemců z nedostupného primárního na sekundární způsobí, že původní primární server už nebude přijímat nové události, a proto už nebude aktuální. Čistá replikace je proto vhodná pouze pro scénáře jednosměrného převzetí služeb při selhání. Po provedení převzetí služeb při selhání se původní primární server opustí a v jiné cílové oblasti je potřeba vytvořit novou sekundární službu Event Hubs.
- Vzor sloučení rozšiřuje model replikace provedením průběžného sloučení obsahu dvou nebo více center událostí. Každá událost původně vytvořená v jednom ze služeb Event Hubs zahrnutých v schématu se replikuje do ostatních center událostí. Vzhledem k tomu, že se události replikují, jsou opatřeny poznámkami tak, že se následně ignorují procesem replikace cíle replikace. Výsledkem použití vzoru sloučení jsou dvě nebo více center událostí, které budou obsahovat stejnou sadu událostí nakonec konzistentním způsobem.
V obou případech nebude obsah služby Event Hubs stejný. Události od libovolného producenta a seskupené stejným klíčem oddílu se zobrazí ve stejném relativním pořadí jako původně odeslané, ale absolutní pořadí událostí se může lišit. To platí zejména pro scénáře, kdy se počet oddílů zdrojového a cílového centra událostí liší, což je žádoucí pro několik rozšířených vzorů popsaných zde. Rozdělovač nebo směrovač může získat řez mnohem větší služby Event Hubs se stovkami oddílů a trychtýřovým trychtýřem do menších center událostí s pouhými několika oddíly, které jsou vhodnější pro zpracování podmnožinu s omezenými prostředky zpracování. Naopak sloučení může trychtýřovat data z několika menších služeb Event Hubs do jediného, většího centra událostí s více oddíly, aby se dokázala vypořádat s konsolidovanou propustností a požadavky na zpracování.
Kritériem pro udržování událostí je klíč oddílu, nikoli původní ID oddílu. Další důležité informace o relativním pořadí a o tom, jak provést převzetí služeb při selhání z jedné služby Event Hubs na další, aniž byste se museli spoléhat na stejný rozsah posunů datových proudů, je popsán v popisu vzoru replikace .
Pokyny:
Optimalizace latence
Streamy událostí jsou napsány jednou producenty, ale mohou být přečteny libovolný počet příjemců událostí. Ve scénářích, kdy datový proud událostí v oblasti sdílí více příjemců a je potřeba k němu opakovaně přistupovat během zpracování analýz umístěných v jiné oblasti nebo v rámci požadavků, které by zahlcely souběžné příjemce, může být výhodné umístit kopii datového proudu událostí poblíž procesoru analýzy, aby se snížila latence odezvy.
Dobrými příklady, kdy je vhodné upřednostňovat replikaci před využíváním událostí vzdáleně od různých oblastí, jsou zvlášť ty, kde jsou oblasti extrémně daleko, například Evropa a Austrálie, které jsou téměř antipody, geograficky a latence sítě mohou snadno překročit 250 ms pro jakoukoli zpáteční cestu. Rychlost světla nemůžete zrychlit, ale můžete snížit počet jízd s vysokou latencí při interakci s daty.
Pokyny:
Ověřování, redukce a rozšiřování
Streamy událostí mohou být odesílány do služby Event Hubs klienty, kteří jsou externí pro vaše vlastní řešení. Takové streamy událostí mohou vyžadovat, aby externě odeslané události byly kontrolovány v souladu s daným schématem a aby se události nedodržovaly předpisy.
Ve scénářích, kdy jsou klienti extrémně omezeni šířkou pásma, protože se jedná o případ mnoha scénářů "Internetu věcí" s měřenou šířkou pásma nebo kdy se události původně posílají přes sítě bez IP adres s omezenými velikostmi paketů, je možné, že události budou muset rozšířit o referenční data, aby bylo možné přidat další kontext pro použití podřízenými procesory událostí.
V jiných případech, zejména při slučování datových proudů, může být nutné snížit složitost dat událostí nebo jejich velikost vynecháním některých podrobností.
K některé z těchto operací může dojít jako součást replikace, konsolidace nebo slučovacích toků.
Pokyny:
Integrace s analytickými službami
Několik analytických služeb nativních pro cloud v Azure, jako je Azure Stream Analytics nebo Azure Synapse, funguje nejlépe se streamovanými nebo předem dávkovanými daty obsluhovanými z Azure Event Hubs a Azure Event Hubs také umožňuje integraci s několika opensourcovými analytickými balíčky, jako jsou Apache Samza, Apache Flink, Apache Spark a Apache Storm.
Pokud vaše řešení primárně používá Service Bus nebo Event Grid, můžete tyto události snadno zpřístupnit takovým analytickým systémům a také pro archivaci pomocí event Hubs Capture, pokud je trychtýřujete do služby Event Hubs. Event Grid to může provést nativně s integrací služby Event Hubs pro Service Bus podle pokynů k replikaci služby Service Bus.
Azure Stream Analytics se integruje přímo se službou Event Hubs.
Pokyny:
Konsolidace a normalizace datových proudů událostí
Globální řešení se často skládají z regionálních stop, které jsou z velké části nezávislé, včetně vlastních analytických schopností, ale perspektivy nadnárodních a globálních analýz budou vyžadovat integrovanou perspektivu a proto centrální konsolidace stejných datových proudů událostí, které se vyhodnocují v příslušných regionálních stopách pro místní perspektivu.
Normalizace je příchuť scénáře konsolidace, kdy dva nebo více příchozích datových proudů událostí nese stejný druh událostí, ale s různými strukturami nebo různými kódováními a události, které se před jejich použitím překódují nebo transformují.
Normalizace může také zahrnovat kryptografickou práci, jako je dešifrování komplexních šifrovaných datových částí a jejich opětovné šifrování pomocí různých klíčů a algoritmů pro cílovou skupinu příjemců podřízeného příjemce.
Pokyny:
Rozdělení a směrování datových proudů událostí
Služba Azure Event Hubs se občas používá ve scénářích ve stylu publikování a odběru, kdy příchozí příval ingestovaných událostí daleko překračuje kapacitu služby Azure Service Bus nebo Azure Event Gridu, z nichž obě mají nativní filtrování odběrů publikování a distribuci a jsou upřednostňované pro tento model.
I když možnost publikování a odběru skutečně ponechá předplatitelům možnost vybrat požadované události, rozdělovací model má události producenta mapovat na oddíly podle předem určeného distribučního modelu a určených příjemců pak výhradně přetahuje ze svého oddílu. Když služba Event Hubs ukládá celkový provoz do vyrovnávací paměti, obsah konkrétního oddílu představující zlomek původního svazku propustnosti se pak může replikovat do fronty pro spolehlivou, transakční a konkurenční spotřebu příjemců.
Řada scénářů, kdy se služba Event Hubs primárně používá k přesouvání událostí v rámci aplikace v rámci oblasti, mají některé případy, kdy je potřeba vybrat události, třeba jenom z jednoho oddílu, zpřístupnit i jinde. Tento scénář je podobný situaci rozdělení, ale může použít škálovatelný směrovač, který bere v úvahu všechny zprávy přicházející do služby Event Hubs a pár vybraných možností pro další směrování a může rozlišovat cíle směrování podle metadat událostí nebo obsahu.
Pokyny:
Projekce protokolů
V některých scénářích budete chtít mít přístup k nejnovější hodnotě odeslané pro jakýkoli podstream události a běžně se odlišují klíčem oddílu. V Apache Kafka se toho často dosahuje povolením "komprimace protokolů" v tématu, které zahodí všechny události s popiskem všechny kromě nejnovější události označené libovolným jedinečným klíčem. Přístup ke komprimování protokolů má tři nevýhody složeného souboru:
- Komprimace vyžaduje nepřetržitou reorganizaci protokolu, což je nadměrně náročná operace pro zprostředkovatele optimalizovaného pro úlohy jen pro připojení.
- Komprimace je destruktivní a neumožňuje kompaktní a nekomprimovanou perspektivu stejného proudu.
- Komprimovaný datový proud má stále model sekvenčního přístupu, což znamená, že nalezení požadované hodnoty v protokolu vyžaduje čtení celého protokolu v nejhorším případě, což obvykle vede k optimalizacím, které implementují přesný vzor uvedený zde: promítání obsahu protokolu do databáze nebo mezipaměti.
Komprimovaný protokol je nakonec úložiště klíč-hodnota, a proto je to nejhorší možná možnost implementace pro takové úložiště. Pro vyhledávání a dotazy je mnohem efektivnější vytvořit a použít trvalou projekci protokolu do správného úložiště klíč-hodnota nebo jiné databáze.
Vzhledem k tomu, že události jsou neměnné a pořadí je vždy zachováno v protokolu, jakákoli projekce protokolu do úložiště klíč-hodnota bude vždy stejná pro stejný rozsah událostí, což znamená, že projekce, kterou udržujete aktualizované, vždy poskytuje autoritativní zobrazení a nikdy neexistuje žádný dobrý důvod k jeho opětovnému sestavení z obsahu protokolu po sestavení.
Pokyny:
Technologie replikace aplikací
Implementace výše uvedených vzorů vyžaduje škálovatelné a spolehlivé spouštěcí prostředí pro úlohy replikace, které chcete nakonfigurovat a spustit. V Azure jsou prostředí runtime, která jsou pro takové úlohy nejvhodnější, bezstavové úlohy jsou Azure Stream Analytics pro úlohy replikace stavových proudů a Azure Functions pro úlohy bezstavové replikace.
Stavové aplikace replikace ve službě Azure Stream Analytics
Pro stavové aplikace replikace, které potřebují zvážit vztahy mezi událostmi, vytváření složených událostí, rozšiřování událostí nebo redukce událostí, vytváření agregací dat a transformace datových částí událostí, je nejlepší možností implementace Azure Stream Analytics .
V Azure Stream Analytics vytvoříte úlohy, které integrují vstupy a výstupy a integrují data ze vstupů prostřednictvím dotazů, které poskytují výsledek, který se pak zpřístupní na výstupech.
Dotazy jsou založené na dotazovacím jazyku SQL a dají se použít k snadnému filtrování, řazení, agregaci a spojení streamovaných dat v určitém časovém období. Tento jazyk SQL můžete rozšířit také pomocí funkcí definovaných uživatelem v Jazyce JavaScript a C#. Možnosti řazení událostí a dobu trvání časových intervalů můžete snadno upravit při provádění agregačních operací prostřednictvím jednoduchých konstruktorů jazyka a/nebo konfigurací.
Každá úloha má jeden nebo několik výstupů pro transformovaná data a můžete řídit, co se stane v reakci na informace, které jste analyzovali. Je například možné:
- Odesílání dat do služeb, jako jsou Azure Functions, témata služby Service Bus nebo fronty, aby se aktivovala komunikace nebo vlastní pracovní postupy podřízené.
- Odeslání dat na řídicí panel Power BI pro řídicí panel v reálném čase
- Data můžete ukládat do jiných služeb úložiště Azure (například Azure Data Lake, Azure Synapse Analytics atd.), abyste mohli provádět dávkové analýzy nebo trénovat modely strojového učení na základě velmi velkých indexovaných fondů historických dat.
- Ukládejte projekce (označované také jako materializovaná zobrazení) v databázích (SQL Database, Azure Cosmos DB).
Bezstavové aplikace replikace ve službě Azure Functions
V případě úloh bezstavové replikace, ve kterých chcete předávat události bez ohledu na jejich datové části nebo je zpracovává ingálně, aniž byste museli brát v úvahu vztahy událostí (s výjimkou jejich relativního pořadí), můžete použít Azure Functions, což poskytuje obrovskou flexibilitu.
Azure Functions má předem připravené, škálovatelné triggery a výstupní vazby pro Azure Event Hubs, Azure IoT Hub, Azure Service Bus, Azure Event Grid a Azure Queue Storage a také vlastní rozšíření pro RabbitMQ a Apache Kafka. Většina triggerů se dynamicky přizpůsobí potřebám propustnosti škálováním počtu souběžně spuštěných instancí nahoru a dolů na základě zdokumentovaných metrik.
Pro vytváření projekcí protokolu podporuje Azure Functions výstupní vazby pro Azure Cosmos DB a Azure Table Storage.
Služba Azure Functions může běžet pod spravovanou identitou Azure a s tím může obsahovat konfigurační hodnoty přihlašovacích údajů v úzce řízeném úložišti s přístupem ve službě Azure Key Vault.
Azure Functions navíc umožňuje úlohy replikace přímo integrovat s virtuálními sítěmi Azure a koncovými body služeb pro všechny služby zasílání zpráv Azure a je snadno integrována se službou Azure Monitor.
S plánem consumption služby Azure Functions můžou předem připravené triggery dokonce vertikálně snížit kapacitu na nulu, zatímco pro replikaci nejsou k dispozici žádné zprávy, což znamená, že vám nebudou účtovány žádné náklady na udržování konfigurace připravené na vertikální navýšení kapacity. Klíčovou nevýhodou použití plánu consumption je, že latence úloh replikace se z tohoto stavu "probouzí" výrazně vyšší než u plánů hostování, ve kterých je infrastruktura stále spuštěná.
Na rozdíl od všech těchto nejběžnějších replikovacích modulů pro zasílání zpráv a událostí, jako je zrcadlení Apache Kafka, vyžadují, abyste poskytli hostitelské prostředí a škálujte replikační modul sami. To zahrnuje konfiguraci a integraci funkcí zabezpečení a sítí a usnadnění toku dat monitorování a pak ještě nemáte možnost vkládat do toku vlastní úlohy replikace.
Volba mezi Službami Azure Functions a Azure Stream Analytics
Azure Stream Analytics (ASA) je nejlepší volbou vždy, když potřebujete zpracovat datovou část událostí při jejich replikaci. ASA může události kopírovat po jednom nebo může vytvořit agregace, které před předáním zkondenzují informace o datových proudech událostí. Může se snadno spoléhat na doplnění referenčních dat uložených ve službě Azure Blob Storage nebo Azure SQL Database, aniž byste je museli importovat do datového proudu.
Pomocí ASA můžete snadno vytvářet trvalá materializovaná zobrazení datových proudů v databázích s hyper-škálováním. Jedná se o daleko nadřazený přístup k modelu komprimace protokolů Apache Kafka a volatilních projekcí tabulek na straně klienta streamů Kafka.
ASA dokáže snadno zpracovávat události s datovými částmi kódovanými ve formátech CSV, JSON a Apache Avro a můžete je připojit k vlastním deserializerům pro jakýkoli jiný formát.
Pro všechny úlohy replikace, ve kterých chcete kopírovat datové proudy "tak, jak je" a bez zásahu do datových částí, nebo pokud potřebujete implementovat směrovač, provádět kryptografickou práci, měnit kódování datových částí nebo pokud jinak potřebujete úplnou kontrolu nad obsahem datového proudu, je nejlepší volbou Azure Functions.
Další kroky
V tomto článku jsme prozkoumali řadu vzorů federace a vysvětlili jsme roli Azure Functions jako modulu runtime replikace událostí a zasílání zpráv v Azure.
Dále si můžete přečíst, jak nastavit aplikaci replikátoru pomocí Azure Stream Analytics nebo Azure Functions a jak pak replikovat toky událostí mezi Event Hubs a různými dalšími systémy událostí a zasílání zpráv: