Wzorzec mostka obsługi komunikatów

Azure Service Bus

Łączenie systemów obsługi komunikatów opartych na różnych infrastrukturach obsługi komunikatów i przekazywanie komunikatów między nimi. Takie podejście umożliwia integrację różnych systemów bez konieczności modyfikowania samych systemów.

Kontekst i problem

Wiele organizacji i obciążeń może przypadkowo mieć systemy IT korzystające z wielu infrastruktur obsługi komunikatów, takich jak Microsoft Message Queueing (MSMQ), RabbitMQ, Azure Service Bus i Amazon SQS. Ten problem może wystąpić z powodu fuzji, przejęć lub rozszerzenia bieżących systemów lokalnych na składniki hostowane w chmurze pod kątem efektywności kosztowej i łatwości konserwacji.

Deweloperzy mogą rozwiązać to wyzwanie, modyfikując zintegrowane systemy w celu komunikowania się przy użyciu usług internetowych opartych na protokole HTTP. Jednak takie podejście ma wady, w tym:

• Systemy muszą być modyfikowane przez dodanie klienta HTTP po jednej stronie i program obsługi żądań HTTP z drugiej strony. Następnie należy ponownie przetestować i ponownie wdrożyć systemy.
• Punkty końcowe HTTP muszą być hostowane, co zwiększa złożoność podczas zabezpieczania i wysokiej dostępności usług internetowych.
• Częste problemy z łącznością sieciową, które wymagają niestandardowych mechanizmów ponawiania prób.

Rozwiązanie

Jeśli zintegrowane systemy składają się ze składników komunikujących się przez wymianę komunikatów, wzorzec mostka obsługi komunikatów poprawia integrację i zmniejsza wady.

W tym scenariuszu każdy system łączy się z jedną infrastrukturą obsługi komunikatów. Aby zintegrować różne infrastruktury obsługi komunikatów, należy wprowadzić składnik mostka, który łączy się z co najmniej dwiema infrastrukturami obsługi komunikatów w tym samym czasie. Most ściąga komunikaty z jednego i wypycha je do drugiego bez zmiany ładunku.

Zintegrowane systemy nie muszą rozpoznawać innych ani mostów. System nadawcy jest skonfigurowany do wysyłania określonych komunikatów do wyznaczonej kolejki w natywnej infrastrukturze obsługi komunikatów. Mostek pobiera te komunikaty i przekazuje je do innej kolejki w alternatywnej infrastrukturze komunikatowej, gdzie system odbiorcy je pobiera.

Świadczenia

• Systemy zintegrowane za pośrednictwem mostka obsługi komunikatów nie muszą być modyfikowane. W idealnym przypadku punkty końcowe nie wiedzą, że komunikaty są łączone.
• Integracja jest bardziej niezawodna w porównaniu z alternatywą HTTP dzięki gwarancji mechanizmu dostarczania wiadomości co najmniej raz.
• Scenariusze migracji mogą być bardziej elastyczne. Na przykład punkty końcowe można migrować z jednej infrastruktury obsługi komunikatów do innej w miarę możliwości harmonogramu, zamiast wszystkich jednocześnie.

Wady i ograniczenia

• Zaawansowane funkcje jednej lub obu technologii obsługi komunikatów mogą nie być dostępne na trasie mostkowanej.
• Trasa mostkowana musi uwzględniać ograniczenia obu technologii. Na przykład maksymalny rozmiar komunikatu może wynosić 4 MB w msMQ, ale tylko 64 KB w kolejkach usługi Azure Storage.

Problemy i kwestie do rozważenia

Podczas implementowania wzorca mostka obsługi komunikatów należy wziąć pod uwagę następujące kwestie:

• Jeśli jeden ze zintegrowanych systemów opiera się na transakcjach rozproszonych, takich jak Microsoft Distributed Transaction Coordinator (DTC), dla zapewnienia poprawnego działania, należy zaimplementować mechanizm deduplikacji w moście.

• Jeśli jeden ze zintegrowanych systemów nie korzysta z żadnej infrastruktury obsługi komunikatów i nie można go modyfikować, możesz utworzyć mostek obsługi komunikatów między infrastrukturą używaną przez inny system i kolejką emulowaną przez program SQL Server. Starszy system może wysyłać komunikaty przy użyciu funkcji przechwytywania zmian danych dla programu SQL Server w celu wypychania zmian do dedykowanej tabeli kolejek. Mostek może przekazywać te komunikaty do rzeczywistej infrastruktury obsługi komunikatów.

