Dela via

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

Lär dig hur du skapar robusta och tillförlitliga serverlösa lösningar med Azure Functions med Azure Event Hubs-utlösare. Den här artikeln beskriver metodtips för kontrollpunkter, felhantering och implementering av kretsbrytarmönster för att säkerställa att inga händelser går förlorade och att dina händelsedrivna program 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 den här takten kan flera parallella instanser använda inkommande 100 händelser varje sekund inom några minuter.

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 strö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 obearbetade händelserna staplas upp.

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 använder händelser från en händelsehubb genom att gå igenom följande steg:

  1. En pekare skapas och sparas i Azure Storage för varje partition i händelsehubben.
  2. Nya händelser tas emot i en batch (som standard) och värdtjänsten försöker utlösa funktionen som tillhandahåller batchen med händelser för bearbetning.
  3. När funktionen slutför körningen, med eller utan undantag, flyttas pekaren framåt och en kontrollpunkt sparas till värdens standardlagringskonto.
  4. Om villkor förhindrar att funktionskörningen slutförs kan värden inte föra pekaren framåt. 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.

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öksprinciper skapar du bara ett nytt undantag och värden försöker bearbeta händelsen igen baserat på den definierade principen. 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åller 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 levereras med inbyggda anslutningar till olika tjänster, funktioner och tillståndsberoende orkestreringar, och det är ett naturligt val för att hantera kretstillstånd. 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.

Information om hur du inaktiverar och kan återanvända specifika funktioner med appinställningar finns i Inaktivera funktioner i Azure Functions.

E-postmottagaren kan undersöka kretsens hälsotillstånd och, när det är lämpligt, starta om kretsen via en länk i e-postmeddelandet. När arbetsflödet startar om funktionen bearbetas händelser från den senaste kontrollpunkten för händelsehubben.

När du använder den här metoden går inga händelser förlorade, händelser bearbetas i ordning och du 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 kan du under migreringsprocessen ha två appar som båda kan använda från samma händelseström och skriva till samma utdatamål.

Du bör överväga att använda konsumentgrupper för att undvika förlust av händelsedata eller duplicering under migreringsprocessen:

  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.

    Detta gör att båda apparna kan 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/konsumentgrupp.