Integrera Event Hubs med serverlösa funktioner i Azure

Lösningar som använder Azure Event Hubs tillsammans med Azure Functions dra nytta av en serverlös arkitektur som är skalbar, kostnadseffektiv och som kan bearbeta stora mängder data nästan i realtid. Även om 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 tjänst för händelsebearbetning 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 beständiga 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 att flera konsumerande program kan ha en separat vy över händelseströmmen och läsa dataströmmen oberoende av varandra i sin egen takt och med sina egna förskjutningar.

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

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 i 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) säkerställer 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 functions skalningslogik 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 om det Function_1 finns fler meddelanden än den kan bearbeta och sedan skapa 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 belastningsutjämning 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åda 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 partitioner i händelsehubben. I vårt exempel lastbalanserar Event Hubs återigen partitionerna, i det här fallet över instanserna Function_1...Function_10.

  

När skalning sker kan N-instanser vara ett tal som är större än antalet partitioner i händelsehubben. 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 alla funktionskörningar slutförs (med eller utan fel) läggs kontrollpunkter till i det associerade lagringskontot. När kontrollen är klar hämtas aldrig alla 1 000 meddelanden igen.

Dynamisk, händelsebaserad skalning är möjlig med förbrukning 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 (App Service) plan, vilket 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. Den skrevs ursprungligen av följande deltagare.

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.
• Av batchbearbetning och filtrering i serverlös händelsebearbetning med Event Hubs beskriver i detalj hur dessa delar av referensarkitekturen fungerar.