Mönster för Publisher-Subscriber

Aktivera ett program för att informera flera intresserade kunder om evenemang asynkront, utan att koppla avsändarna till mottagarna.

Kallas även: Pub/sub messaging

Kontext och problem

I molnbaserade och distribuerade program behöver komponenter i systemet ofta tillhandahålla information till andra komponenter när händelser inträffar.

Asynkrona meddelanden är ett effektivt sätt att frikoppla avsändare från konsumenter och undvika att blockera avsändaren att vänta på ett svar. Men att använda en dedikerad meddelandekö för varje konsument skalas inte effektivt till många konsumenter. Dessutom kan vissa av konsumenterna bara vara intresserade av en delmängd av informationen. Hur kan avsändaren meddela händelser till alla intresserade konsumenter utan att känna till deras identiteter?

Lösning

Introducera ett asynkront meddelandeundersystem som innehåller följande:

• En kanal för indatameddelanden som används av avsändaren. Avsändaren paketera händelser i meddelanden med ett känt meddelandeformat och skickar dessa meddelanden via indatakanalen. Avsändaren i det här mönstret kallas även utgivaren.

  Kommentar

  Ett meddelande är ett datapaket. En händelse är ett meddelande som meddelar andra komponenter om en ändring eller en åtgärd som har ägt rum.

• En kanal för utdatameddelanden per konsument. Konsumenterna kallas prenumeranter.

• En mekanism för att kopiera varje meddelande från indatakanalen till utdatakanalerna för alla prenumeranter som är intresserade av meddelandet. Den här åtgärden hanteras vanligtvis av en mellanhand, till exempel en meddelandekö eller händelsebuss.

Följande diagram visar de logiska komponenterna i det här mönstret:

Pub-/undermeddelanden har följande fördelar:

• Den frikopplar undersystem som fortfarande behöver kommunicera. Undersystem kan hanteras oberoende av varandra och meddelanden kan hanteras korrekt även om en eller flera mottagare är offline.

• Det ökar skalbarheten och förbättrar avsändarens svarstider. Avsändaren kan snabbt skicka ett enda meddelande till indatakanalen och sedan återgå till sitt kärnbearbetningsansvar. Meddelandeinfrastrukturen ansvarar för att säkerställa att meddelanden levereras till intresserade prenumeranter.

• Det förbättrar tillförlitligheten. Asynkrona meddelanden hjälper program att fortsätta att köras smidigt under ökad belastning och hantera tillfälliga fel mer effektivt.

• Det möjliggör uppskjuten eller schemalagd bearbetning. Prenumeranter kan vänta med att hämta meddelanden tills det är låg belastning, eller så kan meddelanden dirigeras eller bearbetas enligt ett visst schema.

• Det möjliggör enklare integrering mellan system med olika plattformar, programmeringsspråk eller kommunikationsprotokoll, samt mellan lokala system och program som körs i molnet.

• Det underlättar asynkrona arbetsflöden i ett företag.

• Det förbättrar testbarheten. Kanaler kan övervakas och meddelanden kan inspekteras eller loggas som en del av en övergripande integrationsteststrategi.

• Det ger en uppdelning av problem för dina program. Varje program kan fokusera på sina kärnfunktioner, medan meddelandeinfrastrukturen hanterar allt som krävs för att på ett tillförlitligt sätt dirigera meddelanden till flera konsumenter.

Problem och överväganden

Tänk på följande när du bestämmer hur du ska implementera mönstret:

• Befintliga tekniker. Vi rekommenderar starkt att du använder tillgängliga meddelandeprodukter och tjänster som stöder en publiceringsprenumereringsmodell i stället för att skapa egna. Överväg att använda Service Bus, Event Hubs eller Event Grid i Azure. Andra tekniker som kan användas för pub-/undermeddelanden är Redis, RabbitMQ och Apache Kafka.

• Prenumerationshantering. Meddelandeinfrastrukturen måste tillhandahålla mekanismer som konsumenter kan använda för att prenumerera på eller avbryta prenumerationen från tillgängliga kanaler.

• Säkerhet. Anslut till alla meddelandekanaler måste begränsas av säkerhetsprinciper för att förhindra avlyssning av obehöriga användare eller program.

• Delmängder av meddelanden. Prenumeranter är vanligtvis bara intresserade av delmängden av de meddelanden som distribueras av en utgivare. Meddelandetjänster gör det ofta möjligt för prenumeranter att begränsa mängden meddelanden som tas emot av:

  • Ämnen. Varje ämne har en dedikerad utdatakanal och varje konsument kan prenumerera på alla relevanta ämnen.
  • Innehållsfiltrering. Meddelanden inspekteras och distribueras baserat på innehållet i varje meddelande. Varje prenumerant kan ange det innehåll som den är intresserad av.

• Jokerteckenprenumeranter. Överväg att låta prenumeranter prenumerera på flera ämnen via jokertecken.

• Dubbelriktad kommunikation. Kanalerna i ett publiceringsprenumerationssystem behandlas som enkelriktade. Om en specifik prenumerant behöver skicka bekräftelse eller kommunicera status tillbaka till utgivaren kan du överväga att använda mönstret För begäran/svar. Det här mönstret använder en kanal för att skicka ett meddelande till prenumeranten och en separat svarskanal för att kommunicera tillbaka till utgivaren.