• W każdej infrastrukturze obsługi komunikatów można użyć jednej kolejki wyznaczonej jako kolejka mostkowa. W tej topologii skonfiguruj system wysyłania tak, aby używał tej konkretnej kolejki jako miejsca docelowego dla typów komunikatów wysyłanych do innego systemu. Można również używać wielu par kolejek w każdej infrastrukturze przesyłu wiadomości, więc nadawca nie jest świadomy mostka. Kolejka cieni jest tworzona dla każdej kolejki docelowej w infrastrukturze obsługi komunikatów systemu docelowego. Most przekazuje komunikaty między kolejkami cieni a ich odpowiednikami.

• W celu spełnienia żądanych celów dotyczących poziomów usług dostępności (SLO) może być konieczne skalowanie w poziomie mostka komunikacyjnego przy użyciu podejścia konkurencyjnych odbiorców.

• Regularne składniki przetwarzania komunikatów używają wzorca ponawiania do obsługi błędów przejściowych. Limit licznika ponawiania umożliwia składnikom wykrywanie zatrutych komunikatów i usuwanie ich z kolejki w celu odblokowania przetwarzania. Most może wymagać innych zasad ponawiania prób, aby zapobiec fałszywej identyfikacji komunikatów jako trucizny, jeśli wystąpi awaria infrastruktury. Aby wstrzymać przekazywanie, możesz użyć wzorca Circuit Breaker.

• Uwzględnij wiadomości w trakcie przesyłania podczas przyrostowej migracji endpointów. Komunikaty, które oczekują już w kolejce w starej infrastrukturze, w tym komunikaty w kolejce błędów oczekujące na ponowną próbę, muszą nadal docierać do punktu końcowego po przeniesieniu. Zachowaj mostek do momentu dostarczenia tych komunikatów, a nie tylko do momentu przeniesienia ostatniego punktu końcowego. Aby zapoznać się z przykładem krok po kroku, zobacz migrowanie do innego transportu przy użyciu mostka komunikatów NServiceBus.

Kiedy używać tego wzorca

Użyj wzorca mostka obsługi komunikatów, jeśli musisz:

• Zintegruj istniejące systemy z minimalnym zapotrzebowaniem na modyfikację.
• Integrowanie starszych aplikacji, które nie mogą korzystać z innych technologii obsługi komunikatów.
• Rozszerzanie istniejących aplikacji lokalnych przy użyciu składników hostowanych w chmurze.
• Połącz systemy rozproszone geograficznie, gdy połączenie internetowe nie jest stabilne.
• Migrowanie pojedynczego systemu rozproszonego z jednej infrastruktury obsługi komunikatów do innej przyrostowo bez konieczności migracji całego systemu w jednym wysiłku.

Ten wzorzec może nie być odpowiedni, jeśli:

• Co najmniej jeden z zaangażowanych systemów opiera się na funkcji jednej infrastruktury obsługi komunikatów, która nie jest obecna w drugiej.
• Integracja jest synchroniczna, a system inicjujący wymaga natychmiastowej reakcji.
• Integracja ma określone wymagania funkcjonalne lub niefunkcjonalne, takie jak obawy dotyczące zabezpieczeń lub prywatności.
• Ilość danych na potrzeby integracji przekracza pojemność systemu obsługi komunikatów lub sprawia, że obsługa komunikatów jest kosztownym rozwiązaniem problemu.

Projektowanie obciążenia

Architekt powinien ocenić, w jaki sposób wzorzec Messaging Bridge może być używany w projekcie obciążenia roboczego, aby sprostać celom i zasadom opisanym w filarach Azure Well-Architected Framework. Na przykład:

Filar	Jak ten wzorzec obsługuje cele filaru
Optymalizacja kosztów koncentruje się na utrzymaniu i poprawiezwrotu z inwestycji.	Ten krok pośredni może zwiększyć długowieczność istniejącego systemu bez konieczności ponownego pisania, umożliwiając współdziałanie z systemami korzystającymi z innej technologii obsługi komunikatów lub zdarzeń. - KOSZT SKŁADNIKA CO:07
Doskonałość operacyjna pomaga zapewnić jakość obciążeń dzięki ustandaryzowanym procesom i spójności zespołu.	To oddzielenie zapewnia elastyczność podczas zmiany technologii komunikacyjnych i obsługi zdarzeń w ramach obciążenia lub w przypadku różnorodnych wymagań wynikających z zewnętrznych zależności. - OE:06 Wdrażanie zmian obciążenia

