Asynkrona meddelandealternativ

Event Hubs
Event Grid
Service Bus
Stream Analytics

Den här artikeln beskriver de olika typerna av meddelanden och de entiteter som deltar i en meddelandeinfrastruktur. Baserat på kraven för varje meddelandetyp rekommenderar artikeln Azure Messaging Services. Alternativen är Azure Service Bus, Event Grid och Event Hubs.

På arkitekturnivå är ett meddelande ett datagram som skapats av en entitet (producent) för att distribuera information så att andra entiteter (konsumenter) kan vara medvetna och agera därefter. Producenten och konsumenten kan kommunicera direkt eller valfritt via en mellanliggande entitet (meddelandeförmedlare). Den här artikeln fokuserar på asynkrona meddelanden med hjälp av en meddelandekö.

Diagram som visar entiteter som deltar i asynkrona meddelanden.

Meddelanden kan klassificeras i två huvudkategorier. Om producenten förväntar sig en åtgärd från konsumenten är det meddelandet ett kommando. Om meddelandet informerar konsumenten om att en åtgärd har vidtagits är meddelandet en händelse.

Kommandon

Producenten skickar ett kommando med avsikten att konsumenterna ska utföra en åtgärd inom omfånget för en affärstransaktion.

Ett kommando är ett meddelande med högt värde och måste levereras minst en gång. Om ett kommando går förlorat kan hela affärstransaktionen misslyckas. Dessutom bör ett kommando inte bearbetas mer än en gång. Detta kan orsaka en felaktig transaktion. En kund kan få dubblettbeställningar eller faktureras två gånger.

Kommandon används ofta för att hantera arbetsflödet för en affärstransaktion med flera steg. Beroende på affärslogik kan producenten förvänta sig att konsumenten bekräftar meddelandet och rapporterar resultatet av åtgärden. På grundval av detta resultat kan producenten välja ett lämpligt tillvägagångssätt.

Händelser

En händelse är en typ av meddelande som en producent genererar för att meddela fakta.

Producenten (känd som utgivaren i detta sammanhang) har inga förväntningar på att händelserna kommer att resultera i någon åtgärd.

Intresserade konsumenter kan prenumerera, lyssna efter händelser och vidta åtgärder beroende på deras förbrukningsscenario. Händelser kan ha flera prenumeranter eller inga prenumeranter alls. Två olika prenumeranter kan reagera på en händelse med olika åtgärder och inte känna till varandra.

Producenten och konsumenten är löst kopplade och hanteras oberoende av varandra. Konsumenten förväntas inte bekräfta händelsen tillbaka till producenten. En konsument som inte längre är intresserad av händelserna kan avbryta prenumerationen. Konsumenten tas bort från pipelinen utan att påverka tillverkaren eller systemets övergripande funktionalitet.

Det finns två kategorier av händelser:

  • Producenten tar upp evenemang för att tillkännage diskreta fakta. Ett vanligt användningsfall är händelsemeddelande. Till exempel genererar Azure Resource Manager händelser när de skapar, ändrar eller tar bort resurser. En prenumerant på dessa händelser kan vara en logikapp som skickar e-postmeddelanden med aviseringar.

  • Producenten genererar relaterade händelser i en sekvens, eller en ström av händelser, under en tidsperiod. Normalt används en dataström för statistisk utvärdering. Utvärderingen kan göras inom ett tidsfönster eller när händelser anländer. Telemetri är ett vanligt användningsfall, till exempel hälso- och belastningsövervakning av ett system. Ett annat fall är händelseströmning från IoT-enheter.

Ett vanligt mönster för att implementera händelsemeddelanden är mönstret Publisher-Subscriber .

Utgivar-prenumerantmönster för händelsemeddelanden

Roll och fördelar med en meddelandeförmedlare

En mellanliggande meddelandeförmedlare ger funktioner för att flytta meddelanden från producent till konsument och kan ge ytterligare fördelar.

Frånkoppling

En meddelandekoordinator frikopplar producenten från konsumenten i logiken som genererar respektive använder meddelandena. I ett komplext arbetsflöde kan asynkron meddelandekö uppmuntra till att affärsåtgärder frikopplas och hjälpa till att samordna arbetsflödet.

