Betrouwbare gebeurtenisverwerking met Azure Functions en Event Hubs

2025-07-02

Meer informatie over het bouwen van robuuste, betrouwbare serverloze oplossingen met behulp van Azure Functions met Azure Event Hubs-triggers. In dit artikel worden aanbevolen procedures beschreven voor controlepunten, foutafhandeling en het implementeren van circuitonderbrekerpatronen om ervoor te zorgen dat er geen gebeurtenissen verloren gaan en uw gebeurtenisgestuurde toepassingen stabiel en tolerant blijven.

Uitdagingen van gebeurtenisstromen in gedistribueerde systemen

Overweeg een systeem waarmee gebeurtenissen met een constante snelheid van 100 gebeurtenissen per seconde worden verzonden. Met deze snelheid kunnen binnen enkele minuten meerdere parallelle exemplaren elke seconde de binnenkomende 100 gebeurtenissen verbruiken.

Houd echter rekening met deze uitdagingen voor het consumeren van een gebeurtenisstroom.

Een event publisher verstuurt een corrupte gebeurtenis.
Uw functiecode ondervindt een niet-verwerkte uitzondering.
Een downstreamsysteem gaat offline en blokkeert de verwerking van gebeurtenissen.

In tegenstelling tot een Azure Queue Storage-trigger, die berichten vergrendelt tijdens de verwerking, leest Azure Event Hubs, per partitie, vanaf één punt in de stream. Dit leesgedrag, dat meer lijkt op een videospeler, biedt de gewenste voordelen van hoge doorvoer, meerdere consumentengroepen en mogelijkheden voor opnieuw afspelen. Gebeurtenissen worden gelezen, vooruit of achteruit, vanaf een controlepunt, maar u moet de aanwijzer verplaatsen om nieuwe gebeurtenissen te verwerken. Zie Controlepunt in de Documentatie van Event Hubs voor meer informatie.

Wanneer er fouten optreden in een stream en u ervoor kiest om de aanwijzer niet door te voeren, wordt verdere verwerking van gebeurtenissen geblokkeerd. Met andere woorden, als u de aanwijzer stopt om een probleem te verwerken dat één gebeurtenis verwerkt, beginnen de niet-verwerkte gebeurtenissen zich op te stapelen.

Functie voorkomt impasses door de aanwijzer van de stream altijd te verplaatsen, ongeacht succes of mislukking. Omdat de aanwijzer steeds verdergaat, moeten uw functies op de juiste wijze omgaan met fouten.

Hoe de Event Hubs-trigger gebeurtenissen verbruikt

Azure Functions gebruikt gebeurtenissen van een Event Hub door de volgende stappen te doorlopen:

Er wordt een aanwijzer gemaakt en persistent gemaakt in Azure Storage voor elke partitie van de Event Hub.
Nieuwe gebeurtenissen worden ontvangen in een batch (standaard) en de host probeert de functie te activeren die een batch met gebeurtenissen levert voor verwerking.
Wanneer de functie is voltooid, met of zonder uitzonderingen, wordt de aanwijzer geavanceerd en wordt een controlepunt opgeslagen in het standaardhostopslagaccount.
Als voorwaarden voorkomen dat de uitvoering van de functie wordt voltooid, kan de host de aanwijzer niet vooruitgaan. Wanneer de aanwijzer niet verder kan gaan, worden dezelfde gebeurtenissen opnieuw verwerkt.

Dit gedrag toont enkele belangrijke punten:

Niet-verwerkte uitzonderingen kunnen ertoe leiden dat u gebeurtenissen kwijtraakt:

Functies die een uitzondering genereren, gaan verder met het verplaatsen van de aanwijzer. Als u een beleid voor opnieuw proberen of andere logica voor opnieuw proberen instelt, wordt de aanwijzer vertraagd totdat het hele opnieuw proberen is voltooid.
Functions garandeert ten minste eenmaal levering:

