Integrera Event Hubs med serverlösa funktioner i Azure

Lösningar som använder Azure Event Hubs tillsammans med Azure Functions drar nytta av en serverlös arkitektur som är skalbar, kostnadseffektiv och kan bearbeta stora mängder data nästan i realtid. Så mycket som dessa tjänster fungerar sömlöst tillsammans finns det många funktioner, inställningar och invecklingar som ökar komplexiteten i deras relation. Den här artikeln innehåller vägledning om hur du effektivt kan dra nytta av den här integreringen genom att lyfta fram viktiga överväganden och tekniker för prestanda, återhämtning, säkerhet, observerbarhet och skalning.

Grundläggande begrepp för Event Hubs

Azure Event Hubs är en mycket skalbar händelsebearbetningstjänst som kan ta emot miljontals händelser per sekund. Innan du går in på mönster och metodtips för Azure Functions-integrering är det bäst att förstå de grundläggande komponenterna i Event Hubs.

Följande diagram visar dataströmbearbetningsarkitekturen för Event Hubs:

Händelser

En händelse är ett meddelande eller en tillståndsändring som representeras som ett faktum som har inträffat tidigare. Händelser är oföränderliga och bevaras i en händelsehubb, även kallat ett ämne i Kafka. En händelsehubb består av en eller flera partitioner.

Partitioner

När en partition inte anges av avsändaren distribueras mottagna händelser mellan partitioner i händelsehubben. Varje händelse skrivs i exakt en partition och är inte multi-cast över partitioner. Varje partition fungerar som en logg där poster skrivs i ett tilläggsmönster. Analogin för en incheckningslogg används ofta för att beskriva hur händelser läggs till i slutet av en sekvens i en partition.

När mer än en partition används kan parallella loggar användas inifrån samma händelsehubb. Det här beteendet ger flera grader av parallellitet och förbättrar dataflödet för konsumenter.

Konsumenter och konsumentgrupper

En partition kan användas av mer än en konsument, var och en läser från och hanterar sina egna förskjutningar.

Event Hubs har begreppet konsumentgrupper, vilket gör det möjligt för flera förbrukande program att var och en har en separat vy över händelseströmmen och läser strömmen oberoende av varandra i sin egen takt och med sina egna förskjutningar.

Mer information finns i Djupdykning i Event Hubs-begrepp och -funktioner.

Använda händelser med Azure Functions

Azure Functions stöder utlösar- och utdatabindningar för Event Hubs. Det här avsnittet beskriver hur Azure Functions svarar på händelser som skickas till en händelseström för händelsehubben med utlösare.

Varje instans av en Event Hubs-utlöst funktion backas upp av en enda EventProcessorHost-instans . Utlösaren (som drivs av Event Hubs) ser till att endast en EventProcessorHost-instans kan få ett lån på en viss partition.

Tänk dig till exempel en händelsehubb med följande egenskaper:

• 10 partitioner.
• 1 000 händelser distribueras jämnt alla partitioner, med ett varierande antal meddelanden i varje partition.

När funktionen först är aktiverad finns det bara en instans av funktionen. Nu ska vi anropa den första funktionsinstansen Function_1. Function_1 har en enda instans av EventProcessorHost som har ett lån på alla 10 partitioner. Den här instansen läser händelser från partitionerna 1–10. Från och med nu händer något av följande:

• Nya funktionsinstanser behövs inte: Function_1 kan bearbeta alla 1 000 händelser innan skalningslogik för Functions börjar gälla. I det här fallet bearbetas alla 1 000 meddelanden av Function_1.

  

• Ytterligare en funktionsinstans läggs till: händelsebaserad skalning eller annan automatiserad eller manuell logik kan avgöra att det Function_1 finns fler meddelanden än den kan bearbeta och sedan skapar en ny funktionsappinstans (Function_2). Den här nya funktionen har också en associerad instans av EventProcessorHost. När den underliggande händelsehubben upptäcker att en ny värdinstans försöker läsa meddelanden lastbalanseras partitionerna mellan värdinstanserna. Till exempel kan partitioner 1-5 tilldelas till Function_1 och partitioner 6-10 till Function_2.

  

• N fler funktionsinstanser läggs till: händelsebaserad skalning eller annan automatiserad eller manuell logik avgör att både Function_1 och Function_2 har fler meddelanden än de kan bearbeta, skapas nya Function_N funktionsappinstanser. Instanser skapas till den punkt där N är lika med eller större än antalet händelsehubbpartitioner. I vårt exempel belastningsutjämningar Event Hubs partitionerna igen, i det här fallet över instanserna Function_1...Function_10.

  

När skalning sker kan N-instanser vara ett tal större än antalet händelsehubbpartitioner. Den här situationen kan inträffa när händelsedriven skalning stabiliserar antalet instanser, eller på grund av att annan automatiserad eller manuell logik har skapat fler instanser än partitioner. I det här fallet hämtar EventProcessorHost-instanser endast lås på partitioner när de blir tillgängliga från andra instanser, eftersom endast en funktionsinstans från samma konsumentgrupp kan komma åt/läsa från de partitioner som den har lås på.

När all funktionskörning slutförs (med eller utan fel) läggs kontrollpunkter till i det associerade lagringskontot. När kontrollmarkeringen lyckas hämtas aldrig alla 1 000 meddelanden igen.

Dynamisk, händelsebaserad skalning är möjlig med förbruknings- och Premium Azure-planer. Kubernetes värdbaserade funktionsappar kan också dra nytta av KEDA-skalningsverktyget för Event Hubs. Händelsebaserad skalning är för närvarande inte möjlig när funktionsappen finns i en dedikerad plan (App Service), som kräver att du fastställer rätt antal instanser baserat på din arbetsbelastning.

Mer information finns i Azure Event Hubs-bindningar för Azure Functions - och Azure Event Hubs-utlösare för Azure Functions.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

• David Barkol | Huvudlösningsspecialist GBB

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

Relaterade resurser

• Övervakning av serverlös händelsebearbetning ger vägledning om övervakning av serverlösa händelsedrivna arkitekturer.
• Serverlös händelsebearbetning är en referensarkitektur som beskriver en typisk arkitektur av den här typen, med kodexempel och diskussion om viktiga överväganden.