Tillförlitlig händelsebearbetning med Azure Functions och Event Hubs

Lär dig hur du bygger robusta, pålitliga serverlösa lösningar genom att använda Azure Functions med Azure Event Hubs-triggers. Den här artikeln täcker bästa praxis för kontrollpunkter, felhantering och implementering av brytarmönster för att säkerställa att du inte förlorar några händelser och att dina händelsedrivna applikationer förblir stabila och motståndskraftiga.

Utmaningar med händelseströmmar i distribuerade system

Överväg ett system som skickar händelser med en konstant hastighet på 100 händelser per sekund. I denna takt kan flera parallella instanser konsumera de inkommande 100 händelserna varje sekund.

Tänk dock på de här utmaningarna med att använda en händelseström:

  • En händelseutgivare skickar en korrupt händelse.
  • Funktionskoden stöter på ett ohanterat undantag.
  • Ett nedströmssystem går offline och blockerar händelsebearbetning.

Till skillnad från en Azure Queue Storage-utlösare, som låser meddelanden under bearbetningen, läser Azure Event Hubs per partition från en enda punkt i dataströmmen. Det här läsbeteendet, som mer liknar en videospelare, ger de önskade fördelarna med högt dataflöde, flera konsumentgrupper och uppspelningsförmåga. Händelser läss, framåt eller bakåt, från en kontrollpunkt, men du måste flytta pekaren för att bearbeta nya händelser. Mer information finns i Kontrollpunkt i Event Hubs-dokumentationen.

När fel inträffar i en ström och du väljer att inte föra pekaren framåt blockeras ytterligare händelsebearbetning. Med andra ord, om du stoppar pekaren för att hantera ett problem som bearbetar en enskild händelse, börjar de obehandlade händelserna hopa sig.

Funktionerna undviker dödlägen genom att alltid flytta fram dataströmmens pekare, oavsett om de lyckas eller misslyckas. Eftersom pekaren fortsätter att utvecklas måste dina funktioner hantera fel på rätt sätt.

Så här förbrukar Event Hubs-utlösaren händelser

Azure Functions förbrukar händelser från en händelsehubb genom att gå igenom följande steg:

  1. Triggern skapar och behåller en pekare i Azure Storage för varje partition i händelsehubben.
  2. Utlösaren tar emot nya händelser i en batch (som standard), och värden försöker utlösa funktionen genom att skicka batchen med händelser för bearbetning.
  3. När funktionen har körts klart, med eller utan undantag, för utlösaren fram pekaren och sparar en kontrollpunkt i standardlagringskontot för värden.
  4. Om omständigheterna hindrar funktionskörningen från att slutföras, kan värddatorn inte flytta fram pekaren. När pekaren inte kan avancera bearbetas samma händelser på nytt i efterföljande körningar.

Det här beteendet visar några viktiga punkter:

  • Ohanterade undantag kan leda till att du förlorar händelser:

    Funktionskörningar som skapar ett undantag fortsätter att föra pekaren framåt. Om du anger en återförsöksprincip eller andra logikförsök fördröjs pekarens framryckning tills hela återförsöket har slutförts.

  • Functions garanterar leverans minst en gång :

    Din kod och beroende system kan behöva ta hänsyn till det faktum att samma händelse kan bearbetas två gånger. Mer information finns i Designa Azure Functions för identiska indata.

  • Checkpoint state lagras i Azure Storage:

    Utlösaren sparar kontrollpunkten (bearbetningspekaren) i lagringskontot som konfigureras av funktionsappens inställning AzureWebJobsStorage. Den här lagrade referensen till kontrollpunkten betyder följande:

    • När du byter AzureWebJobsStorage till att referera till ett annat lagringskonto börjar funktionen bearbeta från en ny position, vilket kan leda till att händelser bearbetas om.
    • När en händelsehubb tas bort och återskapas återställs händelseströmmens position (såsom sekvensnummer och offsets) medan lagrade kontrollpunktreferenser förblir oförändrade. I detta scenario kanske funktionen inte behandlar nya händelser förrän kontrollpunkten tas bort manuellt.

Hantering av undantag

Även om all funktionskod bör innehålla ett try/catch-block på den högsta kodnivån är det ännu viktigare att ha ett catch block för funktioner som använder Event Hubs-händelser. På så sätt, när ett undantag utlöses, hanterar catch-blocket felet innan pekaren fortsätter.

Återförsöksmekanismer och principer

Eftersom många undantag i molnet är tillfälliga är det första steget i felhanteringen alltid att försöka utföra åtgärden igen. Du kan använda inbyggda återförsöksprinciper eller definiera din egen logik för återförsök.

Principer för nya försök

Functions tillhandahåller inbyggda återförsöksprinciper för Event Hubs. När du använder återförsökspolicyer utlöser du helt enkelt ett nytt undantag, och värdprocessen försöker bearbeta händelsen igen enligt den definierade policyn. Det här återförsöksbeteendet kräver version 5.x eller senare av Event Hubs-tillägget. Mer information finns i Återförsöksprinciper.

Anpassad logik för återförsök

Du kan också definiera din egen logik för återförsök i själva funktionen. Du kan till exempel implementera en princip som följer ett arbetsflöde som illustreras av följande regler:

  • Försök att bearbeta en händelse tre gånger (eventuellt med en fördröjning mellan återförsök).
  • Om det slutliga resultatet av alla återförsök är ett fel lägger du till en händelse i en kö så att bearbetningen kan fortsätta i dataströmmen.
  • Skadade eller obearbetade händelser hanteras senare.