Podobnie jak w przypadku każdej decyzji projektowej, należy rozważyć wszelkie kompromisy w stosunku do celów innych filarów, które mogą zostać wprowadzone przy użyciu tego wzorca.

Przykład

Istnieje aplikacja platformy .NET Framework do zarządzania planowaniem pracowników hostowanych lokalnie. Aplikacja jest dobrze ustrukturyzowana z oddzielnymi składnikami komunikującymi się za pośrednictwem usługi MSMQ. Aplikacja działa, a zespół ds. obciążeń nie ma zamiaru ponownie go zapisywać. Nowy konsument danych planowania musi zostać utworzony, aby zaspokoić potrzeby biznesowe, a strategia IT wymaga utworzenia nowego oprogramowania jako aplikacji natywnych dla chmury, aby zoptymalizować koszty i czas dostarczania.

Asynchroniczna architektura oparta na kolejkach dobrze sprawdzała się w przeszłości dla zespołu roboczego, więc zespół zamierza użyć tego samego podejścia architektonicznego, ale z nowoczesną technologią Service Bus. Zespół ds. obciążeń nie chce wprowadzać synchronicznej komunikacji między chmurą a wdrożeniem lokalnym w celu ograniczenia opóźnienia lub niedostępności jednego, który ma wpływ na drugą.

Zespół decyduje się na użycie wzorca mostka wiadomości w celu nawiązania połączenia pomiędzy dwoma systemami. Wzorzec składa się z dwóch części. Jeden moduł odbiera komunikaty z istniejącej kolejki MSMQ i przekazuje je do usługi Service Bus. Druga część pobiera komunikaty z usługi Service Bus i przekazuje je do istniejącej kolejki MSMQ.

Gdy zespół ds. implementacji korzysta z tego podejścia, korzysta z istniejącej infrastruktury w istniejącej aplikacji do integracji z nowymi składnikami. Istniejąca aplikacja nie jest świadoma, że nowe składniki są hostowane na platformie Azure. Podobnie nowe składniki komunikują się ze starszą aplikacją w taki sam sposób, jak komunikują się między sobą, wysyłając komunikaty usługi Service Bus. Mostek przekazuje komunikaty między dwoma systemami.

Implementację tego przykładu można znaleźć w przykładzie MSMQ-to-Service Bus, który korzysta z mostka obsługi komunikatów NServiceBus.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główni autorzy:

• Rob Bagby | Główny deweloper zawartości — wzorce i praktyki platformy Azure
• Kyle Baley | Inżynier oprogramowania
• Udi Dahan | Założyciel i dyrektor generalny określonego oprogramowania
• Chad Kittel | Główny inżynier oprogramowania — wzorce i praktyki dotyczące platformy Azure
• Bryan Lamos | Deweloper zawartości — wzorce i praktyki platformy Azure
• Szymon Pobiega | Inżynier

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

• Opis wzorca mostka obsługi komunikatów ze społeczności wzorców integracji przedsiębiorstwa.
• Dowiedz się, jak zaimplementować mostek komunikatów w środowisku Spring Java.
• QPid bridge może być używany do łączenia technologii przesyłania komunikatów z obsługą protokołu AMQP.
• Mostek komunikatów NServiceBus to implementacja mostka kolejki-do-kolejki dla platformy .NET, która obsługuje szereg infrastruktur obsługi komunikatów, w tym MSMQ, Service Bus i Azure Queue Storage.
• NServiceBus.Router to projekt typu open source, który implementuje wzorzec mostka obsługi komunikatów. Umożliwia również łączenie więcej niż dwóch technologii w jednym wystąpieniu oraz ma zaawansowane możliwości routingu komunikatów.

Powiązane zasoby

• Wzorzec konkurujących odbiorców gwarantuje, że implementacja mostka obsługi komunikatów może obsłużyć obciążenie.
• Wzorzec Ponawiania umożliwia mostkowi obsługi komunikatów obsługę przejściowych błędów.
• Wzorzec wyłącznika obwodu oszczędza zasoby, gdy po którejkolwiek stronie mostu wystąpi przestój.