En enskild affärstransaktion kräver till exempel distinkta åtgärder som utförs i en affärslogiksekvens. Producenten utfärdar ett kommando som signalerar en konsument att starta en åtgärd. Konsumenten bekräftar meddelandet i en separat kö som är reserverad för att rada upp svar för producenten. Först efter att ha fått svaret skickar producenten ett nytt meddelande för att starta nästa åtgärd i sekvensen. En annan konsument bearbetar meddelandet och skickar ett slutförandemeddelande till svarskö. Med hjälp av meddelanden samordnar tjänsterna arbetsflödet för transaktionen sinsemellan.

Kommunikation mellan producent och konsument

En meddelandekö ger tidsmässig frikoppling. Producenten och konsumenten behöver inte köras samtidigt. En producent kan skicka ett meddelande till meddelandekoordinatorn oavsett konsumentens tillgänglighet. Omvänt begränsas inte konsumenten av producentens tillgänglighet.

Användargränssnittet för en webbapp genererar till exempel meddelanden och använder en kö som meddelandeförmedlare. När det är klart kan konsumenter hämta meddelanden från kön och utföra arbetet. Tidsmässig frikoppling hjälper användargränssnittet att förbli responsivt. Det blockeras inte när meddelandena hanteras asynkront.

Vissa åtgärder kan ta lång tid att slutföra. När du har utfärdat ett kommando ska producenten inte behöva vänta tills konsumenten har slutfört det. En meddelandekö hjälper till med asynkron bearbetning av meddelanden.

Belastningsutjämning

Producenter kan publicera ett stort antal meddelanden som hanteras av många konsumenter. Använd en meddelandekö för att distribuera bearbetning över servrar och förbättra dataflödet. Konsumenter kan köra på olika servrar för att sprida belastningen. Konsumenter kan läggas till dynamiskt för att skala ut systemet när det behövs eller tas bort på annat sätt.

Mönster för konkurrerande konsumenter

Mönstret Konkurrerande konsumenter förklarar hur du bearbetar flera meddelanden samtidigt för att optimera dataflödet, för att förbättra skalbarheten och tillgängligheten och för att balansera arbetsbelastningen.

Belastningsutjämning

Mängden meddelanden som genereras av producenten eller en grupp producenter kan vara variabel. Ibland kan det finnas en stor volym som orsakar toppar i meddelanden. I stället för att lägga till konsumenter för att hantera detta arbete kan en meddelandekö fungera som en buffert, och konsumenterna dränerar gradvis meddelanden i sin egen takt utan att betona systemet.

Mönster för köbaserad belastningsutjämning

Det köbaserade belastningsutjämningsmönstret innehåller mer information.

Tillförlitliga meddelanden

En meddelandeförmedlare hjälper till att säkerställa att meddelanden inte går förlorade även om kommunikationen misslyckas mellan producenten och konsumenten. Producenten kan publicera meddelanden till meddelandekoordinatorn och konsumenten kan hämta dem när kommunikationen återupprättas. Producenten blockeras inte om den inte förlorar anslutningen till meddelandekoordinatorn.

Elastiska meddelanden

En meddelandekö kan öka motståndskraften för användarna i systemet. Om en konsument misslyckas när ett meddelande bearbetas kan en annan instans av konsumenten bearbeta meddelandet. Ombearbetningen är möjlig eftersom meddelandet finns kvar i asynkron meddelandekö.

Teknikval för en meddelandeförmedlare

Azure tillhandahåller flera meddelandekötjänster, var och en med en rad funktioner. Innan du väljer en tjänst ska du fastställa avsikten och kraven för meddelandet.

Azure Service Bus

Azure Service Bus köer passar bra för att överföra kommandon från producenter till konsumenter. Här är några saker att tänka på.

Pull-modell

En användare av en Service Bus-kö avsöker ständigt Service Bus för att kontrollera om nya meddelanden är tillgängliga. Klient-SDK:erna och Azure Functions utlösare för Service Bus abstraherar modellen. När ett nytt meddelande är tillgängligt anropas konsumentens återanrop och meddelandet skickas till konsumenten.

