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

Azure Service Bus

Propojte systémy pro zasílání zpráv založené na různých infrastrukturách pro zasílání zpráv a předávejte mezi nimi zprávy. Tento přístup umožňuje integrovat různorodé systémy beze změny samotných systémů.

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 tak, že se na jedné straně přidá klient HTTP a na druhé obslužná rutina pro zpracování požadavků HTTP. 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 systému a přenese je do druhého systému 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šle je do jiné fronty v jiné infrastruktuře pro zasílání zpráv, kde je systém příjemce přijme.

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ě si koncové body nejsou vědomy toho, že jsou zprávy přemostěny.
• 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é, jak to časový harmonogram dovolí, 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 (služba MS 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í změn dat pro SQL Server, aby byly změny odeslány 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á fronta. 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řesměruje zprávy mezi stínovými frontami a jejich protějšky.

• Aby bylo možné splnit požadované cíle úrovně dostupnosti služeb, možná budete muset škálovat Messaging Bridge pomocí metody Konkurující spotřebitelé.

• Běžné komponenty zpracování zpráv používají vzorec 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 vzor Circuit Breaker.

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:

Pilíř	Jak tento model podporuje cíle pilíře
Optimalizace nákladů se zaměřuje na udržení a zlepšení návratnosti vašich úloh.	Tento zprostředkující krok může prodloužit životnost stávajícího systému, aniž by bylo nutné přepisovat, protože umožňuje interoperabilitu se systémy, které používají jinou technologii zasílání zpráv nebo událostí. - CO:07 Náklady na komponenty
Efektivita provozu pomáhá poskytovat kvalitu úloh prostřednictvím standardizovaných procesů a týmové soudržnosti.	Toto oddělení závislostí poskytuje flexibilitu při přechodu od jedné technologie zasílání zpráv a událostí k jiné ve vašem úkolu nebo když máte různorodé požadavky vyplývající z externích závislostí. - OE:06 Nasazení změn úloh

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

K dispozici je aplikace .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 neplánuje zavedení synchronní komunikace mezi cloudem a místním nasazením, aby se zmírnila latence nebo nedostupnost jednoho, což může mít 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í vývojář obsahu – Vzory a postupy Azure
• Kyle Baley | Softwarový inženýr
• Udi Dahan | Zakladatel a generální ředitel konkrétního softwaru
• Chad Kittel | Hlavní softwarový inženýr – Vzory a postupy Azure
• Bryan Lamos | Vývojář obsahu – Vzory a postupy Azure
• Szymon Pobiega | Inženýr

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

Další kroky

• Popis vzoru Messaging Bridge od komunity podnikových integračních vzorů
• Naučte se implementovat Messaging Bridge v prostředí Spring Java.
• QPid most lze použít k propojení technologií zasílání zpráv s podporou AMQP.
• NServiceBus Messaging Bridge je implementace mostu pro propojení front na 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.

Propojte systémy pro zasílání zpráv založené na různých infrastrukturách pro zasílání zpráv a předávejte mezi nimi zprávy. Tento přístup umožňuje integrovat různorodé systémy beze změny samotných systémů.

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 tak, že se na jedné straně přidá klient HTTP a na druhé obslužná rutina pro zpracování požadavků HTTP. 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 systému a přenese je do druhého systému 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šle je do jiné fronty v jiné infrastruktuře pro zasílání zpráv, kde je systém příjemce přijme.

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ě si koncové body nejsou vědomy toho, že jsou zprávy přemostěny.
• 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é, jak to časový harmonogram dovolí, 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 (služba MS 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í změn dat pro SQL Server, aby byly změny odeslány 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á fronta. 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řesměruje zprávy mezi stínovými frontami a jejich protějšky.

• Aby bylo možné splnit požadované cíle úrovně dostupnosti služeb, možná budete muset škálovat Messaging Bridge pomocí metody Konkurující spotřebitelé.

• Běžné komponenty zpracování zpráv používají vzorec 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 vzor Circuit Breaker.

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:

Pilíř	Jak tento model podporuje cíle pilíře
Optimalizace nákladů se zaměřuje na udržení a zlepšení návratnosti vašich úloh.	Tento zprostředkující krok může prodloužit životnost stávajícího systému, aniž by bylo nutné přepisovat, protože umožňuje interoperabilitu se systémy, které používají jinou technologii zasílání zpráv nebo událostí. - CO:07 Náklady na komponenty
Efektivita provozu pomáhá poskytovat kvalitu úloh prostřednictvím standardizovaných procesů a týmové soudržnosti.	Toto oddělení závislostí poskytuje flexibilitu při přechodu od jedné technologie zasílání zpráv a událostí k jiné ve vašem úkolu nebo když máte různorodé požadavky vyplývající z externích závislostí. - OE:06 Nasazení změn úloh

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

K dispozici je aplikace .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 neplánuje zavedení synchronní komunikace mezi cloudem a místním nasazením, aby se zmírnila latence nebo nedostupnost jednoho, což může mít 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í vývojář obsahu – Vzory a postupy Azure
• Kyle Baley | Softwarový inženýr
• Udi Dahan | Zakladatel a generální ředitel konkrétního softwaru
• Chad Kittel | Hlavní softwarový inženýr – Vzory a postupy Azure
• Bryan Lamos | Vývojář obsahu – Vzory a postupy Azure
• Szymon Pobiega | Inženýr

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

Další kroky

• Popis vzoru Messaging Bridge od komunity podnikových integračních vzorů
• Naučte se implementovat Messaging Bridge v prostředí Spring Java.
• QPid most lze použít k propojení technologií zasílání zpráv s podporou AMQP.
• NServiceBus Messaging Bridge je implementace mostu pro propojení front na 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.