Łączenie systemów obsługi komunikatów opartych na różnych infrastrukturach obsługi komunikatów i przekazywanie komunikatów między nimi. Takie podejście umożliwia integrację różnych systemów bez konieczności modyfikowania samych systemów.

Kontekst i problem

Wiele organizacji i obciążeń może przypadkowo mieć systemy IT korzystające z wielu infrastruktur obsługi komunikatów, takich jak Microsoft Message Queueing (MSMQ), RabbitMQ, Azure Service Bus i Amazon SQS. Ten problem może wystąpić z powodu fuzji, przejęć lub rozszerzenia bieżących systemów lokalnych na składniki hostowane w chmurze pod kątem efektywności kosztowej i łatwości konserwacji.

Deweloperzy mogą rozwiązać to wyzwanie, modyfikując zintegrowane systemy w celu komunikowania się przy użyciu usług internetowych opartych na protokole HTTP. Jednak takie podejście ma wady, w tym:

• Systemy muszą być modyfikowane przez dodanie klienta HTTP po jednej stronie i program obsługi żądań HTTP z drugiej strony. Następnie należy ponownie przetestować i ponownie wdrożyć systemy.
• Punkty końcowe HTTP muszą być hostowane, co zwiększa złożoność podczas zabezpieczania i wysokiej dostępności usług internetowych.
• Częste problemy z łącznością sieciową, które wymagają niestandardowych mechanizmów ponawiania prób.

Rozwiązanie

Jeśli zintegrowane systemy składają się ze składników komunikujących się przez wymianę komunikatów, wzorzec mostka obsługi komunikatów poprawia integrację i zmniejsza wady.

W tym scenariuszu każdy system łączy się z jedną infrastrukturą obsługi komunikatów. Aby zintegrować różne infrastruktury obsługi komunikatów, należy wprowadzić składnik mostka, który łączy się z co najmniej dwiema infrastrukturami obsługi komunikatów w tym samym czasie. Most ściąga komunikaty z jednego i wypycha je do drugiego bez zmiany ładunku.

Zintegrowane systemy nie muszą rozpoznawać innych ani mostów. System nadawcy jest skonfigurowany do wysyłania określonych komunikatów do wyznaczonej kolejki w natywnej infrastrukturze obsługi komunikatów. Mostek pobiera te komunikaty i przekazuje je do innej kolejki w alternatywnej infrastrukturze komunikatowej, gdzie system odbiorcy je pobiera.

Świadczenia

• Systemy zintegrowane za pośrednictwem mostka obsługi komunikatów nie muszą być modyfikowane. W idealnym przypadku punkty końcowe nie wiedzą, że komunikaty są łączone.
• Integracja jest bardziej niezawodna w porównaniu z alternatywą HTTP dzięki gwarancji mechanizmu dostarczania wiadomości co najmniej raz.
• Scenariusze migracji mogą być bardziej elastyczne. Na przykład punkty końcowe można migrować z jednej infrastruktury obsługi komunikatów do innej w miarę możliwości harmonogramu, zamiast wszystkich jednocześnie.

Wady i ograniczenia

• Zaawansowane funkcje jednej lub obu technologii obsługi komunikatów mogą nie być dostępne na trasie mostkowanej.
• Trasa mostkowana musi uwzględniać ograniczenia obu technologii. Na przykład maksymalny rozmiar komunikatu może wynosić 4 MB w msMQ, ale tylko 64 KB w kolejkach usługi Azure Storage.

Problemy i kwestie do rozważenia

Podczas implementowania wzorca mostka obsługi komunikatów należy wziąć pod uwagę następujące kwestie:

• Jeśli jeden ze zintegrowanych systemów opiera się na transakcjach rozproszonych, takich jak Microsoft Distributed Transaction Coordinator (DTC), dla zapewnienia poprawnego działania, należy zaimplementować mechanizm deduplikacji w moście.

• Jeśli jeden ze zintegrowanych systemów nie korzysta z żadnej infrastruktury obsługi komunikatów i nie można go modyfikować, możesz utworzyć mostek obsługi komunikatów między infrastrukturą używaną przez inny system i kolejką emulowaną przez program SQL Server. Starszy system może wysyłać komunikaty przy użyciu funkcji przechwytywania zmian danych dla programu SQL Server w celu wypychania zmian do dedykowanej tabeli kolejek. Mostek może przekazywać te komunikaty do rzeczywistej infrastruktury obsługi komunikatów.