Garanterad leverans

Med Service Bus kan en konsument titta på kön och låsa ett meddelande från andra konsumenter.

Det är konsumentens ansvar att rapportera meddelandets bearbetningsstatus. Endast när konsumenten markerar meddelandet som förbrukat tar Service Bus bort meddelandet från kön. Om ett fel, en timeout eller en krasch inträffar låser Service Bus upp meddelandet så att andra konsumenter kan hämta det. På så sätt går inte meddelanden förlorade i överföringen.

En producent kan av misstag skicka samma meddelande två gånger. En producentinstans misslyckas till exempel efter att ett meddelande har skickats. En annan producent ersätter den ursprungliga instansen och skickar meddelandet igen. Azure Service Bus köer ger en inbyggd avdubbleringsfunktion som identifierar och tar bort dubblettmeddelanden. Det finns fortfarande en chans att ett meddelande levereras två gånger. Om en konsument till exempel misslyckas under bearbetningen returneras meddelandet till kön och hämtas av samma eller en annan konsument. Logiken för meddelandebearbetning i konsumenten bör vara idempotent så att systemets tillstånd inte ändras även om arbetet upprepas.

Meddelandeordning

Om du vill att konsumenterna ska få meddelandena i den ordning de skickas garanterar Service Bus-köer fifo-ordnad leverans (först in först ut) med hjälp av sessioner. En session kan ha ett eller flera meddelanden. Meddelandena är korrelerade med egenskapen SessionId . Meddelanden som ingår i en session upphör aldrig att gälla. En session kan låsas till en konsument för att förhindra att meddelandena hanteras av en annan konsument.

Mer information finns i Meddelandesessioner.

Meddelandepersistence

Service Bus-köer stöder temporal frikoppling. Även om en konsument inte är tillgänglig eller inte kan bearbeta meddelandet finns det kvar i kön.

Tidskrävande kontrollpunktstransaktioner

Affärstransaktioner kan köras under lång tid. Varje åtgärd i transaktionen kan ha flera meddelanden. Använd kontrollpunkter för att samordna arbetsflödet och ge återhämtning om en transaktion misslyckas.

Service Bus-köer tillåter kontrollpunkter via funktionen för sessionstillstånd. Tillståndsinformation registreras inkrementellt i kön (SetState) för meddelanden som tillhör en session. En konsument kan till exempel spåra förloppet genom att kontrollera tillståndet (GetState) då och då. Om en konsument misslyckas kan en annan konsument använda tillståndsinformation för att fastställa den senast kända kontrollpunkten för att återuppta sessionen.

Kö med obeställbara meddelanden (DLQ)

En Service Bus-kö har en standardunderfråga som kallas kö med obeställbara meddelanden (DLQ) för att lagra meddelanden som inte kunde levereras eller bearbetas. Service Bus eller logiken för meddelandebearbetning i konsumenten kan lägga till meddelanden i DLQ. DLQ behåller meddelandena tills de hämtas från kön.

Här följer exempel när ett meddelande kan hamna i DLQ:

  • Ett giftmeddelande är ett meddelande som inte kan hanteras eftersom det är felaktigt formaterat eller innehåller oväntad information. I Service Bus-köer kan du identifiera skadliga meddelanden genom att ange egenskapen MaxDeliveryCount för kön. Om antalet gånger samma meddelande tas emot överskrider egenskapsvärdet flyttar Service Bus meddelandet till DLQ.

  • Ett meddelande kanske inte längre är relevant om det inte bearbetas inom en period. Med Service Bus-köer kan producenten publicera meddelanden med ett time to live-attribut. Om den här perioden går ut innan meddelandet tas emot placeras meddelandet i DLQ.

Granska meddelanden i DLQ för att fastställa orsaken till felet.

Hybridlösning

Service Bus brygger lokala system och molnlösningar. Lokala system är ofta svåra att nå på grund av brandväggsbegränsningar. Både producent och konsument (antingen kan vara lokalt eller i molnet) kan använda Service Bus-köslutpunkten som upphämtnings- och avlämningsplats för meddelanden.

Ämnen och prenumerationer

