Resilient Event Hubs en Functions-ontwerp

Artikel
10/11/2021
11 minuten om te lezen

Foutafhandeling, ontwerpen voor idempotentie en beheer van gedrag voor opnieuw proberen zijn enkele van de kritieke maatregelen die u kunt nemen om ervoor te zorgen dat Event Hubs geactiveerde functies flexibel zijn en grote hoeveelheden gegevens kunnen verwerken. In dit artikel worden deze cruciale concepten beschreven en worden aanbevelingen gedaan voor oplossingen voor serverloze gebeurtenisstreaming.

Azure biedt drie belangrijke berichtenservices die kunnen worden gebruikt met Azure Functions ter ondersteuning van een breed scala aan unieke, gebeurtenisgestuurde scenario's. Vanwege het gepartitiesteerde consumentenmodel en de mogelijkheid om gegevens met een hoge snelheid op te nemen, wordt Azure Event Hubs vaak gebruikt voor gebeurtenisstreaming en big data scenario's. Zie Kiezen tussen Azure-berichtenservices - Event Grid, Event Hubs en Service Bus voor een gedetailleerde vergelijking van Azure-berichtenservices.

Voordelen en uitdagingen voor streaming

Inzicht in de voor- en nadelen van stromen helpt u te begrijpen hoe een service zoals Event Hubs werkt. U hebt deze context ook nodig bij het nemen van belangrijke beslissingen over de architectuur, het oplossen van problemen en het optimaliseren van de prestaties. Houd rekening met de volgende belangrijke concepten over oplossingen met zowel Event Hubs als Functions:

Streams zijn geen wachtrijen: Event Hubs, Kafka en andere vergelijkbare producten die zijn gebouwd op basis van het gepartitiese consumentenmodel, bieden geen intrinsieke ondersteuning voor sommige van de belangrijkste functies in een berichtenbroker, zoals Service Bus. De grootste indicator hiervoor is misschien wel het feit dat lees lezen niet-destructief is. Dit betekent dat de gegevens die worden gelezen door de Functions-host niet later worden verwijderd. In plaats daarvan zijn berichten onveranderbaar en kunnen andere consumenten deze blijven lezen, waaronder mogelijk dezelfde klant die het opnieuw leest. Daarom zijn oplossingen die patronen implementeren, zoals concurrerende consumenten, beter geschikt voor een traditionele berichtenbroker.
Ontbrekende ondersteuning voor dead-letter overnemen: Een dead-letter-kanaal is geen native functie in Event Hubs of Kafka. Het concept van 'dead-lettering' is vaak geïntegreerd in een streaming-oplossing om rekening te houden met gegevens die niet kunnen worden verwerkt. Deze functionaliteit is opzettelijk geen innate element in Event Hubs en wordt alleen toegevoegd aan de consumentenzijde om een soortgelijk gedrag of effect te produceren. Als u ondersteuning voor berichten zonder berichten nodig hebt, moet u mogelijk uw keuze voor de streaming-berichtenservice bekijken.
Een werkeenheid is een partitie: In een traditionele berichtenbroker is een werkeenheid één bericht. In een streamingoplossing wordt een partitie vaak beschouwd als de werkeenheid. Als elke gebeurtenis in een Event Hub wordt beschouwd als een afzonderlijk bericht dat moet worden behandeld als een orderverwerkingsbewerking of financiële transactie, is het waarschijnlijk een indicatie van de verkeerde berichtenservice die wordt gebruikt.
Geen filters op de server: Een van de redenen Event Hubs kan worden geschaald en de doorvoer wordt veroorzaakt door de lage overhead van de service zelf. Functies zoals filteren op de server, indexen en coördinatie tussen verschillende brokeren maken geen deel uit van de architectuur van Event Hubs. Functies worden af en toe gebruikt om gebeurtenissen te filteren door ze naar andere Event Hubs op basis van de inhoud in de hoofdtekst of header. Deze aanpak is gebruikelijk bij het streamen van gebeurtenissen, maar heeft het nadeel dat elke gebeurtenis wordt gelezen en geëvalueerd door de initiële functie.
Elke lezer moet alle gegevens lezen: Omdat filteren op de server niet beschikbaar is, leest een consument opeenvolgend alle gegevens in een partitie. Dit omvat gegevens die mogelijk niet relevant zijn of zelfs misvormd kunnen zijn. Er zijn verschillende opties en zelfs strategieën die kunnen worden gebruikt om deze uitdagingen te compenseren die later in deze sectie worden behandeld.

