Model mostu pro zasílání zpráv

Tento článek popisuje model mostu zasílání zpráv, což je technika, kterou můžete použít k integraci různorodých systémů, které jsou založené na různých infrastrukturách zasílání zpráv.

Kontext a problém

Mnoho organizací a úloh může neúmyslně mít IT systémy, které používají více infrastruktur zasílání zpráv, jako je Microsoft Message Queueing (MSMQ), RabbitMQ, Azure Service Bus a Amazon SQS. K tomuto problému může dojít kvůli fúzím, akvizicím nebo kvůli rozšíření stávajících místních systémů na komponenty hostované v cloudu za účelem úspory nákladů a snadné údržby.

Vývojáři můžou tento problém vyřešit úpravou integrovaných systémů pro komunikaci pomocí webových služeb založených na protokolu HTTP. Tento přístup má však nevýhody, mezi které patří:

• Systémy musí být upraveny přidáním klienta HTTP na jedné straně a obslužnou rutinou požadavku HTTP na druhé. Systémy se pak musí znovu otestovat a znovu nasadit.
• Koncové body HTTP musí být hostované, což zvyšuje složitost při zabezpečení a vysoké dostupnosti webových služeb.
• Časté problémy s připojením k síti, které vyžadují vlastní mechanismy opakování.

Řešení

Pokud se systémy integrované skládají ze součástí, které komunikují výměnou zpráv, model mostu zasílání zpráv zlepšuje integraci a snižuje nevýhody.

V tomto scénáři se každý systém připojí k jedné infrastruktuře zasílání zpráv. Pokud chcete integrovat různé infrastruktury zasílání zpráv, zavedněte komponentu mostu, která se připojuje ke dvěma nebo více infrastrukturám zasílání zpráv najednou. Most načítá zprávy z jednoho a nasdílí je do druhé beze změny datové části.

Integrované systémy nemusí rozpoznávat ostatní ani most. Systém odesílatele je nakonfigurovaný tak, aby odesílal konkrétní zprávy do určené fronty ve své nativní infrastruktuře zasílání zpráv. Most tyto zprávy převezme a přepošlí je do jiné fronty v jiné infrastruktuře zasílání zpráv, kde je systém příjemce vybere.

Zaměstnanecké výhody

• Systémy integrované prostřednictvím mostu zasílání zpráv se nemusí upravovat. V ideálním případě koncové body neví, že se zprávy přemístit.
• Integrace je spolehlivější v porovnání s alternativou HTTP kvůli zárukě alespoň jednoho mechanismu doručování zpráv.
• Scénáře migrace můžou být flexibilnější. Koncové body je například možné migrovat z jedné infrastruktury zasílání zpráv do druhé, protože plán povoluje místo všech najednou.

Nevýhody

• Pokročilé funkce jedné nebo obou technologií zasílání zpráv nemusí být na přeměněné trase dostupné.
• Přemostěná trasa musí zvážit omezení obou technologií. Například maximální velikost zprávy může být 4 MB v MSMQ, ale pouze 64 kB ve frontách Azure Storage.

Problémy a důležité informace

Při implementaci modelu mostu zasílání zpráv zvažte následující body:

• Pokud jeden z integrovaných systémů spoléhá na distribuované transakce, například DTC (Microsoft Distributed Transaction Coordinator), pro správnost, musíte implementovat mechanismus odstranění duplicit v mostu.

• Pokud některý z integrovaných systémů nepoužívá žádnou infrastrukturu zasílání zpráv a nedá se upravit, můžete vytvořit most pro zasílání zpráv mezi infrastrukturou používanou jiným systémem a emulovanou frontou SQL Serveru. Starší systém může odesílat zprávy pomocí funkce zachytávání dat změn pro SQL Server k odeslání změn do vyhrazené tabulky fronty. Tento most může tyto zprávy předávat skutečné infrastruktuře zasílání zpráv.

• V každé infrastruktuře zasílání zpráv můžete použít jednu frontu určenou jako přemostění fronty. V této topologii nakonfigurujte odesílající systém tak, aby používal tuto konkrétní frontu jako cíl pro typy zpráv odesílaných do jiného systému. V každé infrastruktuře zasílání zpráv můžete také použít několik dvojic front, takže odesílatel o mostu neví. Pro každou cílovou frontu v infrastruktuře zasílání zpráv cílového systému se vytvoří stínová fronta . Přemostivá zprávy mezi stínovými frontami a jejich protějšky.

• Aby bylo možné splnit požadované smlouvy o úrovni služeb (SLA) dostupnosti, možná budete muset škálovat most zasílání zpráv pomocí přístupu Konkurující spotřebitelé .

