Mönster för meddelandebrygga

Den här artikeln beskriver mönstret Meddelandebrygga, som är en teknik som du kan använda för att integrera olika system som bygger på olika meddelandeinfrastrukturer.

Kontext och problem

Många organisationer och arbetsbelastningar kan oavsiktligt ha IT-system som använder flera meddelandeinfrastrukturer som Microsoft Message Queueing (MSMQ), RabbitMQ, Azure Service Bus och Amazon SQS. Det här problemet kan uppstå på grund av sammanslagningar, förvärv eller på grund av att befintliga lokala system utökas till molnbaserade komponenter för kostnadseffektivitet och enkelt underhåll.

Utvecklare kan hantera den här utmaningen genom att ändra de system som integreras för att kommunicera med hjälp av HTTP-baserade webbtjänster. Den här metoden har dock nackdelar, bland annat:

• Systemen måste ändras genom att lägga till en HTTP-klient på ena sidan och en HTTP-begärandehanterare på den andra. Systemen måste sedan testas på nytt och distribueras om.
• HTTP-slutpunkter måste vara värdbaserade, vilket ökar komplexiteten när du gör webbtjänster säkra och mycket tillgängliga.
• Frekventa problem med nätverksanslutningar som kräver anpassade återförsöksmekanismer.

Lösning

Om systemen som integreras består av komponenter som kommunicerar genom att utbyta meddelanden, förbättrar mönstret meddelandebrygga integreringen och minskar nackdelarna.

I det här scenariot ansluter varje system till en meddelandeinfrastruktur. Om du vill integrera i olika meddelandeinfrastrukturer introducerar du en brokomponent som ansluter till två eller flera meddelandeinfrastrukturer samtidigt. Bryggan hämtar meddelanden från en och skickar dem till den andra utan att ändra nyttolasten.

Systemen som integreras behöver inte känna igen de andra eller bryggan. Avsändarsystemet är konfigurerat för att skicka specifika meddelanden till en angiven kö i dess interna meddelandeinfrastruktur. Bryggan hämtar dessa meddelanden och vidarebefordrar dem till en annan kö i en annan meddelandeinfrastruktur där mottagarsystemet hämtar dem.

Förmåner

• Systemen som integreras via Meddelandebrygga behöver inte ändras. Helst är slutpunkterna inte medvetna om att meddelandena är bryggade.
• Integreringen är mer tillförlitlig jämfört med HTTP-alternativet på grund av garantin för meddelandeleverans minst en gång.
• Migreringsscenarier kan vara mer flexibla. Slutpunkter kan till exempel migreras från en meddelandeinfrastruktur till en annan eftersom schemat tillåter i stället för alla samtidigt.

Nackdelar

• Avancerade funktioner i en eller båda meddelandeteknikerna kanske inte är tillgängliga på den bryggda vägen.
• Den överbryggade vägen måste ta hänsyn till båda teknikernas begränsningar. Den maximala meddelandestorleken kan till exempel vara 4 MB i MSMQ men endast 64 KB i Azure Storage-köer.

Problem och överväganden

Tänk på följande när du implementerar mönstret Meddelandebrygga:

• Om ett av de integrerade systemen förlitar sig på distribuerade transaktioner, till exempel Microsoft Distributed Transaction Coordinator (DTC), måste du implementera en dedupliceringsmekanism i bryggan för korrekthet.

• Om ett av systemen som integreras inte använder någon meddelandeinfrastruktur och inte kan ändras kan du skapa meddelandebryggans mellan infrastrukturen som används av det andra systemet och en SQL Server-emulerad kö. Det äldre systemet kan skicka meddelanden med hjälp av funktionen för ändringsdatainsamling för SQL Server för att skicka ändringarna till en dedikerad kötabell. Bryggan kan vidarebefordra dessa meddelanden till den faktiska meddelandeinfrastrukturen.

• Du kan använda en enda kö i varje meddelandeinfrastruktur, som är avsedd som bryggningskö. I den här topologin konfigurerar du det sändande systemet så att det använder den specifika kön som mål för meddelandetyper som skickas till det andra systemet. Du kan också använda flera par köer i varje meddelandeinfrastruktur, så att avsändaren inte känner till bryggan. En skuggkö skapas för varje målkö i målsystemets meddelandeinfrastruktur. Bryggan vidarebefordrar meddelanden mellan skuggköerna och deras motsvarigheter.

• För att uppfylla de önskade serviceavtalen (SLA) för tillgänglighet kan du behöva skala ut meddelandebryggorna med hjälp av metoden Konkurrerande konsumenter .