Met deze belangrijke ontwerpbeslissingen kunnen Event Hubs doen wat het beste werkt: een aanzienlijke instroom van gebeurtenissen ondersteunen en een robuuste en robuuste service bieden waar gebruikers uit kunnen lezen. Elke consumententoepassing is verantwoordelijk voor het onderhouden van hun eigen offsets aan de clientzijde of cursor naar deze gebeurtenissen. De lage overhead maakt Event Hubs een betaalbaar en krachtige optie voor het streamen van gebeurtenissen.

Idempotentie

Een van de belangrijkste basisconcepten Azure Event Hubs is het concept van ten minste één levering. Deze aanpak zorgt ervoor dat gebeurtenissen altijd worden geleverd. Het betekent ook dat gebeurtenissen meer dan één keer, zelfs herhaaldelijk, kunnen worden ontvangen door consumenten, zoals een functie. Daarom is het belangrijk dat een door event hub geactiveerde functie het idempotent consumerpatroon ondersteunt.

Werken met de veronderstelling dat er ten minste één levering is, met name binnen de context van een gebeurtenisgestuurde architectuur, is een verantwoorde benadering voor het op betrouwbare wijze verwerken van gebeurtenissen. Uw functie moet idempotent zijn, zodat het resultaat van het meerdere keren verwerken van dezelfde gebeurtenis hetzelfde is als het één keer verwerken ervan.

Dubbele gebeurtenissen

Er zijn verschillende scenario's die ertoe kunnen leiden dat dubbele gebeurtenissen aan een functie worden geleverd:

Controlepunten: Als de Azure Functions host vast loopt of als de drempelwaarde voor de controlepuntfrequentie van de batch niet wordt bereikt, wordt er geen controlepunt gemaakt. Als gevolg hiervan is de offset voor de consument niet geavanceerd en de volgende keer dat de functie wordt aangeroepen, wordt deze hervat vanaf het laatste controlepunt. Het is belangrijk te weten dat controlepunten plaatsvinden op het partitieniveau voor elke consument.
Gepubliceerde dubbele gebeurtenissen: Er zijn veel technieken die de mogelijkheid kunnen verminderen dat dezelfde gebeurtenis naar een stroom wordt gepubliceerd, maar het is nog steeds de verantwoordelijkheid van de consument om dubbele gegevens idempotent te verwerken.
Ontbrekende bevestigingen: In sommige gevallen kan een uitgaande aanvraag naar een service slagen, maar er wordt nooit een bevestiging (ACK) van de service ontvangen. Dit kan ertoe leiden dat de uitgaande aanroep is mislukt en dat er een reeks of nieuwe pogingen of andere resultaten van de functie worden gestart. Uiteindelijk kunnen dubbele gebeurtenissen worden gepubliceerd of wordt er geen controlepunt gemaakt.

Ontdubbelingstechnieken

Het ontwerpen van uw functies voor identieke invoer moet de standaardbenadering zijn wanneer deze is gekoppeld aan de Event Hub-triggerbinding. Houd rekening met de volgende technieken:

Op zoek naar duplicaten: Voordat u deze verwerkt, moet u de benodigde stappen nemen om te controleren of de gebeurtenis moet worden verwerkt. In sommige gevallen is hiervoor een onderzoek nodig om te bevestigen dat het nog geldig is. Het kan ook zijn dat het verwerken van de gebeurtenis niet meer nodig is vanwege de nieuwheid van gegevens of logica die de gebeurtenis ongeldig maakt.
Ontwerpgebeurtenissen voor idempotentie: Door aanvullende informatie op te geven in de nettolading van de gebeurtenis, kan het mogelijk zijn om ervoor te zorgen dat de verwerking ervan meerdere keren geen schadelijke effecten heeft. Neem het voorbeeld van een gebeurtenis met een bedrag dat moet worden afgeschreven van een rekening. Als niet op verantwoorde wijze wordt omgegaan, is het mogelijk dat het saldo van een account meerdere keren wordt afgeschreven. Als dezelfde gebeurtenis echter het bijgewerkte saldo voor het account bevat, kan deze worden gebruikt om een upsert-bewerking uit te voeren op het saldo van het bankaccount. Deze gebeurtenisoverdrachtmethode vereist af en toe coördinatie tussen producenten en consumenten en moet worden gebruikt wanneer dit zinvol is voor deelnemende services.