• Běžné komponenty zpracování zpráv používají vzor opakování ke zpracování přechodných selhání. Limit čítače opakování umožňuje komponentám detekovat otrávené zprávy a odebrat je z fronty a odblokovat zpracování. Most může vyžadovat jinou zásadu opakování, aby se v případě selhání infrastruktury nepravdě identifikovaly zprávy jako otrávené. K pozastavení přeposílání můžete použít model Jistič .

Kdy se má tento model použít

Model mostu pro zasílání zpráv použijte, když potřebujete:

• Integrujte stávající systémy s minimální potřebou úprav.
• Integrujte starší verze aplikací, které nemůžou používat jiné technologie zasílání zpráv.
• Rozšíření stávajících místních aplikací o komponenty hostované v cloudu
• Připojte geograficky distribuované systémy, pokud připojení k internetu není stabilní.
• Migrujte jeden distribuovaný systém z jedné infrastruktury zasílání zpráv do jiného, aniž byste museli migrovat celý systém v jednom úsilí.

Tento vzor nemusí být vhodný, pokud:

• Minimálně jeden ze zahrnutých systémů spoléhá na funkci jedné infrastruktury zasílání zpráv, která není v druhé.
• Integrace je v podstatě synchronní a iniciační systém vyžaduje okamžitou reakci.
• Integrace má specifické funkční nebo nefunkční požadavky, jako je zabezpečení nebo ochrana osobních údajů.
• Objem dat pro integraci překračuje kapacitu systému zasílání zpráv nebo představuje nákladné řešení problému.

Návrh úloh

Architekt by měl vyhodnotit způsob použití modelu mostu zasílání zpráv v návrhu úloh k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Příklad:

Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.

Příklad

Aplikace je napsaná v rozhraní .NET Framework pro správu plánování zaměstnanců hostovaných místně. Aplikace je dobře strukturovaná s samostatnými komponentami komunikujícími přes MSMQ. Aplikace funguje a tým úloh nemá v úmyslu ji přepisovat. Aby bylo možné splnit obchodní potřebu, je potřeba vytvořit nového uživatele dat plánování a strategie IT vyzývá k vytvoření nového softwaru jako aplikací nativních pro cloud, aby se optimalizovaly náklady a doba doručení.

Asynchronní architektura založená na frontě pracovala pro tým úloh v minulosti, takže tým bude používat stejný přístup k architektuře, ale s moderní technologií Service Bus. Tým úloh nechce zavést synchronní komunikaci mezi cloudem a místním nasazením, aby se zmírnit latence nebo nedostupnost jednoho, který má vliv na druhý.

Tým se rozhodne použít model mostu zasílání zpráv k propojení těchto dvou systémů. Vzor se skládá ze dvou částí. Jedna část přijímá zprávy z existující fronty MSMQ a předává je do služby Service Bus. Druhá část přebírá zprávy ze služby Service Bus a předává je do existující fronty MSMQ.

Když implementační tým použije tento přístup, využívá stávající infrastrukturu v existující aplikaci k integraci s novými komponentami. Stávající aplikace neví, že nové komponenty jsou hostované v Azure. Podobně nové komponenty komunikují se starší aplikací stejným způsobem, jakým komunikují mezi sebou, tím, že odesílají zprávy service Bus. Most přeposílá zprávy mezi těmito dvěma systémy.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

• Rob Bagby | Hlavní zájemce o obsah architektury objektu zabezpečení
• Kyle Baley | Softwarový inženýr
• Udi Dahan | Zakladatel a generální ředitel konkrétního softwaru
• Chad Kittel | Hlavní softwarový inženýr
• Bryan Lamos | Vztahy s vývojáři
• Szymon Pobiega | Inženýr

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

• Popis vzoru mostu pro zasílání zpráv od komunity podnikových integračních vzorů
• Naučte se implementovat most pro zasílání zpráv v architektuře Spring Java.
• K přemíscení technologií zasílání zpráv s podporou AMQP je možné použít most QPid.
• Most zasílání zpráv NServiceBus je implementace mostu fronty do fronty, která podporuje celou řadu infrastruktur zasílání zpráv, včetně MSMQ, Service Bus a Azure Queue Storage.
• NServiceBus.Router je opensourcový projekt, který implementuje model mostu zasílání zpráv. Umožňuje také přemostění více než dvou technologií v jedné instanci a má pokročilé možnosti směrování zpráv.

Související prostředky

• Model Konkurenční spotřebitelé zajišťuje, že implementace mostu zasílání zpráv dokáže zvládnout zatížení.
• Model Opakování umožňuje mostu zasílání zpráv zpracovávat přechodné chyby.
• Model Jistič šetří prostředky v případech, kdy dojde k výpadku na obou stranách mostu.