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-meddelandetjänster. Alternativen är Azure Service Bus Messaging, Azure Event Grid och Azure Event Hubs. För produktjämförelse, se Jämför meddelandetjänster.
På arkitekturnivå är ett meddelande ett datagram som skapats av en entitet (producent) för att distribuera information så att andra entiteter (konsumenter) kan känna till och agera därefter. Producenten och konsumenten kan kommunicera direkt eller valfritt via en mellanliggande entitet (meddelandekö). Den här artikeln fokuserar på asynkrona meddelanden med hjälp av en meddelandekö.
Vi kan klassificera meddelanden 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. Baserat på detta resultat kan producenten välja ett lämpligt tillvägalopp.
Event
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 resulterar 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. Producenten förväntar sig inte att konsumenten ska bekräfta händelsen tillbaka till producenten. En konsument som inte längre är intresserad av händelserna kan avbryta prenumerationen, vilket tar bort konsumenten från pipelinen utan att påverka producenten eller systemets övergripande funktionalitet.
Det finns två kategorier av händelser:
Producenten väcker evenemang för att tillkännage diskreta fakta. Ett vanligt användningsfall är händelsemeddelande. Azure Resource Manager genererar till exempel händelser när det 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 händelseström under en viss tidsperiod. Normalt används en ström för statistisk utvärdering. Utvärderingen kan ske 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 .
Roll och fördelar med en meddelandekö
En mellanliggande meddelandekö ger funktioner för att flytta meddelanden från producent till konsument och kan erbjuda fler fördelar.
Frånkoppling
En meddelandekö frikopplar producenten från konsumenten i logiken som genererar respektive använder meddelandena. I ett komplext arbetsflöde kan mäklaren 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 när du har fått svaret skickar producenten ett nytt meddelande för att starta nästa åtgärd i sekvensen. En annan konsument bearbetar det meddelandet och skickar ett slutförandemeddelande till svarskön. Med hjälp av meddelanden samordnar tjänsterna arbetsflödet för transaktionen sinsemellan.
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 meddelandekö. När konsumenten är klar kan den hämta meddelanden från kön och utföra arbetet. Tidsmässig frikoppling hjälper användargränssnittet att förbli dynamiskt. Det blockeras inte när meddelandena hanteras asynkront.
Vissa åtgärder kan ta lång tid att slutföra. När ett kommando har problem bör 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önstret Konkurrerande konsumenter förklarar hur du bearbetar flera meddelanden samtidigt för att optimera dataflödet, förbättra skalbarheten och tillgängligheten och 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 tömmer gradvis meddelanden i sin egen takt utan att betona systemet.
Det köbaserade mönstret för belastningsutjämning innehåller mer information.
Tillförlitliga meddelanden
En meddelandekö 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 konsumenterna 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 meddelandekö
Azure tillhandahåller flera tjänster för meddelandeköer, 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-meddelanden
Azure Service Bus Messaging-köer passar bra för att överföra kommandon från producenter till konsumenter. Här följer några överväganden.
Pull-modell
En konsument 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ösaren för Service Bus abstraherar den 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 meddelanden inte förlorade vid överföring.
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 de-duping-funktion 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-beställningsleverans (first-in-first-out) med hjälp av sessioner. En session kan ha ett eller flera meddelanden. Meddelandena korreleras 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 sessionstillståndsfunktionen. Tillståndsinformation registreras stegvis 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 är exempel på när ett meddelande kan hamna i DLQ:
Ett giftmeddelande är ett meddelande som inte kan hanteras eftersom det är felaktigt eller innehåller oväntad information. I Service Bus-köer kan du identifiera giftmeddelanden genom att ange egenskapen MaxDeliveryCount för kön. Om antalet gånger samma meddelande tas emot överskrider det 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 upphör att gälla 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 producenten och konsumenten (kan antingen vara lokala eller molnet) kan använda Service Bus-köslutpunkten som upphämtnings- och avlämningsplats för meddelanden.
Mönstret Meddelandebrygga är ett annat sätt att hantera dessa scenarier.
Ämnen och prenumerationer
Service Bus stöder mönstret Publisher-Subscriber 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 användare som prenumererar. En prenumeration kan också ha filtervillkor som gör att konsumenten kan hämta en delmängd meddelanden. Varje konsument hämtar meddelanden från en prenumeration på ett liknande sätt som en kö.
Mer information finns i Avsnittet om Azure Service Bus.
Azure Event Grid
Vi rekommenderar Azure Event Grid för diskreta händelser. Event Grid följer mönstret Publisher-Subscriber. När händelsekällor utlöser händelser publiceras de i 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 publicerar Event Grid händelsen till webhookens slutpunkt.
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 skapa händelser när de bearbetar sina enskilda affärsåtgärder. En webbapp visar dessa händelser. Ett sätt att utföra den här uppgiften ä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. Du anger filtren 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 utlöses och publiceras en händelse 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. Information om kostnadsöverväganden finns i Hur mycket kostar Event Grid?
Elastisk leverans
Även om 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 bokstäver. Mer information finns i Leverans av Event Grid-meddelanden 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 Schema för återförsök.
Du kan spara händelser som inte har levererats till ett bloblagringskonto genom att aktivera obeställbara bokstäver. 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 Ange plats för obeställbara bokstäver och återförsöksprincip.
Azure Event Hubs
När du arbetar med en händelseström är Azure Event Hubs den rekommenderade meddelandeköen. 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 endast till i strömmen och sorteras efter tid.
Pull-modell
Precis som Event Grid erbjuder Event Hubs även funktioner för utgivare och prenumeranter. 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 Hubs 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 omvandling 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ändelseprocessorvärden eller genom att använda inbyggda anslutningsappar som Azure 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 ordnas 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 resulterar i snabbare bearbetning eftersom strömmen kan läsas samtidigt av flera konsumenter.
Instanser av samma konsument utgör en enda 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 temperaturtoppar. En annan kan läsa samma ström för att beräkna en rullande medeltemperatur i ett tidsfönster.
Event Hubs stöder mönstret Publisher-Subscriber genom att tillåta flera konsumentgrupper. Varje konsumentgrupp är prenumerant.
Mer information om Event Hubs-partitionering finns i Partitioner.
Event Hubs Capture
Med funktionen Capture 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 Azure Event Hubs 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. Du behöver inte göra några kodändringar.
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.
Mer information om hur du ansluter Service Bus till Event Grid finns i Azure Service Bus till Event Grid-integreringsöversikt.
Företagsintegreringen med hjälp av meddelandeköer och händelsereferensarkitektur 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 att särskilja ä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ön. Mottagarna i kön kan vidta nödvändiga åtgärder. Aviseringshändelserna skickas till Logic Apps för att skicka aviseringsmeddelanden.
Relaterade mönster
Tänk på dessa mönster när du implementerar asynkrona meddelanden:
- Mönster för konkurrerande förbrukare. Flera konsumenter kan behöva konkurrera om att läsa meddelanden från en kö. Det här mönstret 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.
- Mönster för prioritetskö. För 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 med högre prioritet 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 meddelandekö 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 orsakerna till det här felet kan vara tillfälliga och skickas snabbt. Det här mönstret beskriver hur du hanterar den här situationen för att lägga till återhämtning i ett program.
- Scheduler Agent Supervisor-mönster. 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"?