• Vanliga komponenter för meddelandebearbetning använder mönstret Försök igen för att hantera tillfälliga fel. Gränsen för återförsöksräknare gör det möjligt för komponenter att identifiera giftmeddelanden och ta bort dem från kön för att avblockera bearbetning. Bryggan kan kräva en annan återförsöksprincip för att förhindra att meddelanden felaktigt identifieras som gift om ett infrastrukturfel inträffar. Du kan använda kretsbrytarmönstret för att pausa vidarebefordran.

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

Använd mönstret Meddelandebrygga när du behöver:

• Integrera befintliga system med minimalt behov av ändringar.
• Integrera äldre program som inte kan använda andra meddelandetekniker.
• Utöka befintliga lokala program med molnbaserade komponenter.
• Anslut geo-distribuerade system när Internetanslutningen inte är stabil.
• Migrera ett enda distribuerat system från en meddelandeinfrastruktur till en annan stegvis utan att behöva migrera hela systemet i ett enda försök.

Det här mönstret kanske inte är lämpligt om:

• Minst ett av de berörda systemen förlitar sig på en funktion i en meddelandeinfrastruktur som inte finns i den andra.
• Integreringen är synkron och det inledande systemet kräver omedelbara svar.
• Integreringen har specifika funktionella eller icke-funktionella krav, till exempel säkerhets- eller sekretessproblem.
• Mängden data för integreringen överskrider meddelandesystemets kapacitet eller gör meddelanden till en dyr lösning på problemet.

Design av arbetsbelastning

En arkitekt bör utvärdera hur mönstret Messaging Bridge 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

Det finns ett program skrivet i ett .NET-ramverk för att hantera schemaläggning av anställda lokalt. Programmet är välstrukturerat med separata komponenter som kommunicerar via MSMQ. Programmet fungerar och arbetsbelastningsteamet har inte för avsikt att skriva om det. En ny konsument av schemaläggningsdata måste skapas för att uppfylla ett affärsbehov, och IT-strategin kräver att ny programvara skapas som molnbaserade program för att optimera kostnaderna och leveranstiden.

Den asynkrona köbaserade arkitekturen fungerade tidigare för arbetsbelastningsteamet, så teamet kommer att använda samma arkitekturmetod men med den moderna tekniken Service Bus. Arbetsbelastningsteamet vill inte införa synkron kommunikation mellan molnet och den lokala distributionen för att minska svarstiden eller otillgängligheten hos den ena som påverkar den andra.

Teamet bestämmer sig för att använda mönstret Messaging Bridge för att ansluta de två systemen. Mönstret består av två delar. En del tar emot meddelanden från den befintliga MSMQ-kön och vidarebefordrar dem till Service Bus. Den andra delen tar meddelanden från Service Bus och vidarebefordrar dem till den befintliga MSMQ-kön.

När implementeringsteamet använder den här metoden använder de befintlig infrastruktur i det befintliga programmet för att integrera med de nya komponenterna. Det befintliga programmet är inte medvetet om att de nya komponenterna finns i Azure. På samma sätt kommunicerar de nya komponenterna med det äldre programmet på samma sätt som de kommunicerar sinsemellan genom att skicka Service Bus-meddelanden. Bryggan vidarebefordrar meddelanden mellan de två systemen.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

• Rob Bagby | Innehållsledare för huvudarkitektur
• Kyle Baley | Programvarutekniker
• Udi Dahan | Grundare och VD för särskild programvara
• Chad Kittel | Huvudprogramtekniker
• Bryan Lamos | Utvecklarrelationer
• Szymon Pobiega | Ingenjör

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

• Beskrivning av meddelandebryggor från communityn för företagsintegreringsmönster.
• Lär dig hur du implementerar en meddelandebrygga i Spring Java-ramverket.
• QPid-brygga kan användas för att överbrygga AMQP-aktiverade meddelandetekniker.
• NServiceBus Messaging Bridge är en .NET-implementering av en kö-till-kö-brygga som stöder en rad olika meddelandeinfrastrukturer, inklusive MSMQ, Service Bus och Azure Queue Storage.
• NServiceBus.Router är ett projekt med öppen källkod som implementerar mönstret Meddelandebrygga. Det möjliggör också bryggning av fler än två tekniker i en enda instans och har avancerade funktioner för meddelandedirigering.

Relaterade resurser

• Mönstret Konkurrerande konsumenter säkerställer att implementeringen av Meddelandebrygga kan hantera belastningen.
• Med återförsöksmönstret kan Meddelandebryggorna hantera tillfälliga fel.
• Kretsbrytarmönstret sparar resurser när endera sidan av bryggan upplever stilleståndstid.