Event Hubs integreren met serverloze functies in Azure

Oplossingen die Gebruikmaken van Azure Event Hubs in combinatie met Azure Functions, profiteren van een serverloze architectuur die schaalbaar, rendabel en in bijna realtime grote hoeveelheden gegevens kan verwerken. Net zoals deze services naadloos samenwerken, zijn er veel functies, instellingen en complexiteiten die hun relatie complexer maken. Dit artikel bevat richtlijnen voor het effectief benutten van deze integratie door belangrijke overwegingen en technieken voor prestaties, tolerantie, beveiliging, waarneembaarheid en schaal aan te geven.

Basisconcepten van Event Hubs

Azure Event Hubs is een uiterst schaalbare service voor gebeurtenisverwerking die miljoenen gebeurtenissen per seconde kan ontvangen. Voordat u ingaat op de patronen en aanbevolen procedures voor Azure Functions-integratie, is het raadzaam om inzicht te hebben in de fundamentele onderdelen van Event Hubs.

In het volgende diagram ziet u de gebeurtenishubs-stroomverwerkingsarchitectuur:

gebeurtenis

Een gebeurtenis is een melding of statuswijziging die wordt weergegeven als een feit dat zich in het verleden heeft voorgedaan. Gebeurtenissen zijn onveranderbaar en persistent in een Event Hub, ook wel een onderwerp genoemd in Kafka. Een Event Hub bestaat uit een of meer partities.

Partities

Wanneer een partitie niet wordt opgegeven door de afzender, worden ontvangen gebeurtenissen verdeeld over partities in de Event Hub. Elke gebeurtenis wordt in precies één partitie geschreven en is niet multicast over partities. Elke partitie werkt als een logboek waarin records worden geschreven in een patroon dat alleen toevoegt. De analogie van een doorvoerlogboek wordt vaak gebruikt om de aard te beschrijven van hoe gebeurtenissen worden toegevoegd aan het einde van een reeks in een partitie.

Wanneer meer dan één partitie wordt gebruikt, kunnen parallelle logboeken worden gebruikt vanuit dezelfde Event Hub. Dit gedrag biedt meerdere mate van parallelle uitvoering en verbetert de doorvoer voor consumenten.

Consumenten en consumentengroepen

Een partitie kan worden gebruikt door meer dan één consument, elk lezen van en het beheren van hun eigen offsets.

Event Hubs heeft het concept van consumentengroepen, waarmee meerdere verbruikende toepassingen elk een afzonderlijke weergave van de gebeurtenisstroom hebben en de stream onafhankelijk in hun eigen tempo en met hun eigen offsets kunnen lezen.

Zie voor meer informatie de concepten en functies van Event Hubs.

Gebeurtenissen gebruiken met Azure Functions

Azure Functions ondersteunt trigger - en uitvoerbindingen voor Event Hubs. In deze sectie wordt beschreven hoe Azure Functions reageert op gebeurtenissen die zijn verzonden naar een Event Hub-gebeurtenisstroom met behulp van triggers.

Elk exemplaar van een door Event Hubs geactiveerde functie wordt ondersteund door één EventProcessorHost-exemplaar . De trigger (verzorgd door Event Hubs) zorgt ervoor dat slechts één EventProcessorHost-exemplaar een lease kan krijgen op een bepaalde partitie.

Denk bijvoorbeeld aan een Event Hub met de volgende kenmerken:

• 10 partities.
• 1000 gebeurtenissen verdeeld over alle partities, met een verschillend aantal berichten in elke partitie.

Wanneer uw functie voor het eerst is ingeschakeld, is er slechts één exemplaar van de functie. We noemen het eerste functie-exemplaar Function_1. Function_1 heeft één exemplaar van EventProcessorHost dat een lease op alle 10 partities bevat. Dit exemplaar leest gebeurtenissen uit partities 1-10. Vanaf dit punt gebeurt een van de volgende dingen:

• Er zijn geen nieuwe functie-exemplaren nodig: Function_1 kan alle 1000 gebeurtenissen verwerken voordat de functieschaallogica van kracht wordt. In dit geval worden alle 1.000 berichten verwerkt door Function_1.

  

• Er wordt een extra functie-exemplaar toegevoegd: op gebeurtenissen gebaseerde schaalaanpassing of andere geautomatiseerde of handmatige logica kan bepalen dat Function_1 er meer berichten zijn dan kan worden verwerkt en vervolgens een nieuw exemplaar van de functie-app (Function_2) wordt gemaakt. Deze nieuwe functie heeft ook een gekoppeld exemplaar van EventProcessorHost. Naarmate de onderliggende Event Hub detecteert dat een nieuw hostexemplaren berichten probeert te lezen, worden de partities verdeeld over de hostinstanties. Partities 1-5 kunnen bijvoorbeeld worden toegewezen Function_1 aan en partities 6-10 aan Function_2.

  

• N meer functie-exemplaren worden toegevoegd: op gebeurtenissen gebaseerde schaalaanpassing of andere geautomatiseerde of handmatige logica bepaalt dat zowel Function_1 als Function_2 meer berichten bevatten dan ze kunnen verwerken, nieuwe Function_N functie-app-exemplaren worden gemaakt. Exemplaren worden gemaakt tot het punt waarop N gelijk is aan of groter is dan het aantal Event Hub-partities. In ons voorbeeld verdeelt Event Hubs de partities opnieuw, in dit geval over de exemplaren Function_1...Function_10.

  

Wanneer het schalen plaatsvindt, kunnen N-exemplaren een getal groter zijn dan het aantal Event Hub-partities. Deze situatie kan optreden wanneer gebeurtenisgestuurd schalen het aantal exemplaren stabiliseren of omdat andere geautomatiseerde of handmatige logica meer exemplaren heeft gemaakt dan partities. In dit geval krijgen EventProcessorHost-exemplaren alleen vergrendelingen op partities zodra ze beschikbaar komen van andere exemplaren, omdat op elk moment slechts één functie-exemplaar van dezelfde consumentengroep toegang heeft tot/lezen vanuit de partities waarop deze is vergrendeld.

Wanneer alle uitvoering van de functie is voltooid (met of zonder fouten), worden controlepunten doorgevoerd in het gekoppelde opslagaccount. Wanneer het controlepunt slaagt, is de functie klaar om een nieuwe batch gebeurtenissen te verwerken.

Dynamisch schalen op basis van gebeurtenissen is mogelijk met de abonnementen Consumption, Flex Consumption en Premium Azure. Door Kubernetes gehoste functie-apps kunnen ook gebruikmaken van de KEDA-schaalfunctie voor Event Hubs. Schalen op basis van gebeurtenissen is momenteel niet mogelijk wanneer de functie-app wordt gehost in een Toegewezen (App Service)-plan. Hiervoor moet u het juiste aantal exemplaren bepalen op basis van uw workload.

Zie Azure Event Hubs-bindingen voor Azure Functions en Azure Event Hubs-trigger voor Azure Functions voor meer informatie.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

• David Barkol | Principal Solution Specialist GBB

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Gerelateerde resource

Serverloze gebeurtenisverwerking is een referentiearchitectuur met een typische architectuur van dit type, met codevoorbeelden en bespreking van belangrijke overwegingen.