Anmärkning

Polly är ett exempel på ett återhämtnings- och tillfälligt felhanteringsbibliotek för C#-program.

Nonexception-fel

Vissa problem kan uppstå utan att ett undantag uppstår. Tänk dig till exempel ett fall där en begäran överskrider tidsgränsen eller den instans som kör funktionen kraschar. När en funktion inte kan slutföras utan att ett undantag inträffar, förskjuts aldrig förskjutningspekaren. Om pekaruppdateringen inte avancerar fortsätter alla instanser som körs efter en misslyckad exekvering att läsa samma händelser. Den här situationen ger en garanti minst en gång .

Försäkran om att varje händelse bearbetas minst en gång innebär att vissa händelser kan bearbetas mer än en gång. Dina funktionsappar måste vara medvetna om den här möjligheten och måste byggas kring principerna för idempotens.

Hantera feltillstånd

Din app kanske kan hantera ett visst antal fel i händelsebearbetningen. Du bör dock också vara beredd på att hantera beständiga feltillstånd, vilket kan inträffa till följd av fel i nedströmsbearbetningen. I ett sådant feltillstånd, till exempel att ett nedströmsdatalager är offline, bör funktionen sluta utlösa händelser tills systemet når ett felfritt tillstånd.

Kretsbrytarmönster

När du implementerar kretsbrytarmönstret kan appen effektivt pausa händelsebearbetningen och sedan återuppta den vid ett senare tillfälle efter att problem har lösts.

Det krävs två komponenter för att implementera en kretsbrytare i en händelseströmsprocess:

  • Gemensamt tillstånd för alla instanser för att spåra och övervaka kretsens status.
  • En primär process som kan hantera kretstillståndet som antingen open eller closed.

Implementeringsinformationen kan variera, men för att dela tillstånd mellan instanser behöver du en lagringsmekanism. Du kan lagra tillstånd i Azure Storage, en Redis-cache eller någon annan beständig tjänst som kan nås av dina funktionsappinstanser.

Både Durable Functions och Azure Logic Apps tillhandahålla infrastruktur för att hantera arbetsflöden och kretstillstånd. I den här artikeln beskrivs hur du använder Logic Apps för att pausa och starta om funktionskörningar, vilket ger dig den kontroll som krävs för att implementera kretsbrytarmönstret.

Definiera ett tröskelvärde för fel mellan instanser

Beständiga delade externa tillstånd krävs för att övervaka kretsens hälsotillstånd när flera instanser bearbetar händelser samtidigt. Du kan sedan övervaka det här bevarade tillståndet baserat på regler som anger ett feltillstånd, till exempel:

När det finns fler än 100 händelsefel inom en 30-sekundersperiod i alla instanser, ska kretsen brytas för att förhindra att nya händelser utlöses.

Implementeringsinformationen för den här övervakningslogik varierar beroende på dina specifika appbehov, men i allmänhet måste du skapa ett system som:

  1. Loggar misslyckas med sparad lagring.
  2. Granska det löpande antalet när nya fel loggas för att avgöra om tröskelvärdet för händelsefel uppfylls.
  3. När det här tröskelvärdet uppfylls genererar du en händelse som uppmanar systemet att bryta kretsen.

Hantera kretstillstånd med Azure Logic Apps

Azure Logic Apps inkluderar inbyggda kopplingar till olika tjänster, funktioner och tillståndsbundna orkestreringar. Det är ett naturligt val att hantera kretstillståndet. När du har upptäckt när en krets måste brytas kan du skapa en logikapp för att implementera det här arbetsflödet:

  1. Utlös ett Event Grid-arbetsflöde som stoppar funktionsbearbetningen.
  2. Skicka ett e-postmeddelande som innehåller ett alternativ för att starta om arbetsflödet.

För att lära dig hur du inaktiverar och återaktiverar specifika funktioner genom att använda appinställningar, se How to disable functions in Azure Functions.

E-postmottagaren kan undersöka kretsens hälsa och, när det är lämpligt, starta om kretsen via en länk i meddelandemailet. När arbetsflödet startar om funktionen bearbetar det händelser från den senaste händelsehubbens kontrollpunkt.

När du använder detta tillvägagångssätt förlorar du inga händelser, du bearbetar händelser i ordning och kan bryta kretsen så länge det behövs.

Migreringsstrategier för Event Grid-utlösare

När du migrerar en befintlig funktionsapp mellan regioner eller mellan vissa planer måste du återskapa appen under migreringsprocessen. I det här fallet, under migreringen, kan du ha två appar som båda kan konsumera från samma händelseström och skriva till samma utdatadestination.

För att undvika förlust av händelsedata eller duplicering under migreringen, överväg att använda konsumentgrupper:

  1. Skapa en ny konsumentgrupp för den nya målappen.

  2. Konfigurera utlösaren i den nya appen så att den använder den nya konsumentgruppen.

    Genom att använda detta tillvägagångssätt kan båda apparna bearbeta händelser oberoende av varandra under valideringen.

  3. Kontrollera att den nya appen bearbetar händelser korrekt.

  4. Stoppa den ursprungliga appen eller ta bort dess prenumeration eller konsumentgrupp.

  • Last updated on