Perspektiva architektury s dobře navrženou architekturou Azure ve službě Azure Event Hubs
Azure Event Hubs je škálovatelná služba zpracování událostí, která ingestuje a zpracovává velké objemy událostí a dat s nízkou latencí a vysokou spolehlivostí. Dokáže přijímat a zpracovávat miliony událostí za sekundu. Data odesílaná do centra událostí je možné transformovat a ukládat pomocí libovolného poskytovatele analýz v reálném čase nebo adaptérů dávkování a úložiště.
Další informace o používání služby Event Hubs najdete v dokumentaci ke službě Azure Event Hubs a zjistěte, jak pomocí služby Event Hubs ingestovat miliony událostí za sekundu z připojených zařízení a aplikací.
Pokud chcete porozumět způsobům používání služby Event Hubs, pomůže vám dosáhnout efektivity provozu a spolehlivosti pro vaše úlohy, projděte si následující články:
- Monitorování služby Azure Event Hubs
- Streamování dat Diagnostiky Azure pomocí Event Hubs
- Škálování pomocí služby Event Hubs
Následující části jsou specifické pro službu Azure Event Hubs z hlediska dobře architektuře:
- Aspekty návrhu
- Kontrolní seznam konfigurace
- Doporučené možnosti konfigurace
- Zdrojové artefakty
Aspekty návrhu
Azure Event Hubs poskytuje smlouvu SLA pro dobu provozu. Další informace najdete ve sla pro službu Event Hubs.
Kontrolní seznam
Nakonfigurovali jste službu Azure Event Hubs s ohledem na efektivitu provozu?
- Vytvořte zásady SendOnly a ListenOnly pro vydavatele a příjemce události.
- Při použití sady SDK k odesílání událostí do služby Event Hubs se ujistěte, že jsou správně zachyceny výjimky vyvolané zásadami opakování (
EventHubsException
neboOperationCancelledException
). - Ve scénářích s vysokou propustností používejte dávkové události.
- Každý příjemce může číst události z jednoho do maximálního počtu oddílů podporovaných skladovou jednotkou Event Hubs .
- Při vývoji nových aplikací používejte
EventProcessorClient
(.NET a Java) neboEventHubConsumerClient
(Python a JavaScript) jako klientskou sadu SDK. - Jako součást strategie dostupnosti a zotavení po havárii pro celé řešení zvažte povolení možnosti geografického zotavení po havárii služby Event Hubs.
- Pokud má řešení velký počet nezávislých vydavatelů událostí, zvažte použití Event Publishers pro jemně odstupňované řízení přístupu.
- Nepublikujte události do určitého oddílu.
- Při častém publikování událostí používejte protokol AMQP, pokud je to možné.
- Početoddílůch
- Zajistěte, aby každá aplikace používala samostatnou skupinu příjemců a je na místě pouze jeden aktivní příjemce na skupinu příjemců.
- Při použití funkce Capture pečlivě zvažte konfiguraci časového intervalu a velikosti souboru, zejména u malých objemů událostí.
Doporučení pro konfiguraci
Při konfiguraci služby Azure Event Hubs zvažte následující doporučení k optimalizaci spolehlivosti:
Doporučení | Popis |
---|---|
Při použití sady SDK k odesílání událostí do služby Event Hubs se ujistěte, že jsou správně zachyceny výjimky vyvolané zásadami opakování (EventHubsException nebo OperationCancelledException ). |
Při použití HTTPS se ujistěte, že je implementovaný správný vzor opakování. |
Ve scénářích s vysokou propustností používejte dávkové události. | Služba doručí json pole s více událostmi odběratelům místo pole s jednou událostí. Spotřebová aplikace musí tato pole zpracovat. |
Každý příjemce může číst události z jednoho do maximálního počtu oddílů podporovaných skladovou jednotkou služby Event Hubs. | Aby bylo dosaženo maximálního škálování na straně spotřebovávající aplikace, měl by každý příjemce číst z jednoho oddílu. |
Při vývoji nových aplikací používejte EventProcessorClient (.NET a Java) nebo EventHubConsumerClient (Python a JavaScript) jako klientskou sadu SDK. |
EventProcessorHost už je zastaralý. |
Jako součást strategie dostupnosti a zotavení po havárii pro celé řešení zvažte povolení možnosti geografického zotavení po havárii služby Event Hubs. | Tato možnost umožňuje vytvoření sekundárního oboru názvů v jiné oblasti. Zprávy obdrží kdykoli pouze aktivní obor názvů. Zprávy a události se nereplikují do sekundární oblasti. RtO pro regionální převzetí služeb při selhání je až 30 minut. Ověřte, že tato RTO odpovídá požadavkům zákazníka a vyhovuje širší strategii dostupnosti. Pokud je vyžadováno vyšší RTO, zvažte implementaci modelu převzetí služeb při selhání na straně klienta. |
Pokud má řešení velký počet nezávislých vydavatelů událostí, zvažte použití Event Publishers pro jemně odstupňované řízení přístupu. | Služba Event Publishers automaticky nastaví klíč oddílu na název vydavatele, takže tato funkce by měla být použita pouze v případě, že události pocházejí od všech vydavatelů rovnoměrně. |
Nepublikujte události do určitého oddílu. | Pokud jsou události objednávání nezbytné, implementujte řazení podřízeného procesu nebo místo toho použijte jinou službu zasílání zpráv. |
Při častém publikování událostí používejte protokol AMQP, pokud je to možné. | AMQP má při inicializaci relace vyšší náklady na síť, ale HTTPS vyžaduje režii protokolu TLS pro každý požadavek. AMQP má pro často používané zdroje vyšší výkon. |
Početoddílůch | Pro maximální propustnost použijte při vytváření centra událostí maximální počet oddílů podporovaných skladovou jednotkou. Zvýšení počtu oddílů umožňuje škálovat souběžné entity zpracování tak, aby odpovídaly oddílům a zajistily optimální dostupnost odesílání a příjmu. |
Při použití funkce Capture pečlivě zvažte konfiguraci časového intervalu a velikosti souboru, zejména u malých objemů událostí. | Data Lake Gen2 bude účtovat minimální velikost transakcí. Pokud nastavíte časové okno tak nízké, že soubor nedosáhl minimální velikosti, bude se vám účtují další náklady. |
Zdrojové artefakty
Pokud chcete najít obory názvů služby Event Hubs se skladovou jednotkou Basic , použijte následující dotaz:
Resources
| where type == 'microsoft.eventhub/namespaces'
| where sku.name == 'Basic'
| project resourceGroup, name, sku.name