• Ordningsföljd för meddelanden. Ordningen i vilken konsumentinstanser tar emot meddelanden är inte garanterad och återspeglar inte nödvändigtvis den ordning i vilken meddelandena skapades. Utforma systemet för att säkerställa att meddelandebearbetningen är idempotent för att eliminera eventuella beroenden av ordningen för meddelandehantering.

• Meddelandeprioritet. Vissa lösningar kan kräva att meddelanden bearbetas i en viss ordning. Mönstret Prioritetskö ger en mekanism för att säkerställa att specifika meddelanden levereras före andra.

• Giftmeddelanden. Ett felaktigt meddelande, eller en uppgift som kräver åtkomst till resurser som inte är tillgängliga, kan orsaka fel hos en tjänstinstans. Systemet bör förhindra att sådana meddelanden returneras till kön. Samla i stället in och lagra information om dessa meddelanden någon annanstans så att de kan analyseras om det behövs. Vissa meddelandeköer, till exempel Azure Service Bus, stöder detta via sina köfunktioner med obeställbara meddelanden.

• Upprepade meddelanden. Samma meddelande kan skickas mer än en gång. Avsändaren kan till exempel misslyckas när ett meddelande har publicerats. Sedan kan en ny instans av avsändaren starta och upprepa meddelandet. Meddelandeinfrastrukturen bör implementera duplicerad meddelandeidentifiering och borttagning (kallas även de-duping) baserat på meddelande-ID:er för att tillhandahålla leverans av meddelanden högst en gång. Om du använder meddelandeinfrastruktur som inte avduplicerar meddelanden kontrollerar du också att logiken för meddelandebearbetning är idempotent.

• Meddelandet upphör att gälla. Ett meddelande kan ha en begränsad livslängd. Om den inte bearbetas inom den här perioden kanske den inte längre är relevant och bör tas bort. En avsändare kan ange en förfallotid som en del av data i meddelandet. En mottagare kan undersöka den här informationen innan den bestämmer sig för om den affärslogik som är associerad med meddelandet ska utföras.

• Schemaläggning av meddelanden. Ett meddelande kan tillfälligt vara embargo och bör inte bearbetas förrän ett visst datum och en viss tid. Meddelandet bör inte vara tillgängligt för en mottagare förrän den här gången.

• Skala ut prenumeranter. Om en viss prenumerant inte kan hålla jämna hand med antalet meddelanden som den tar emot använder du mönstret Konkurrerande konsumenter för att skala ut det.

När du ska använda det här mönstret

Använd det här mönstret i sådana här scenarier:

• Ett program måste sända information till ett stort antal konsumenter.

• Ett program måste kommunicera med ett eller flera oberoende utvecklade program eller tjänster, som kan använda olika plattformar, programmeringsspråk och kommunikationsprotokoll.

• Ett program kan skicka information till konsumenter utan att kräva realtidssvar från konsumenterna.

• Systemen som integreras är utformade för att stödja en eventuell konsekvensmodell för deras data.

• Ett program måste kommunicera information till flera konsumenter, som kan ha olika tillgänglighetskrav eller drifttidsscheman än avsändaren.

Det här mönstret är kanske inte användbart om:

• Ett program har bara ett fåtal konsumenter som behöver väsentligt annan information än det producerande programmet.

• Ett program kräver nästan realtidsinteraktion med konsumenter.

Design av arbetsbelastning

En arkitekt bör utvärdera hur mönstret Publisher/Subscriber kan användas i arbetsbelastningens design för att uppfylla de mål och principer som beskrivs i grundpelarna i Azure Well-Architected Framework. Till exempel:

Som med alla designbeslut bör du överväga eventuella kompromisser mot målen för de andra pelarna som kan införas med det här mönstret.

Exempel

Följande diagram visar en arkitektur för företagsintegrering som använder Service Bus för att samordna arbetsflöden och Event Grid för att meddela undersystem om händelser som inträffar. Mer information finns i Enterprise-integrering i Azure med hjälp av meddelandeköer och händelser.

Nästa steg

Följande vägledning kan vara relevant när du implementerar det här mönstret:

• Välj mellan Azure-tjänster som levererar meddelanden.

• Asynkron primer för meddelanden. Meddelandeköer är mekanism för asynkron kommunikation. Om en konsumenttjänst behöver skicka ett svar till ett program, kan det vara nödvändigt att implementera svarsmeddelanden av någon typ. Primern för asynkrona meddelanden tillhandahåller information om hur du implementerar begäran-/svarsmeddelanden genom att använda meddelandeköer.

Följande mönster kan vara relevanta när du implementerar det här mönstret:

• Observatörsmönster. Mönstret Publish-Subscribe bygger på Observer-mönstret genom att frånkoppla ämnen från observatörer via asynkrona meddelanden.

• Meddelandekömönster. Många meddelandeundersystem som stöder en publiceringsprenumereringsmodell implementeras via en meddelandekö.

Det här blogginlägget beskriver olika sätt att hantera meddelanden som kommer i fel ordning.

Relaterade resurser

• Den händelsedrivna arkitekturstilen är en arkitekturstil som använder pub-/sub-meddelanden.
• Idempotent meddelandebearbetning
• Enterprise-integrering i Azure med hjälp av meddelandeköer och händelser