Wzorzec mostka obsługi komunikatów

W tym artykule opisano wzorzec mostka obsługi komunikatów, który jest techniką, której można użyć do integracji różnych systemów opartych na różnych infrastrukturach obsługi komunikató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. Mostek ś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 innej infrastrukturze obsługi komunikatów, w której 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 ze względu na co najmniej jednokrotny mechanizm dostarczania komunikatów.
• Scenariusze migracji mogą być bardziej elastyczne. Na przykład punkty końcowe można migrować z jednej infrastruktury obsługi komunikatów do innej, ponieważ harmonogram zezwala zamiast wszystkich jednocześnie.

Wady

• 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, na przykład Microsoft Distributed Transaction Coordinator (DTC), aby uzyskać poprawność, należy zaimplementować mechanizm deduplikacji w mostek.

• 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żyć wielu par kolejek w każdej infrastrukturze obsługi komunikatów, więc nadawca nie zna mostka. Kolejka w tle jest tworzona dla każdej kolejki docelowej w infrastrukturze obsługi komunikatów systemu docelowego. Mostek przekazuje komunikaty między kolejkami w tle a ich odpowiednikami.

• W celu spełnienia żądanych umów dotyczących poziomu usług dostępności (SLA) może być konieczne skalowanie mostka obsługi komunikatów w poziomie przy użyciu podejścia Konkurujący konsumenci .

• 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 wyłącznika .

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łączenie systemów rozproszonych 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.

Projekt obciążenia

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

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 napisana w programie .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.

Architektura oparta na kolejkach asynchroniczna pracowała w przeszłości dla zespołu roboczego, więc zespół będzie używać 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 obsługi komunikatów w celu nawiązania połączenia z dwoma systemami. Wzorzec składa się z dwóch części. Jedna część 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.

Współautorzy

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

Autorzy zabezpieczeń:

• Rob Bagby | Główny lider zawartości architektury
• Kyle Baley | Inżynier oprogramowania
• Udi Dahan | Założyciel i dyrektor generalny określonego oprogramowania
• Chad Kittel | Główny inżynier oprogramowania
• Bryan Lamos | Relacje deweloperów
• 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 obsługi komunikatów w środowisku Spring Java.
• Mostek QPid może służyć do łączenia technologii obsługi komunikatów z obsługą protokołu AMQP.
• Mostek obsługi komunikatów NServiceBus to implementacja platformy .NET mostka kolejki do kolejki, która obsługuje szereg infrastruktury 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ż mostkowanie więcej niż dwóch technologii w jednym wystąpieniu i 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 mostek obsługi komunikatów do obsługi przejściowych błędów.
• Wzorzec wyłącznika oszczędza zasoby po obu stronach mostka.