• W każdej infrastrukturze obsługi komunikatów można użyć jednej kolejki wyznaczonej jako kolejka mostkowa. W tej topologii skonfiguruj system wysyłania tak, aby używał tej konkretnej kolejki jako miejsca docelowego dla typów komunikatów wysyłanych do innego systemu. Można również używać wielu par kolejek w każdej infrastrukturze przesyłu wiadomości, więc nadawca nie jest świadomy mostka. Kolejka cieni jest tworzona dla każdej kolejki docelowej w infrastrukturze obsługi komunikatów systemu docelowego. Most przekazuje komunikaty między kolejkami cieni a ich odpowiednikami.

• W celu spełnienia żądanych celów dotyczących poziomów usług dostępności (SLO) może być konieczne skalowanie w poziomie mostka komunikacyjnego przy użyciu podejścia konkurencyjnych odbiorców.

• Regularne składniki przetwarzania komunikatów używają wzorca ponawiania do obsługi błędów przejściowych. Limit licznika ponawiania umożliwia składnikom wykrywanie zatrutych komunikatów i usuwanie ich z kolejki w celu odblokowania przetwarzania. Most może wymagać innych zasad ponawiania prób, aby zapobiec fałszywej identyfikacji komunikatów jako trucizny, jeśli wystąpi awaria infrastruktury. Aby wstrzymać przekazywanie, możesz użyć wzorca Circuit Breaker.

• Uwzględnij wiadomości w trakcie przesyłania podczas przyrostowej migracji endpointów. Komunikaty, które oczekują już w kolejce w starej infrastrukturze, w tym komunikaty w kolejce błędów oczekujące na ponowną próbę, muszą nadal docierać do punktu końcowego po przeniesieniu. Zachowaj mostek do momentu dostarczenia tych komunikatów, a nie tylko do momentu przeniesienia ostatniego punktu końcowego. Aby zapoznać się z przykładem krok po kroku, zobacz migrowanie do innego transportu przy użyciu mostka komunikatów NServiceBus.

Kiedy używać tego wzorca

Użyj wzorca mostka obsługi komunikatów, jeśli musisz:

• Zintegruj istniejące systemy z minimalnym zapotrzebowaniem na modyfikację.
• Integrowanie starszych aplikacji, które nie mogą korzystać z innych technologii obsługi komunikatów.
• Rozszerzanie istniejących aplikacji lokalnych przy użyciu składników hostowanych w chmurze.
• Połącz systemy rozproszone geograficznie, gdy połączenie internetowe nie jest stabilne.
• Migrowanie pojedynczego systemu rozproszonego z jednej infrastruktury obsługi komunikatów do innej przyrostowo bez konieczności migracji całego systemu w jednym wysiłku.

Ten wzorzec może nie być odpowiedni, jeśli:

• Co najmniej jeden z zaangażowanych systemów opiera się na funkcji jednej infrastruktury obsługi komunikatów, która nie jest obecna w drugiej.
• Integracja jest synchroniczna, a system inicjujący wymaga natychmiastowej reakcji.
• Integracja ma określone wymagania funkcjonalne lub niefunkcjonalne, takie jak obawy dotyczące zabezpieczeń lub prywatności.
• Ilość danych na potrzeby integracji przekracza pojemność systemu obsługi komunikatów lub sprawia, że obsługa komunikatów jest kosztownym rozwiązaniem problemu.

Projektowanie obciążenia

Architekt powinien ocenić, w jaki sposób wzorzec Messaging Bridge może być używany w projekcie obciążenia roboczego, aby sprostać celom i zasadom opisanym w filarach Azure Well-Architected Framework. Na przykład:

Filar	Jak ten wzorzec obsługuje cele filaru
Optymalizacja kosztów koncentruje się na utrzymaniu i poprawiezwrotu z inwestycji.	Ten krok pośredni może zwiększyć długowieczność istniejącego systemu bez konieczności ponownego pisania, umożliwiając współdziałanie z systemami korzystającymi z innej technologii obsługi komunikatów lub zdarzeń. - KOSZT SKŁADNIKA CO:07
Doskonałość operacyjna pomaga zapewnić jakość obciążeń dzięki ustandaryzowanym procesom i spójności zespołu.	To oddzielenie zapewnia elastyczność podczas zmiany technologii komunikacyjnych i obsługi zdarzeń w ramach obciążenia lub w przypadku różnorodnych wymagań wynikających z zewnętrznych zależności. - OE:06 Wdrażanie zmian obciążenia