Foutafhandeling en nieuwe pogingen

Foutafhandeling en nieuwe aanmeldingen zijn enkele van de belangrijkste eigenschappen van gedistribueerde, gebeurtenisgestuurde toepassingen en Functies vormen hierop geen uitzondering. Voor oplossingen voor het streamen van gebeurtenissen is de juiste ondersteuning voor foutafhandeling van cruciaal belang, omdat duizenden gebeurtenissen snel kunnen veranderen in een gelijk aantal fouten als ze niet correct worden verwerkt.

Richtlijnen voor foutafhandeling

Zonder foutafhandeling kan het lastig zijn om nieuwe proberen te implementeren, runtime-uitzonderingen te detecteren en problemen te onderzoeken. Elke functie moet ten minste een niveau of foutafhandeling hebben. Enkele aanbevolen richtlijnen zijn:

Toepassingstoepassing Insights: Schakel Application Insights in om fouten in te loggen en de status van uw functies te controleren. Let op de configureerbare steekproefopties voor scenario's die een groot aantal gebeurtenissen verwerken.
Gestructureerde foutafhandeling toevoegen: Pas de juiste constructies voor foutafhandeling toe voor elke programmeertaal om verwachte en onverwerkte uitzonderingen in uw functiecode te ondervangen, te detecteren en te detecteren. Gebruik bijvoorbeeld een try/catch-blok in C , Java en JavaScript en profiteer van de blokken try en except in Python om uitzonderingen # af te handelen.
Logboekregistratie: Het detecteren van een uitzondering tijdens de uitvoering biedt de mogelijkheid om kritieke informatie vast te maken die kan worden gebruikt om problemen betrouwbaar te detecteren, te reproduceren en op te lossen. Registreer de uitzondering, niet alleen het bericht, maar ook de body, interne uitzondering en andere nuttige artefacten die later nuttig zijn.
Uitzonderingen niet ondervangen en negeren: Een van de ergste dingen die u kunt doen, is een uitzondering ondervangen en er niets mee doen. Als u een algemene uitzondering ondervangt, moet u deze ergens melden. Als u geen fouten vastmeldt, is het moeilijk om fouten en gerapporteerde problemen te onderzoeken.

Nieuwe pogingen

Het implementeren van logica voor opnieuw proberen in een architectuur voor het streamen van gebeurtenissen kan complex zijn. Het ondersteunen van annuleringstokens, aantal nieuwe pogingen en exponentieel terugvallen van strategieën zijn slechts enkele van de overwegingen die het lastig maken. Gelukkig biedt Functions beleid voor opnieuw proberen dat veel van deze taken kan omvatten die u doorgaans zelf zou coden.

Enkele belangrijke factoren die in aanmerking moeten worden genomen bij het gebruik van het beleid voor opnieuw proberen met de Event Hub-binding, zijn onder andere:

Voorkom onbepaalde nieuwe proberen: Wanneer de instelling voor het maximum aantal nieuwe poging is ingesteld op een waarde van -1, zal de functie het voor onbepaalde tijd opnieuw proberen. Over het algemeen moeten onbeperkte nieuwe proberen spaarzaam worden gebruikt met Functions en bijna nooit met de Event Hub-triggerbinding.
Kies de juiste strategie voor opnieuw proberen: Een strategie met een vaste vertraging kan optimaal zijn voor scenario's waarin de druk van andere Azure-services wordt teruggezet. In dergelijke gevallen kan de vertraging helpen om beperking en andere beperkingen van deze services te voorkomen. De strategie voor exponentieel uitstel biedt meer flexibiliteit voor intervallen met vertragingen voor nieuwe poging en wordt vaak gebruikt bij de integratie met services van derden, REST-eindpunten en andere Azure-services.
Houd de intervallen en het aantal nieuwe poging laag: Probeer, indien mogelijk, een interval voor nieuwe poging te behouden dat korter is dan één minuut. Houd ook het maximum aantal nieuwe pogingen bij tot een redelijk laag aantal. Deze instellingen zijn vooral relevant wanneer ze worden uitgevoerd in het Functions-verbruiksplan.
Circuit breaker-patroon: Er wordt van tijd tot tijd een tijdelijke foutfout verwacht en een natuurlijke use-case voor nieuwe proberen. Als er echter een groot aantal fouten of problemen optreden tijdens de verwerking van de functie, kan het zinvol zijn om de functie te stoppen, de problemen op te lossen en later opnieuw op te starten.

