Azure Well-Architected Framework-perspektiv på Azure Event Hubs
Azure Event Hubs är en skalbar händelsebearbetningstjänst som matar in och bearbetar stora mängder händelser och data, med låg svarstid och hög tillförlitlighet. Den kan ta emot och behandla miljoner händelser per sekund. Data som skickas till en händelsehubb kan omvandlas och lagras med hjälp av valfri realtidsanalysprovider eller batchbearbetning och lagringskort.
Mer information om hur du använder Event Hubs finns i Dokumentationen om Azure Event Hubs för att lära dig hur du använder Event Hubs för att mata in miljontals händelser per sekund från anslutna enheter och program.
Information om hur du använder Event Hubs hjälper dig att uppnå driftskvalitet och tillförlitlighet för din arbetsbelastning finns i följande artiklar:
Följande avsnitt är specifika för Azure Event Hubs ur ett välarkitekterat ramverksperspektiv:
- Utformningsbeaktanden
- Checklista för konfiguration
- Rekommenderade konfigurationsalternativ
- Källartefakter
Utformningsbeaktanden
Azure Event Hubs tillhandahåller ett serviceavtal för drifttid. Mer information finns i SLA för Event Hubs.
Checklista
Har du konfigurerat Azure Event Hubs med driftkvalitet i åtanke?
- Skapa principer för SendOnly respektive ListenOnly för händelseutgivaren respektive konsumenten.
- När du använder SDK:t för att skicka händelser till Event Hubs kontrollerar du att undantagen som genereras av återförsöksprincipen (
EventHubsExceptionellerOperationCancelledException) fångas korrekt. - I scenarier med högt dataflöde använder du batchbaserade händelser.
- Varje konsument kan läsa händelser från en till högsta partitioner som stöds av Event Hubs SKU
- När du utvecklar nya program använder du
EventProcessorClient(.NET och Java) ellerEventHubConsumerClient(Python och JavaScript) som klient-SDK. - Som en del av din lösningsomfattande tillgänglighets- och haveriberedskapsstrategi bör du överväga att aktivera event hubs geo-haveriberedskapsalternativet.
- När en lösning har ett stort antal oberoende händelseutgivare bör du överväga att använda Event Publishers för detaljerad åtkomstkontroll.
- Publicera inte händelser till en specifik partition.
- När du publicerar händelser ofta använder du AMQP-protokollet när det är möjligt.
- Antalet partitioner återspeglar den grad av nedströmsparallellitet som du kan uppnå.
- Se till att varje förbrukande program använder en separat konsumentgrupp och att endast en aktiv mottagare per konsumentgrupp finns på plats.
- När du använder capture-funktionen bör du noga överväga konfigurationen av tidsfönstret och filstorleken, särskilt med låga händelsevolymer.
Konfigurationsrekommendationer
Överväg följande rekommendationer för att optimera tillförlitligheten när du konfigurerar Azure Event Hubs:
| Rekommendation | beskrivning |
|---|---|
När du använder SDK:t för att skicka händelser till Event Hubs kontrollerar du att undantagen som genereras av återförsöksprincipen (EventHubsException eller OperationCancelledException) fångas korrekt. |
När du använder HTTPSkontrollerar du att ett korrekt återförsöksmönster implementeras. |
| I scenarier med högt dataflöde använder du batchbaserade händelser. | Tjänsten levererar en json matris med flera händelser till prenumeranterna i stället för en matris med en händelse. Det förbrukande programmet måste bearbeta dessa matriser. |
| Varje konsument kan läsa händelser från en till högsta partitioner som stöds av Event Hubs SKU. | För att uppnå maximal skalning på sidan av det förbrukande programmet bör varje konsument läsa från en enda partition. |
När du utvecklar nya program använder du EventProcessorClient (.NET och Java) eller EventHubConsumerClient (Python och JavaScript) som klient-SDK. |
EventProcessorHost har blivit inaktuell. |
| Som en del av din lösningsomfattande tillgänglighets- och haveriberedskapsstrategi bör du överväga att aktivera event hubs geo-haveriberedskapsalternativet. | Med det här alternativet kan du skapa ett sekundärt namnområde i en annan region. Endast det aktiva namnområdet tar emot meddelanden när som helst. Meddelanden och händelser replikeras inte till den sekundära regionen. RTO för den regionala redundansväxlingen är upp till 30 minuter. Bekräfta att denna RTO överensstämmer med kundens krav och passar in i den bredare tillgänglighetsstrategin. Om en högre RTO krävs kan du överväga att implementera ett redundansmönster på klientsidan. |
| När en lösning har ett stort antal oberoende händelseutgivare bör du överväga att använda Event Publishers för detaljerad åtkomstkontroll. | Event Publishers anger automatiskt partitionsnyckeln till utgivarens namn, så den här funktionen bör endast användas om händelserna kommer från alla utgivare jämnt. |
| Publicera inte händelser till en specifik partition. | Om det är viktigt att beställa händelser implementerar du beställning nedströms eller använder en annan meddelandetjänst i stället. |
| När du publicerar händelser ofta använder du AMQP-protokollet när det är möjligt. | AMQP har högre nätverkskostnader när sessionen initieras, men HTTPS kräver TLS-omkostnader för varje begäran. AMQP har högre prestanda för frekventa utfärdare. |
| Antalet partitioner återspeglar den grad av nedströmsparallellitet som du kan uppnå. | För maximalt dataflöde använder du det maximala antalet partitioner som stöds av SKU:n när du skapar händelsehubben. Genom att öka antalet partitioner kan du skala samtidiga bearbetningsentiteter så att de matchar partitionerna, vilket säkerställer optimal tillgänglighet för sändning och mottagning. |
| När du använder capture-funktionen bör du noga överväga konfigurationen av tidsfönstret och filstorleken, särskilt med låga händelsevolymer. | Data Lake gen2 debiteras för minimal transaktionsstorlek. Om du ställer in tidsfönstret så lågt att filen inte har nått minsta storlek medför du extra kostnad. |
Källartefakter
Om du vill hitta Event Hubs-namnområden med Basic SKU använder du följande fråga:
Resources
| where type == 'microsoft.eventhub/namespaces'
| where sku.name == 'Basic'
| project resourceGroup, name, sku.name