Publisher-Subscriber mönster
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 kanske vissa av konsumenterna bara är 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 inkommande meddelanden som används av avsändaren. Avsändaren paketerar 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.
Anteckning
Ett meddelande är ett datapaket. En händelse är ett meddelande som meddelar andra komponenter om en ändring eller en åtgärd som har vidtagits.
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 meddelandekoordinator eller händelsebuss.
Följande diagram visar de logiska komponenterna i det här mönstret:
Pub/sub-meddelanden 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 ökade belastningar och hantera tillfälliga fel mer effektivt.
Det möjliggör uppskjuten eller schemalagd bearbetning. Prenumeranter kan vänta på att hämta meddelanden till tider med låg belastning, eller så kan meddelanden dirigeras eller bearbetas enligt ett visst schema.
Det möjliggör enklare integrering mellan system som använder 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 strategi för integreringstest.
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 tillförlitligt 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:
Befintlig teknik. Vi rekommenderar starkt att du använder tillgängliga meddelandeprodukter och tjänster som stöder en publicera/prenumerera-modell i stället för att skapa egna. I Azure bör du överväga att använda Service Bus, Event Hubs eller Event Grid. Andra tekniker som kan användas för pub/sub-meddelanden ä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 på tillgängliga kanaler.
Säkerhet. Anslutning till en meddelandekanal måste begränsas av säkerhetsprincipen för att förhindra avlyssning av obehöriga användare eller program.
Delmängder av meddelanden. Prenumeranter är vanligtvis bara intresserade av en delmängd av meddelanden som distribueras av en utgivare. Meddelandetjänster tillåter ofta prenumeranter att begränsa uppsättningen 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 tillåta prenumeranter att prenumerera på flera ämnen via jokertecken.
Dubbelriktad kommunikation. Kanaler i ett publish-subscribe-system behandlas som enkelriktade. Om en specifik prenumerant behöver skicka bekräftelse eller skicka status tillbaka till utgivaren kan du överväga att använda mönstret 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 som meddelandena skapades i. Utforma systemet så att meddelandebearbetningen är idempotent för att eliminera eventuella beroenden av meddelandehanteringens ordning.
Meddelandeprioritet. Vissa lösningar kan kräva att meddelanden bearbetas i en viss ordning. Mönstret Prioritetskö tillhandahåller en mekanism för att se till att specifika meddelanden levereras före andra.
Skadligt meddelande. 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 vid behov.
Upprepade meddelanden. Samma meddelande kan skickas mer än en gång. Avsändaren kan till exempel misslyckas efter att ha skickat ett meddelande. Sedan kan en ny instans av avsändaren starta och upprepa meddelandet. Meddelandeinfrastrukturen bör implementera identifiering och borttagning av duplicerade meddelanden (kallas även avdubbning) baserat på meddelande-ID:n för att tillhandahålla leverans av meddelanden högst en gång.
Förfallodatum för meddelanden. 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 om den affärslogik som är associerad med meddelandet ska utföras.
Schemaläggning av meddelanden. Ett meddelande kan tillfälligt vara omedigt 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.
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 svar i realtid från konsumenterna.
De system som integreras är utformade för att stödja en slutlig konsekvensmodell för sina 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 betydligt annan information än produktionsprogrammet.
Ett program kräver nära realtidsinteraktion med konsumenter.
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 riktlinjer kan vara relevanta när du implementerar det här mönstret:
Det händelsedrivna arkitekturformatet är ett arkitekturformat som använder pub/sub-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.
Närliggande information
Följande mönster kan vara relevanta när du implementerar det här mönstret:
Övervakningsmönster. Mönstret Publish-Subscribe bygger på övervakningsmönstret genom att frikoppla ämnen från observerare via asynkrona meddelanden.
Mönster för autjämning av meddelanden. Många meddelandeundersystem som stöder en publicera-prenumerera-modell implementeras via en a broker för meddelanden.