Uw code en afhankelijke systemen moeten mogelijk rekening houden met het feit dat dezelfde gebeurtenis tweemaal kan worden verwerkt. Zie Azure Functions ontwerpen voor identieke invoer voor meer informatie.

Afhandeling van uitzonderingen

Hoewel alle functiecode een try/catch-blok op het hoogste codeniveau moet bevatten, is het nog belangrijker om een catch blok te hebben voor functies die Event Hubs-gebeurtenissen verbruiken. Wanneer er een uitzondering optreedt, behandelt het catch-blok de fout voordat de pointer verder gaat.

Mechanismen en beleidsregels voor opnieuw proberen

Omdat veel uitzonderingen in de cloud tijdelijk zijn, is de eerste stap in foutafhandeling altijd om de bewerking opnieuw uit te voeren. U kunt ingebouwd beleid voor opnieuw proberen toepassen of uw eigen logica voor opnieuw proberen definiëren.

Beleid opnieuw proberen

Functions biedt ingebouwd beleid voor opnieuw proberen voor Event Hubs. Wanneer u beleid voor opnieuw proberen gebruikt, genereert u gewoon een nieuwe uitzondering en probeert de host de gebeurtenis opnieuw te verwerken op basis van het gedefinieerde beleid. Voor dit gedrag van opnieuw proberen is versie 5.x of later van de Event Hubs-extensie vereist. Zie Beleid voor opnieuw proberen voor meer informatie.

Aangepaste logica voor opnieuw proberen

U kunt ook uw eigen logica voor opnieuw proberen definiëren in de functie zelf. U kunt bijvoorbeeld een beleid implementeren dat volgt op een werkstroom die wordt geïllustreerd door de volgende regels:

Probeer een gebeurtenis drie keer te verwerken (mogelijk met een vertraging tussen nieuwe pogingen).
Als het uiteindelijke resultaat van alle nieuwe pogingen een fout is, voegt u een gebeurtenis toe aan een wachtrij, zodat de verwerking kan doorgaan in de stream.
Beschadigde of niet-verwerkte gebeurtenissen worden later verwerkt.

Opmerking

Polly is een voorbeeld van een tolerantie- en tijdelijke foutafhandelingsbibliotheek voor C#-toepassingen.

Niet-uitzonderingsfouten

Sommige problemen kunnen optreden zonder dat er een uitzondering wordt gegenereerd. Denk bijvoorbeeld aan een geval waarin een aanvraag een time-out krijgt of wanneer de instantie waarop de functie wordt uitgevoerd vastloopt. Wanneer een functie niet kan worden voltooid zonder uitzondering, wordt de offsetaanwijzer nooit geavanceerd. Als de aanwijzer niet verder gaat, blijft een instantie na een mislukte uitvoering dezelfde gebeurtenissen lezen. Deze situatie biedt een garantie van ten minste één keer .

De zekerheid dat elke gebeurtenis ten minste één keer wordt verwerkt, impliceert dat sommige gebeurtenissen meer dan één keer kunnen worden verwerkt. Uw functie-apps moeten zich bewust zijn van deze mogelijkheid en moeten worden gebouwd rond de principes van idempotentie.

Foutstatussen verwerken

Uw app kan mogelijk een aantal fouten in gebeurtenisverwerking acceptabel verwerken. U moet echter ook voorbereid zijn op het afhandelen van de permanente foutstatus, die kan optreden als gevolg van fouten in downstreamverwerking. In een dergelijke foutstatus, zoals wanneer een downstreamgegevensopslag offline is, moet uw functie stoppen met het activeren van gebeurtenissen totdat het systeem in een gezonde toestand is.

Circuitonderbrekerpatroon

Wanneer u het circuitonderbrekerpatroon implementeert, kan uw app de verwerking van gebeurtenissen effectief onderbreken en op een later tijdstip hervatten nadat problemen zijn opgelost.

Er zijn twee onderdelen vereist voor het implementeren van een circuitonderbreker in een gebeurtenisstroomproces:

Gedeelde status voor alle exemplaren om de status van het circuit bij te houden en te bewaken.
Een primair proces dat de circuitstatus kan beheren, als open of closed.

Implementatiedetails kunnen variëren, maar om de status te delen tussen exemplaren hebt u een opslagmechanisme nodig. U kunt de status opslaan in Azure Storage, een Redis-cache of een andere permanente service die toegankelijk is voor uw functie-app-exemplaren.

Durable Functions en Azure Logic Apps bieden infrastructuur voor het beheren van werkstromen en circuitstatussen. In dit artikel wordt beschreven hoe u Logic Apps gebruikt om de uitvoering van functies te onderbreken en opnieuw op te starten, zodat u de controle hebt die nodig is om het circuitonderbrekerpatroon te implementeren.

Een foutendrempel voor alle exemplaren definiëren

Permanente gedeelde externe status is vereist om de status van het circuit te bewaken wanneer meerdere exemplaren gelijktijdig gebeurtenissen verwerken. Vervolgens kunt u deze persistente status bewaken op basis van regels die een foutstatus aangeven, zoals:

Als er meer dan 100 gebeurtenisfouten zijn binnen een periode van 30 seconden bij alle toepassingen, onderbreek dan het circuit om te stoppen met het activeren van nieuwe gebeurtenissen.

De implementatiedetails voor deze bewakingslogica variëren, afhankelijk van uw specifieke app-behoeften, maar in het algemeen moet u een systeem maken dat:

Registreert fouten bij persistente opslag.
Controleer het doorlopend aantal wanneer nieuwe fouten worden geregistreerd om te bepalen of de drempelwaarde voor gebeurtenisfouten wordt bereikt.
Wanneer aan deze drempelwaarde wordt voldaan, verzendt u een gebeurtenis die aangeeft dat het systeem het circuit moet verbreken.

Circuitstatus beheren met Azure Logic Apps

Azure Logic Apps wordt geleverd met ingebouwde connectors voor verschillende services, functies en stateful orkestraties en is een logische keuze voor het beheren van de circuitstatus. Nadat u hebt gedetecteerd wanneer een circuit moet worden onderbroken, kunt u een logische app bouwen om deze werkstroom te implementeren:

Activeer een Event Grid-werkstroom die de verwerking van de functie stopt.
Verzend een e-mailmelding met een optie om de werkstroom opnieuw op te starten.

Zie Functies uitschakelen in Azure Functions voor meer informatie over het uitschakelen en opnieuw inschakelen van specifieke functies met behulp van app-instellingen.

De ontvanger van het e-mailbericht kan de status van het circuit onderzoeken en, indien van toepassing, het circuit opnieuw starten via een koppeling in de e-mailmelding. Wanneer de werkstroom de functie opnieuw start, worden gebeurtenissen verwerkt vanaf het laatste controlepunt van de Event Hub.

Wanneer u deze methode gebruikt, gaan er geen gebeurtenissen verloren, worden gebeurtenissen op volgorde verwerkt en kunt u het circuit zo lang mogelijk verbreken.

Migratiestrategieën voor Event Grid-triggers

Wanneer u een bestaande functie-app migreert tussen regio's of tussen sommige plannen, moet u de app opnieuw maken tijdens het migratieproces. In dit geval hebt u tijdens het migratieproces mogelijk twee apps die beide uit dezelfde gebeurtenisstroom kunnen gebruiken en naar hetzelfde uitvoerdoel kunnen schrijven.

Overweeg het gebruik van consumentengroepen om verlies of duplicatie van gebeurtenisgegevens tijdens het migratieproces te voorkomen:

Maak een nieuwe consumentengroep voor de nieuwe doel-app.
Configureer de trigger in de nieuwe app om deze nieuwe consumentengroep te gebruiken.

Hierdoor kunnen beide apps gebeurtenissen onafhankelijk verwerken tijdens de validatie.
Controleer of de nieuwe app gebeurtenissen correct verwerkt.
Stop de oorspronkelijke app of verwijder de abonnements-/consumentengroep.