Service Bus stöder Publisher-Subscriber mönster via Service Bus-ämnen och -prenumerationer.

Den här funktionen är ett sätt för producenten att sända meddelanden till flera konsumenter. När ett ämne tar emot ett meddelande vidarebefordras det till alla konsumenter som prenumererar. En prenumeration kan också ha filtervillkor som gör att konsumenten kan få en delmängd av meddelandena. Varje konsument hämtar meddelanden från en prenumeration på ett liknande sätt som en kö.

Mer information finns i Azure Service Bus avsnitt.

Azure Event Grid

Azure Event Grid rekommenderas för diskreta händelser. Event Grid följer Publisher-Subscriber-mönstret. När händelsekällor utlöser händelser publiceras de till Event Grid-ämnen. Konsumenter av dessa händelser skapar Event Grid-prenumerationer genom att ange händelsetyper och händelsehanterare som ska bearbeta händelserna. Om det inte finns några prenumeranter ignoreras händelserna. Varje händelse kan ha flera prenumerationer.

Push-modell

Event Grid sprider meddelanden till prenumeranterna i en push-modell. Anta att du har en event grid-prenumeration med en webhook. När en ny händelse anländer skickar Event Grid händelsen till webhook-slutpunkten.

Integrerad med Azure

Välj Event Grid om du vill få meddelanden om Azure-resurser. Många Azure-tjänster fungerar som händelsekällor som har inbyggda Event Grid-ämnen. Event Grid stöder också olika Azure-tjänster som kan konfigureras som händelsehanterare. Det är enkelt att prenumerera på dessa ämnen för att dirigera händelser till valfria händelsehanterare. Du kan till exempel använda Event Grid för att anropa en Azure-funktion när en bloblagring skapas eller tas bort.

Anpassade ämnen

Skapa anpassade Event Grid-ämnen om du vill skicka händelser från ditt program eller en Azure-tjänst som inte är integrerad med Event Grid.

Om du till exempel vill se förloppet för en hel affärstransaktion vill du att de deltagande tjänsterna ska generera händelser när de bearbetar sina enskilda affärsåtgärder. En webbapp visar dessa händelser. Ett sätt är att skapa ett anpassat ämne och lägga till en prenumeration med din webbapp registrerad via en HTTP WebHook. När företagstjänster skickar händelser till det anpassade ämnet skickar Event Grid dem till din webbapp.

Filtrerade händelser

Du kan ange filter i en prenumeration för att instruera Event Grid att endast dirigera en delmängd händelser till en specifik händelsehanterare. Filtren anges i prenumerationsschemat. Alla händelser som skickas till ämnet med värden som matchar filtret vidarebefordras automatiskt till den prenumerationen.

Till exempel laddas innehåll i olika format upp till Blob Storage. Varje gång en fil läggs till genereras en händelse och publiceras till Event Grid. Händelseprenumerationen kan ha ett filter som bara skickar händelser för bilder så att en händelsehanterare kan generera miniatyrbilder.

Mer information om filtrering finns i Filtrera händelser för Event Grid.

Högt genomflöde

Event Grid kan dirigera 10 000 000 händelser per sekund per region. De första 100 000 åtgärderna per månad är gratis. Kostnadsöverväganden finns i Hur mycket kostar Event Grid?

Elastisk leverans

Även om en lyckad leverans för händelser inte är lika viktig som kommandon, kanske du fortfarande vill ha en viss garanti beroende på typen av händelse. Event Grid erbjuder funktioner som du kan aktivera och anpassa, till exempel återförsöksprinciper, förfallotid och obeställbara meddelanden. Mer information finns i Leverans och försök igen.

Event Grids återförsöksprocess kan hjälpa återhämtning, men det är inte felsäkert. I återförsöksprocessen kan Event Grid leverera meddelandet mer än en gång, hoppa över eller fördröja vissa återförsök om slutpunkten inte svarar under en längre tid. Mer information finns i Återförsöksschema och varaktighet.

Du kan spara händelser som inte har levererats till ett bloblagringskonto genom att aktivera obeställbara meddelanden. Det finns en fördröjning i leveransen av meddelandet till bloblagringsslutpunkten och om slutpunkten inte svarar tar Event Grid bort händelsen. Mer information finns i Obeställbara meddelanden och återförsöksprinciper.

