Alternativ för asynkrona meddelanden i Azure

I den här artikeln beskrivs de olika typerna av meddelanden och de entiteter som ingår i en meddelandeinfrastruktur. Baserat på kraven för varje meddelandetyp rekommenderar artikeln Azure-meddelandetjänster. Alternativen är Azure Service Bus, Event Gridoch 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 om och agera därefter. Producenten och konsumenten kan kommunicera direkt eller valfritt via en mellanliggande entitet (meddelandekoordinator). Den här artikeln fokuserar på asynkrona meddelanden med hjälp av en asynkron meddelandekö.

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 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 konsumenten/konsumenterna ska utföra en åtgärd inom omfånget för en affärstransaktion.

Ett kommando är ett högt värde-meddelande och måste levereras minst en gång. Om ett kommando förloras 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å dubbla beställningar eller faktureras två gånger.

Kommandon används ofta för att hantera arbetsflödet för en affärstransaktion i flera steg. Beroende på affärslogiken kan producenten förvänta sig att konsumenten bekräftar meddelandet och rapporterar resultatet av åtgärden. Baserat på resultatet kan producenten välja en lämplig åtgärd.

Händelser

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

Producenten (som i det här sammanhanget kallas utgivare) har inga förväntningar på att händelserna ska 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 vara medvetna om varandra.

Producenten och konsumenten är löst kopplade och hanteras oberoende av varandra. Konsumenten förväntas inte bekräfta händelsen för 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 producenten eller systemets övergripande funktioner.

Det finns två kategorier av händelser:

  • Producenten lanserar händelser för att meddela diskreta fakta. Ett vanligt användningsfall är händelseaviseringar. Till exempel Azure Resource Manager händelser när den skapar, ändrar eller tar bort resurser. En prenumerant av dessa händelser kan vara en logikapp som skickar e-postaviseringar.

  • Producenten träffar relaterade händelser i en sekvens, eller en ström av händelser, under en viss 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 tas emot. 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 prenumerant.

Publisher-Subscriber för händelsemeddelanden

Roll och fördelar med en autjämnare för meddelanden

En mellanliggande meddelandekoordinator tillhandahåller funktioner för att flytta meddelanden från producent till konsument och kan ge ytterligare fördelar.

Frånkoppling

En a broker frikopplar producenten från konsumenten i logiken som genererar och använder meddelandena. I ett komplext arbetsflöde kan koordinatorn uppmuntra verksamheten att frikopplas och samordna arbetsflödet.

En enda affärstransaktion kräver till exempel distinkta åtgärder som utförs i en affärslogiksekvens. Producenten utfärdar ett kommando som signalerar till en konsument att starta en åtgärd. Konsumenten bekräftar meddelandet i en separat kö som reserverats för att få svar från 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ön. Genom att använda meddelanden samordnar tjänsterna arbetsflödet för transaktionen sinsemellan.

Kommunikation mellan producent och konsument

En a broker för meddelanden ger tidsmässig frikoppling. Producenten och konsumenten behöver inte köras samtidigt. En producent kan skicka ett meddelande till meddelandekoordinatorn oavsett om konsumenten är tillgänglig. Omvänt begränsas inte konsumenten av producentens tillgänglighet.

Till exempel genererar användargränssnittet för en webbapp meddelanden och använder en kö som meddelandekoordinator. När det är klart kan konsumenter hämta meddelanden från kön och utföra arbetet. Tidsbestämd frikoppling hjälper användargränssnittet att hålla sig responsivt. Den blockeras inte medan meddelanden hanteras asynkront.

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

Belastningsutjämning

Producenter kan publicera ett stort antal meddelanden som används av många konsumenter. Använd en meddelandekoordinator för att distribuera bearbetning mellan 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örbättra skalbarheten och tillgängligheten och balansera arbetsbelastningen.

Belastningsutjämning