Een belangrijk punt voor het beleid voor opnieuw proberen in Functions is dat het een functie is die optimaal werkt voor het opnieuw verwerken van gebeurtenissen. Het vervangt niet de noodzaak van foutafhandeling, logboekregistratie en andere belangrijke patronen die tolerantie bieden voor uw code.

Strategieën voor fouten en beschadigde gegevens

Er zijn verschillende opmerkingsmethoden die u kunt gebruiken om te compenseren voor problemen die zich voordoen als gevolg van fouten of slechte gegevens in een gebeurtenisstroom. Enkele fundamentele strategieën zijn:

Stoppen met verzenden en lezen: Pauzeer het lezen en schrijven van gebeurtenissen om het onderliggende probleem op te lossen. Het voordeel van deze benadering is dat gegevens niet verloren gaan en dat bewerkingen kunnen worden hervat nadat een oplossing is uitgerold. Voor deze aanpak is mogelijk een circuit breaker-onderdeel in de architectuur vereist en mogelijk een melding aan de betrokken services om een onderbreking te bereiken. In sommige gevallen kan het nodig zijn om een functie te stoppen totdat de problemen zijn opgelost.
Berichten verwijderen: Als berichten niet belangrijk zijn of als niet-bedrijfskritiek worden beschouwd, kunt u overwegen om door te gaan en ze niet te verwerken. Dit werkt niet voor scenario's waarvoor sterke consistentie is vereist, zoals het vastleggen van bewegingen in een match met financiën of transacties op basis van financiën. Foutafhandeling binnen een functie wordt aanbevolen voor het afhalen en verwijderen van berichten die niet kunnen worden verwerkt.
Opnieuw proberen: Er zijn veel situaties die het opnieuw verwerken van een gebeurtenis kunnen rechtvaardigen. Het meest voorkomende scenario is een tijdelijke fout die wordt aangetroffen bij het aanroepen van een andere service of afhankelijkheid. Netwerkfouten, servicelimieten en beschikbaarheid en sterke consistentie zijn mogelijk de meest voorkomende gebruiksgevallen die pogingen tot opnieuw verwerken rechtvaardigen.
Dead letter: Het idee hier is om de gebeurtenis te publiceren naar een andere Event Hub, zodat de bestaande stroom niet wordt onderbroken. Het idee is dat het van het hot pad is verplaatst en later of door een ander proces kan worden afgehandeld. Deze oplossing wordt vaak gebruikt voor het verwerken van verafhandelde berichten of gebeurtenissen. U moet er rekening mee houden dat elke functie, die is geconfigureerd met een andere consumentengroep, nog steeds te maken krijgt met beschadigde of beschadigde gegevens in hun stroom en dat deze op verantwoorde wijze moeten worden verwerkt.
Opnieuw proberen en niet-klaar: De combinatie van talloze nieuwe pogingen voordat uiteindelijk naar een stroom voor een impasse wordt gepubliceerd zodra een drempelwaarde is bereikt, is een andere bekende methode.
Een schemaregister gebruiken: Een schemaregister kan worden gebruikt als een proactief hulpprogramma om de consistentie en gegevenskwaliteit te verbeteren. Het Azure Schema Registry kan ondersteuning bieden voor de overgang van schema's, samen met versie-versies en verschillende compatibiliteitsmodi naarmate schema's zich ontwikkelen. In de kern zal het schema fungeren als een contract tussen producenten en consumenten, waardoor de kans wordt verkleind dat ongeldige of beschadigde gegevens naar de stroom worden gepubliceerd.

Uiteindelijk is er geen perfecte oplossing en moeten de gevolgen en afwegingen van elk van de strategieën grondig worden onderzocht. Op basis van de vereisten kan het gebruik van verschillende van deze technieken samen de beste aanpak zijn.

Volgende stappen

Voordat u doorgaat, kunt u deze gerelateerde artikelen lezen:

Beveiliging

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 een bespreking van belangrijke overwegingen.
In Batchverwerking en filteren in serverloze gebeurtenisverwerking met Event Hubs wordt gedetailleerder beschreven hoe deze gedeelten van de referentiearchitectuur werken.