Azure Event Hubs

När du arbetar med en händelseström är Hub eventi di Azure den rekommenderade meddelandekoordinatorn. I princip är det en stor buffert som kan ta emot stora mängder data med låg svarstid. Mottagna data kan läsas snabbt genom samtidiga åtgärder. Du kan transformera mottagna data med hjälp av valfri realtidsanalysprovider. Event Hubs ger också möjlighet att lagra händelser i ett lagringskonto.

Snabb inmatning

Event Hubs kan mata in miljontals händelser per sekund. Händelserna läggs bara till i strömmen och sorteras efter tid.

Pull-modell

Precis som Event Grid erbjuder Event Hubs även Publisher-Subscriber funktioner. En viktig skillnad mellan Event Grid och Event Hubs är hur händelsedata görs tillgängliga för prenumeranterna. Event Grid skickar inmatade data till prenumeranterna medan Event Hub gör data tillgängliga i en pull-modell. När händelser tas emot lägger Event Hubs till dem i strömmen. En prenumerant hanterar markören och kan gå framåt och tillbaka i strömmen, välja en tidsförskjutning och spela upp en sekvens i sin takt.

Stream-processorer är prenumeranter som hämtar data från Event Hubs för transformering och statistisk analys. Använd Azure Stream Analytics och Apache Spark för komplex bearbetning, till exempel aggregering över tid eller avvikelseidentifiering.

Om du vill agera på varje händelse per partition kan du hämta data med hjälp av Händelsebearbetningsvärd eller med hjälp av inbyggd anslutningsapp, till exempel Logic Apps , för att tillhandahålla transformeringslogik. Ett annat alternativ är att använda Azure Functions.

Partitionering

En partition är en del av händelseströmmen. Händelserna delas med hjälp av en partitionsnyckel. Flera IoT-enheter skickar till exempel enhetsdata till en händelsehubb. Partitionsnyckeln är enhetsidentifieraren. När händelser matas in flyttar Event Hubs dem till separata partitioner. I varje partition sorteras alla händelser efter tid.

En konsument är en instans av kod som bearbetar händelsedata. Event Hubs följer ett partitionerat konsumentmönster. Varje konsument läser bara en specifik partition. Att ha flera partitioner leder till snabbare bearbetning eftersom dataströmmen kan läsas samtidigt av flera konsumenter.

Instanser av samma konsument utgör en enskild konsumentgrupp. Flera konsumentgrupper kan läsa samma ström med olika avsikter. Anta att en händelseström har data från en temperatursensor. En konsumentgrupp kan läsa strömmen för att identifiera avvikelser, till exempel en temperaturökning. En annan kan läsa samma ström för att beräkna en rullande medeltemperatur i ett tidsfönster.

Event Hubs stöder Publisher-Subscriber mönster genom att tillåta flera konsumentgrupper. Varje konsumentgrupp är prenumerant.

Mer information om Event Hub-partitionering finns i Partitioner.

Event Hubs Capture

Med capture-funktionen kan du lagra händelseströmmen till en Azure Blob Storage eller Data Lake Storage. Det här sättet att lagra händelser är tillförlitligt eftersom även om lagringskontot inte är tillgängligt behåller Capture dina data under en period och skriver sedan till lagringen när det är tillgängligt.

Lagringstjänster kan också erbjuda ytterligare funktioner för att analysera händelser. Genom att till exempel dra nytta av åtkomstnivåerna för ett bloblagringskonto kan du lagra händelser på en frekvent nivå för data som behöver frekvent åtkomst. Du kan använda dessa data för visualisering. Alternativt kan du lagra data på arkivnivån och hämta dem ibland i granskningssyfte.

Capture lagrar alla händelser som matas in av Event Hubs och är användbart för batchbearbetning. Du kan generera rapporter om data med hjälp av en MapReduce-funktion. Insamlade data kan också fungera som sanningskälla. Om vissa fakta missades när data aggregerades kan du referera till insamlade data.