Mängden meddelanden som genereras av producenten eller en grupp av 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 det här arbetet kan en meddelandekoordinator fungera som en buffert, och konsumenter tömmer gradvis meddelanden i sin egen takt utan att stressa systemet.

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

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

Tillförlitliga meddelanden

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

Elastiska meddelanden

En meddelandekoordinator kan öka återhämtningsförmågan 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 koordinatorn.

Teknikval för en autjämnare för meddelanden

Azure tillhandahåller flera a broker-tjänster för meddelanden, var och en med en mängd 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 överföring av kommandon från producenter till konsumenter. Här är några saker att tänka på.

Pull-modell

En konsument av en Service Bus avsöker kontinuerligt Service Bus för att kontrollera om nya meddelanden är tillgängliga. Klient-SDK:erna och Azure Functions utlösaren för Service Bus abstrahera modellen. När ett nytt meddelande är tillgängligt anropas konsumentens återanrop och meddelandet skickas till konsumenten.

Garanterad leverans

Service Bus kan en konsument granska 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 Service Bus upp meddelandet så att andra användare kan hämta det. På så sätt går meddelanden inte förlorade under överföringen.

En producent kan av misstag skicka samma meddelande två gånger. Till exempel misslyckas en producentinstans när ett meddelande har skickas. En annan producent ersätter den ursprungliga instansen och skickar meddelandet igen. Azure Service Bus-köer tillhandahåller en inbyggd avd dupliceringsfunktion som identifierar och tar bort dubblettmeddelanden. Det finns fortfarande en risk 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 ska 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 som de skickas, garanterar Service Bus köer fifo(först in först ut) ordnad leverans 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 dess meddelanden hanteras av en annan konsument.

Mer information finns i Meddelandesessioner.

Meddelandepersistence

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

Kontrollpunkt för långvariga transaktioner

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 genom sessionstillståndet. 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 senaste kända kontrollpunkten för att återuppta sessionen.

Kö för dead-letter (DLQ)

En Service Bus-kö har en standardunderkö som kallas för kön för dead-letter (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 på när ett meddelande kan hamna i DLQ:

  • Ett skadligt meddelande är ett meddelande som inte kan hanteras eftersom det är felaktigt eller innehåller oväntad information. I Service Bus kan du identifiera skadligt meddelande genom att ange egenskapen MaxDeliveryCount för kön. Om antalet gånger som 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. Service Bus köer gör att producenten kan 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 bryggor för 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 vara lokalt eller i molnet) kan använda slutpunkten för Service Bus-kö 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 gör det enkelt 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. Alternativt kan en prenumeration ha filtervillkor som gör att konsumenten kan få en delmängd av meddelanden. Varje konsument hämtar meddelanden från en prenumeration på ett sätt som liknar 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önster. 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 bearbetar händelserna. Om det inte finns några prenumeranter ignoreras händelserna. Varje händelse kan ha flera prenumerationer.

Push-modell

Event Grid 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 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 också stöd för 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 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 deltagande tjänster ska skapa 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 av 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.

Innehåll i olika format laddas till exempel upp till Blob Storage. Varje gång en fil läggs till utlöses en händelse och publiceras till Event Grid. Händelseprenumerationen kan ha ett filter som endast 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 kostnad?

Motståndskraftig 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 funktioner som du kan aktivera och anpassa, till exempel återförsöksprinciper, förfallotid och dead lettering. Mer information finns i Leverans och försök igen.

Event Grid återförsöksprocessen kan hjälpa återhämtningen, men den är inte felsäker. I återförsöksprocessen kan Event Grid leverera meddelandet mer än en gång, hoppa över eller fördröja några återförsök om slutpunkten inte svarar under en längre tid. Mer information finns i Schema för återförsök och varaktighet.

Du kan bevara händelser som inte har fortsatts till ett Blob Storage-konto genom att aktivera obeskrivbar information. Det finns en fördröjning i att leverera meddelandet till bloblagringsslutpunkten och om slutpunkten inte svarar tar Event Grid bort händelsen. Mer information finns i Principer för dead letter och återförsök.