Podobnie jak w przypadku każdej decyzji projektowej, należy rozważyć wszelkie kompromisy w stosunku do celów innych filarów, które mogą zostać wprowadzone przy użyciu tego wzorca.

Przykład

Istnieje aplikacja platformy .NET Framework do zarządzania planowaniem pracowników hostowanych lokalnie. Aplikacja jest dobrze ustrukturyzowana z oddzielnymi składnikami komunikującymi się za pośrednictwem usługi MSMQ. Aplikacja działa, a zespół ds. obciążeń nie ma zamiaru ponownie go zapisywać. Nowy konsument danych planowania musi zostać utworzony, aby zaspokoić potrzeby biznesowe, a strategia IT wymaga utworzenia nowego oprogramowania jako aplikacji natywnych dla chmury, aby zoptymalizować koszty i czas dostarczania.

Asynchroniczna architektura oparta na kolejkach dobrze sprawdzała się w przeszłości dla zespołu roboczego, więc zespół zamierza użyć tego samego podejścia architektonicznego, ale z nowoczesną technologią Service Bus. Zespół ds. obciążeń nie chce wprowadzać synchronicznej komunikacji między chmurą a wdrożeniem lokalnym w celu ograniczenia opóźnienia lub niedostępności jednego, który ma wpływ na drugą.

Zespół decyduje się na użycie wzorca mostka wiadomości w celu nawiązania połączenia pomiędzy dwoma systemami. Wzorzec składa się z dwóch części. Jeden moduł odbiera komunikaty z istniejącej kolejki MSMQ i przekazuje je do usługi Service Bus. Druga część pobiera komunikaty z usługi Service Bus i przekazuje je do istniejącej kolejki MSMQ.

Gdy zespół ds. implementacji korzysta z tego podejścia, korzysta z istniejącej infrastruktury w istniejącej aplikacji do integracji z nowymi składnikami. Istniejąca aplikacja nie jest świadoma, że nowe składniki są hostowane na platformie Azure. Podobnie nowe składniki komunikują się ze starszą aplikacją w taki sam sposób, jak komunikują się między sobą, wysyłając komunikaty usługi Service Bus. Mostek przekazuje komunikaty między dwoma systemami.

Implementację tego przykładu można znaleźć w przykładzie MSMQ-to-Service Bus, który korzysta z mostka obsługi komunikatów NServiceBus.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główni autorzy:

• Rob Bagby | Główny deweloper zawartości — wzorce i praktyki platformy Azure
• Kyle Baley | Inżynier oprogramowania
• Udi Dahan | Założyciel i dyrektor generalny określonego oprogramowania
• Chad Kittel | Główny inżynier oprogramowania — wzorce i praktyki dotyczące platformy Azure
• Bryan Lamos | Deweloper zawartości — wzorce i praktyki platformy Azure
• Szymon Pobiega | Inżynier

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

• Opis wzorca mostka obsługi komunikatów ze społeczności wzorców integracji przedsiębiorstwa.
• Dowiedz się, jak zaimplementować mostek komunikatów w środowisku Spring Java.
• QPid bridge może być używany do łączenia technologii przesyłania komunikatów z obsługą protokołu AMQP.
• Mostek komunikatów NServiceBus to implementacja mostka kolejki-do-kolejki dla platformy .NET, która obsługuje szereg infrastruktur obsługi komunikatów, w tym MSMQ, Service Bus i Azure Queue Storage.
• NServiceBus.Router to projekt typu open source, który implementuje wzorzec mostka obsługi komunikatów. Umożliwia również łączenie więcej niż dwóch technologii w jednym wystąpieniu oraz ma zaawansowane możliwości routingu komunikatów.

Powiązane zasoby

• Wzorzec konkurujących odbiorców gwarantuje, że implementacja mostka obsługi komunikatów może obsłużyć obciążenie.
• Wzorzec Ponawiania umożliwia mostkowi obsługi komunikatów obsługę przejściowych błędów.
• Wzorzec wyłącznika obwodu oszczędza zasoby, gdy po którejkolwiek stronie mostu wystąpi przestój.