Mer information om den här funktionen finns i Avbilda händelser via Hub eventi di Azure i Azure Blob Storage eller Azure Data Lake Storage.

Stöd för Apache Kafka-klienter

Event Hubs tillhandahåller en slutpunkt för Apache Kafka-klienter . Befintliga klienter kan uppdatera sin konfiguration så att de pekar på slutpunkten och börja skicka händelser till Event Hubs. Inga kodändringar krävs.

Mer information finns i Event Hubs för Apache Kafka.

Crossover-scenarier

I vissa fall är det fördelaktigt att kombinera två meddelandetjänster.

Genom att kombinera tjänster kan du öka effektiviteten i meddelandesystemet. I din affärstransaktion använder du till exempel Azure Service Bus köer för att hantera meddelanden. Köer som mestadels är inaktiva och tar emot meddelanden ibland är ineffektiva eftersom konsumenten ständigt söker i kön efter nya meddelanden. Du kan konfigurera en Event Grid-prenumeration med en Azure-funktion som händelsehanterare. Varje gång kön tar emot ett meddelande och det inte finns några konsumenter som lyssnar skickar Event Grid ett meddelande som anropar Azure-funktionen som tömmer kön.

Azure Service Bus till Event Grid-integrering

Mer information om hur du ansluter Service Bus till Event Grid finns i Azure Service Bus till Event Grid-integreringsöversikten.

Företagsintegreringen i Azure med hjälp av referensarkitekturen för meddelandeköer och händelser visar en implementering av Service Bus till Event Grid-integrering.

Här är ett annat exempel. Event Grid tar emot en uppsättning händelser där vissa händelser kräver ett arbetsflöde medan andra är för avisering. Meddelandemetadata anger typen av händelse. Ett sätt är att kontrollera metadata med hjälp av filtreringsfunktionen i händelseprenumerationen. Om det kräver ett arbetsflöde skickar Event Grid det till Azure Service Bus kö. Mottagarna av kön kan vidta nödvändiga åtgärder. Meddelandehändelserna skickas till Logic Apps för att skicka e-postmeddelanden med aviseringar.

Azure Event Grid till Service Bus-integrering

Tänk på dessa mönster när du implementerar asynkrona meddelanden:

  • Mönster för konkurrerande konsumenter. Flera konsumenter kan behöva konkurrera om att läsa meddelanden från en kö. Det här mönstret beskriver hur du bearbetar flera meddelanden samtidigt för att optimera dataflödet, för att förbättra skalbarheten och tillgängligheten samt för att balansera arbetsbelastningen.
  • Prioritetskömönster. I fall där affärslogik kräver att vissa meddelanden bearbetas före andra beskriver det här mönstret hur meddelanden som publiceras av en producent som har högre prioritet kan tas emot och bearbetas snabbare av en konsument än meddelanden med lägre prioritet.
  • Mönster för köbaserad belastningsutjämning. Det här mönstret använder en meddelandeförmedlare för att fungera som en buffert mellan en producent och en konsument för att minimera påverkan på tillgängligheten och svarstiden för tillfälliga tunga belastningar för båda dessa entiteter.
  • Återförsöksmönster. En producent eller konsument kanske inte kan ansluta till en kö, men orsaken till det här felet kan vara tillfällig och skickas snabbt. Det här mönstret beskriver hur du hanterar den här situationen för att öka återhämtning i ett program.
  • Scheduler Agent Supervisor Pattern. Meddelanden används ofta som en del av en arbetsflödesimplementering. Det här mönstret visar hur meddelanden kan samordna en uppsättning åtgärder i en distribuerad uppsättning tjänster och andra fjärrresurser och göra det möjligt för ett system att återställa och försöka utföra åtgärder som misslyckas igen.
  • Koreografimönster. Det här mönstret visar hur tjänster kan använda meddelanden för att styra arbetsflödet för en affärstransaktion.
  • Mönster för anspråkskontroll. Det här mönstret visar hur du delar upp ett stort meddelande i en anspråkskontroll och en nyttolast.

Gruppresurser

Jonathon Olivers blogginlägg: Idempotens

Martin Fowlers blogginlägg: Vad menar du med "Event-Driven"?