Azure Event Hubs

När du arbetar med en händelseström är Azure Event Hubs den rekommenderade meddelandekoordinatorn. I princip är det en stor buffert som kan ta emot stora mängder data med kort svarstid. Mottagna data kan läsas snabbt via samtidiga åtgärder. Du kan transformera mottagna data med valfri leverantör av realtidsanalys. Event Hubs också funktioner för 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 dataströ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 push-meddelandena 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 dataströmmen. En prenumerant hanterar markören och kan gå framåt och tillbaka i dataströmmen, välja en tidsförskjutning och spela upp en sekvens i sin takt.

Stream-processorer är prenumeranter som hämtar data 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 värden för händelsebearbetning eller genom att använda inbyggd anslutningsapp som Logic Apps för att tillhandahålla transformeringslogiken. Ett annat alternativ är att använda Azure Functions.

Partitionering

En partition är en del av händelseströmmen. Händelserna delas upp 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. Inom 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 dataströmmen kan läsas samtidigt av flera konsumenter.

Instanser av samma konsument utgör en enskild konsumentgrupp. Flera konsumentgrupper kan läsa samma dataström med olika avsikter. Anta att en händelseström har data från en temperatursensor. En konsumentgrupp kan läsa dataströmmen för att identifiera avvikelser, till exempel en topp i temperatur. En annan kan läsa samma dataströ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 en prenumerant.

Mer information om Event Hub-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.

Storage tjänster kan också erbjuda ytterligare funktioner för att analysera händelser. Genom att till exempel dra nytta av åtkomstnivåer för ett Blob Storage-konto 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 på data med hjälp av en MapReduce-funktion. Infångade data kan också fungera som sanningskälla. Om vissa fakta missades när data aggregerades kan du referera till de infångade data.

Mer information om den här funktionen finns i Capture events through Azure Event Hubs in Azure Blob Storage or 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 den 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 kan du till exempel använda Azure Service Bus köer för att hantera meddelanden. Köer som huvudsakligen är inaktiva och tar emot meddelanden är ibland ineffektiva eftersom konsumenten ständigt avsöker 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 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 to Event Grid integration overview (Översiktöver Azure Event Grid integrering).

Enterprise-integreringen i Azure med hjälp av meddelandeköer och händelsereferensarkitektur visar en implementering av Service Bus för 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 meddelanden. Meddelandets metadata anger typen av händelse. Ett sätt är att kontrollera metadata med hjälp av filtreringsfunktionen i händelseprenumerationen. Om det krävs ett arbetsflöde skickar Event Grid det till Azure Service Bus kön. Mottagarna av kön kan vidta nödvändiga åtgärder. Aviseringshändelserna skickas till Logic Apps skicka e-postmeddelanden.

Azure Event Grid till Service Bus integrering

Tänk på följande 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 förklarar hur du bearbetar flera meddelanden samtidigt för att optimera dataflödet, förbättra skalbarheten och tillgängligheten och balansera arbetsbelastningen.
  • Mönster för prioritetskö. I fall där affärslogiken kräver att vissa meddelanden bearbetas före andra beskriver det här mönstret hur meddelanden som skickas av en producent med 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 meddelandekoordinator för att fungera som en buffert mellan en producent och en konsument för att minimera påverkan på tillgänglighet och svarstider 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 snabbt passera. Det här mönstret beskriver hur du hanterar den här situationen för att lägga till återhämtning i ett program.
  • Mönster för Scheduler-agentövervakare. 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 över 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.
  • Mönster för mönster av mönster på mö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.
  • Anspråkskontrollmönster. Det här mönstret visar hur du delar upp ett stort meddelande i en anspråkskontroll och en nyttolast.

Gruppresurser

Jonathon Jonathans blogginlägg: Idempotency

Martin Fowlers blogginlägg: Vad menar du med "Händelsedriven"?