Integratie Event Hubs met serverloze functies in Azure

Oplossingen die Azure Event Hubs samen met Azure Functions profiteren van een serverloze architectuur die schaalbaar en rendabel is en geschikt is voor het bijna in realtime verwerken van grote hoeveelheden gegevens. Zoveel als deze services naadloos samenwerken, zijn er veel functies, instellingen en complexiteit die de relatie complexer maken. Dit artikel bevat richtlijnen voor het effectief profiteren van deze integratie door belangrijke overwegingen en technieken voor prestaties, tolerantie, beveiliging, waarneembaarheid en schaal te markeren.

Event Hubs belangrijkste concepten

Azure Event Hubs is een uiterst schaalbare service voor gebeurtenisverwerking die miljoenen gebeurtenissen per seconde kan ontvangen. Voordat u in de patronen en best practices voor Azure Functions integratie gaat, is het het beste om inzicht te krijgen in de fundamentele onderdelen van Event Hubs.

In het volgende diagram ziet u de Event Hubs stroomverwerkingsarchitectuur:

Gebeurtenissen

Een gebeurtenis is een melding of statuswijziging die wordt weergegeven als een feit dat in het verleden is gebeurd. Gebeurtenissen zijn onveranderbaar en blijven aanwezig 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 is opgegeven door de afzender, worden ontvangen gebeurtenissen verdeeld over partities in de Event Hub. Elke gebeurtenis wordt in precies één partitie geschreven en wordt niet over meerdere partities gecast. Elke partitie werkt als een logboek waarin records worden geschreven in een patroon dat alleen aan de gegevens is toe te passen. De analogie van een commit-logboek 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 er parallelle logboeken worden gebruikt vanuit dezelfde Event Hub. Dit gedrag biedt meerdere graden parallellisme en verbetert de doorvoer voor consumenten.

Consumenten en consumentengroepen

Een partitie kan worden gebruikt door meer dan één consument, die elk hun eigen offsets leest en beheert.

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

Zie Deep dive on Event Hubs concepts and features (Meer informatie Event Hubs en functies) voor meer informatie.

Gebeurtenissen gebruiken met Azure Functions

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

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

Denk bijvoorbeeld aan een Event Hub met de volgende kenmerken:

• 10 partities.
• 1000 gebeurtenissen verdeelden alle partities gelijkmatig, met een wisselend aantal berichten in elke partitie.

Wanneer uw functie voor het eerst wordt 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:

• Nieuwe functie-exemplaren zijn niet nodig: kan alle 1000 gebeurtenissen verwerken voordat de schaallogica van Function_1 Functions van kracht wordt. In dit geval worden alle 1.000 berichten verwerkt door Function_1.

  

• Er wordt een extra functie-exemplaar toegevoegd: schaalbaarheid op basis van gebeurtenissen of andere geautomatiseerde of handmatige logica kan bepalen dat meer berichten heeft dan kan worden verwerkt en maakt vervolgens een nieuw exemplaar van de functie-app Function_1 ( Function_2 ). Deze nieuwe functie heeft ook een bijbehorend exemplaar van [EventProcessorHost.] Wanneer de onderliggende Event Hub detecteert dat een nieuw host-exemplaar berichten probeert te lezen, worden de partities verdeeld over de host-exemplaren. Partities 1-5 kunnen bijvoorbeeld worden toegewezen aan en Function_1 partities 6-10 aan Function_2 .

  

• Er worden n meer functie-exemplaren toegevoegd: op gebeurtenissen gebaseerde schaalbaarheid of andere geautomatiseerde of handmatige logica bepaalt dat zowel als meer berichten hebben dan ze kunnen verwerken. Er worden nieuwe function Function_1 Function_2 _ N-functie-app-exemplaren gemaakt. Exemplaren worden gemaakt tot het punt waar 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.

  

Als er wordt geschaald, kunnen N exemplaren een getal groter zijn dan het aantal Event Hub-partities. Deze situatie kan zich voordoen wanneer door gebeurtenisgestuurd schalen het aantal exemplaren wordt stabiel, of omdat andere geautomatiseerde of handmatige logica meer exemplaren dan partities heeft gemaakt. In dit geval krijgen [EventProcessorHost-exemplaren] alleen vergrendelingen op partities wanneer ze beschikbaar komen vanuit andere exemplaren, omdat op elk moment slechts één functie-exemplaar van dezelfde consumentengroep toegang heeft tot/kan lezen van de partities die zijn vergrendeld.

Wanneer de uitvoering van alle functies is voltooid (met of zonder fouten), worden controlepunten toegevoegd aan het gekoppelde opslagaccount. Wanneer het toevoegen van controlepunten slaagt, worden alle 1.000 berichten nooit meer opgehaald.

Dynamische schaalbaarheid op basis van gebeurtenissen is mogelijk met Consumption en Premium Azure-abonnementen. In Kubernetes gehoste functie-apps kunnen ook profiteren van de KEDA-scaler voor Event Hubs. Schalen op basis van gebeurtenissen is momenteel niet mogelijk wanneer de functie-app wordt gehost in een Dedicated-abonnement (App Service). Hiervoor moet u het juiste aantal exemplaren bepalen op basis van uw workload.

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

Volgende stappen

Gerelateerde resources

• Bewaking van serverloze gebeurtenisverwerking biedt richtlijnen voor het bewaken van serverloze gebeurtenisgestuurde architecturen.
• Serverloze gebeurtenisverwerking is een referentiearchitectuur waarin een typische architectuur van dit type wordt beschreven, met codevoorbeelden en bespreking van belangrijke overwegingen.
• In Batchverwerking en filteren in serverloze gebeurtenisverwerking met Event Hubs wordt gedetailleerder beschreven hoe deze gedeelten van de referentiearchitectuur werken.