Brokery komunikatów

menu icon

Brokery komunikatów

Brokery komunikatów to technologia komunikacji pomiędzy aplikacjami, która pomaga budować wspólny mechanizm integracji w celu obsługi przeznaczonych dla chmury, opartych na mikrousługach i bezserwerowych architektur hybrydowych.

Czym jest broker komunikatów?

Broker komunikatów to oprogramowanie, które umożliwia aplikacjom, systemom i usługom wzajemną komunikację oraz wymianę informacji. Broker komunikatów realizuje taką funkcję dzięki tłumaczeniu komunikatów pomiędzy formalnymi protokołami komunikacyjnymi. Dzięki temu usługi współzależne mogą ze sobą bezpośrednio „rozmawiać”, nawet jeżeli zostały napisane w różnych językach lub wdrożone na różnych platformach.

Brokery komunikatów to moduły programowe oferowane jako część komunikacyjnego oprogramowania pośredniczącego lub oprogramowania pośredniczącego zorientowanego na przetwarzanie komunikatów (MOM). Ten rodzaj oprogramowania pośredniczącego oferuje programistom ustandaryzowany sposób obsługi przepływu danych pomiędzy komponentami aplikacji, aby mogli koncentrować się na głównym układzie logicznym. Może służyć jako rozproszona warstwa komunikacji, która pozwala aplikacjom na wielu platformach komunikować się wewnętrznie.

Brokery komunikatów mogą magazynować, kierować i dostarczać komunikaty do właściwych miejsc docelowych oraz weryfikować ich poprawność. Pełnią funkcję elementów pośredniczących pomiędzy różnymi aplikacjami, dzięki czemu nadawcy mogą wysyłać wiadomości, nie wiedząc, gdzie znajdują się ich odbiorcy, czy są aktywni, a także ilu ich jest. Pozwala to rozdzielać procesy i usługi w ramach systemów.

Aby zapewnić niezawodność magazynowania oraz pewną dostawę, brokery komunikatów często wykorzystują podstrukturę lub komponent o nazwie kolejka komunikatów, który przechowuje i porządkuje komunikaty do momentu, w którym aplikacje będą je mogły przetworzyć. Komunikaty ustawione w kolejce są przechowywane dokładnie w takim porządku, w jakim zostały przesłane, i pozostają w kolejce do momentu potwierdzenia ich odbioru.

Asynchroniczne przesyłanie komunikatów (15:11) opisuje rodzaj komunikacji pomiędzy aplikacjami, którą umożliwiają brokery komunikatów. Zjawisko to zapobiega utracie cennych danych i pozwala systemom kontynuować pracę nawet w obliczu problemów z przerwami w łączności lub opóźnieniami, które w sieciach publicznych są zjawiskiem powszechnym. Asynchroniczne przesyłanie komunikatów gwarantuje, że komunikat jest dostarczany raz (i tylko raz) we właściwej kolejności względem innych elementów tego typu.

Brokery komunikatów mogą zawierać menedżery kolejek, które obsługują interakcje pomiędzy wieloma kolejkami komunikatów, a także usługi z funkcjami kierowania danych, tłumaczenia wiadomości, utrwalania oraz zarządzania stanem klienta.

Modele brokera komunikatów

Brokery komunikatów oferują dwa podstawowe wzorce dystrybucji komunikatów lub style komunikacji:

  • Przesyłanie wiadomości między punktami: jest to wzorzec dystrybucji wykorzystywany w kolejkach komunikatów, w którym pomiędzy nadawcą a odbiorcą wiadomości występuje relacja „jeden do jednego”. Każda wiadomość w kolejce jest wysyłana tylko do jednego odbiorcy i wykorzystywana tylko raz. Przesyłanie wiadomości między punktami jest stosowane, gdy komunikat musi być obsłużony tylko raz. Przykładem zastosowania tego stylu przesyłania wiadomości jest przetwarzanie transakcji związanych z listami płac oraz finansowych. W tych systemach zarówno nadawcy, jak i odbiorcy potrzebują gwarancji, że każda płatność zostanie wysłana tylko raz.
  • Komunikacja typu publikacja/subskrypcja: w tym modelu przesyłania komunikatów, który często określa się jako „pub/sub”, twórca wiadomości publikuje ją w temacie, a wielu odbiorców wiadomości subskrybuje tematy, dla których chcą otrzymywać wiadomości. Wszystkie wiadomości opublikowane w temacie są przesyłane do wszystkich zasubskrybowanych w nim aplikacji. Jest to nadawcza metoda dystrybucji, w której pomiędzy publikującym a subskrybującymi występuje związek „jeden do wielu”. Gdy na przykład linia lotnicza przekazuje aktualizacje na temat czasu lądowania lub opóźnienia lotów, informacje takie są przydatne dla wielu osób: załogi naziemnej zajmującej się serwisem i tankowaniem samolotów, tragarzy, stewardess i stewardów oraz pilotów przygotowujących się do następnej podróży lotniczej, a także operatorów tablic informacyjnych dla pasażerów. W takich zastosowaniach dobrze sprawdza się właśnie wzorzec komunikacji pub/sub.

Brokery komunikatów w architekturach chmury

Aplikacje od początku przeznaczone dla chmury są skonstruowane tak, aby umożliwiać korzystanie z zalet przetwarzania w chmurze, w tym z elastyczności, skalowalności i szybkiego wdrażania. Aplikacje te są zbudowane z małych, dyskretnych komponentów wielokrotnego użytku nazywanych mikrousługami. Każda mikrousługa jest wdrażana i może działać niezależnie od innych. Oznacza to, że każdą z nich można aktualizować, skalować i uruchamiać ponownie bez wpływu na inne usługi w systemie. Mikrousługi, często pakowane w kontenery, współpracują, tworząc aplikację, ale każda z nich ma własną architekturę, w tym bazę danych i model danych, które mogą się między sobą różnić.

Mikrousługi muszą być wyposażone w mechanizmy wzajemnej komunikacji, aby działać w sposób zgodny. Brokery komunikatów to jeden z mechanizmów, których używają do tworzenia rdzenia wspólnej komunikacji.

Brokery komunikatów są często używane do zarządzania komunikacją pomiędzy systemami lokalnymi i komponentami chmury w środowiskach chmury hybrydowej. Korzystanie z brokera komunikatów zapewnia lepszą kontrolę nad komunikacją pomiędzy usługami, dzięki czemu dane są przesyłane pomiędzy elementami aplikacji w sposób bezpieczny, niezawodny i wydajny. Brokery komunikatów odgrywają podobną rolę w integrowaniu środowisk wielochmurowych, umożliwiając komunikację pomiędzy obciążeniami i środowiskami wykonawczymi na różnych platformach. Są one również dobrze przystosowane do użytku w środowisku przetwarzania bezserwerowego, w którym indywidualne usługi hostowane w chmurze są uruchamiane na żądanie.

Brokery komunikatów a interfejsy API

Interfejsy API REST są powszechnie używane do komunikacji między mikrousługami. Termin „Representational State Transfer” (REST), który można przetłumaczyć jako „zmiana stanu poprzez reprezentacje”, definiuje zbiór zasad i ograniczeń obowiązujących programistów usług sieci WWW. Wszelkie usługi, które są nimi objęte, mogą komunikować się za pośrednictwem zbioru jednolitych, współużytkowanych i bezstanowych operatorów oraz żądań. Interfejs oprogramowania aplikacji (API) oznacza bazowy kod umożliwiający usługom wzajemną komunikację, o ile jest zgodny z regułami REST.

Interfejsy API REST komunikują się za pomocą protokołu przesyłania dokumentów hipertekstowych (HTTP). Ponieważ protokół HTTP jest standardowym protokołem przesyłowym w domenie publicznej, interfejsy API REST są powszechnie znane, często używane i mogą ze sobą współdziałać. Protokół HTTP jest jednak protokołem typu żądanie-odpowiedź, dlatego najlepiej sprawdza się w sytuacjach wymagających synchronicznego żądania/odpowiedzi. Oznacza to, że usługi wysyłające żądania za pośrednictwem interfejsów API REST muszą być zaprojektowane pod kątem natychmiastowych odpowiedzi. Jeżeli klient otrzymujący odpowiedź jest nieaktywny, usługa wysyłania zostanie zablokowana podczas oczekiwania na odpowiedź. Logika przełączania awaryjnego i obsługi błędów powinna być wbudowana w obie usługi.

Brokery komunikatów pozwalają na asynchroniczną komunikację pomiędzy usługami, dzięki czemu usługa wysyłająca nie musi oczekiwać na odpowiedź usługi odbierającej. Zwiększa to odporność na błędy i elastyczność systemów, w których są stosowane. Ponadto używanie brokerów komunikatów pozwala łatwiej skalować systemy, ponieważ wzorzec komunikacji typu pub/sub pozwala łatwo obsługiwać zmieniające się liczby usług. Brokery komunikatów monitorują również statusy subskrybentów.

Brokery komunikatów a platformy strumieniowego przesyłania zdarzeń

Brokery komunikatów mogą obsługiwać dwa wzorce przesyłania komunikatów lub więcej, w tym kolejki komunikatów i wiadomości typu pub/sub, natomiast platformy strumieniowego przesyłania zdarzeń oferują jedynie wzorce dystrybucji pub/sub. Platformy strumieniowego przesyłania zdarzeń, zaprojektowane pod kątem dużych ilości komunikatów, można łatwo skalować. Pozwalają porządkować strumienie rekordów na kategorie nazywane tematami oraz przechowywać je przez określony czas. Platformy strumieniowego przesyłania zdarzeń, w przeciwieństwie do brokerów komunikatów, nie gwarantują dostarczania komunikatów ani śledzenia, którzy subskrybenci otrzymali wiadomości.

Platformy strumieniowego przesyłania zdarzeń oferują większą skalowalność niż brokery komunikatów, ale mniej funkcji, które zapewniają odporność na błędy (takich jak ponowne wysyłanie komunikatów), a także bardziej ograniczone możliwości kierowania wiadomości i kolejkowania.

Dowiedz się więcej na temat architektury opartej na zdarzeniach.

Broker komunikatów a ESB (korporacyjna magistrala usług)

Korporacyjna magistrala usług (ESB) to wzorzec architektury, który jest czasem używany w korporacyjnych architekturach zorientowanych na usługi. W magistrali ESB scentralizowana platforma oprogramowania łączy protokoły komunikacyjne i formaty danych we „wspólny język”, z którego mogą korzystać wszystkie usługi i aplikacje w architekturze. Może to być na przykład tłumaczenie otrzymywanych żądań z jednego protokołu (takiego jak XML) na inny (na przykład JSON). Magistrale ESB przekształcają pakiety komunikatów w sposób zautomatyzowany. Scentralizowana platforma programowa obsługuje też inną logikę harmonizacji, na przykład łączność, routing i przetwarzanie żądań.

Infrastruktury ESB mają jednak złożony charakter, ich integracja może więc stanowić wyzwanie oraz być droga w utrzymaniu. Trudno jest naprawiać związane z nimi problemy, gdy występują w środowiskach produkcyjnych, nie można ich łatwo skalować, a proces aktualizacji jest pracochłonny.

Brokery wiadomości są „lekką” alternatywą dla magistrali ESB; realizują podobną funkcję — mechanizmu komunikacji między usługami — w prostszy i tańszy sposób. Można je z powodzeniem stosować w architekturach mikrousług, które zyskały na popularności w miarę odchodzenia od magistral ESB.

Przypadki użycia brokera komunikatów

Wdrożenie brokerów komunikatów pozwala zrealizować wiele potrzeb biznesowych w różnych branżach oraz środowiskach przetwarzania korporacyjnego. Są one przydatne zawsze, gdy wymagana jest niezawodna komunikacja pomiędzy aplikacjami i dostarczanie komunikatów.

Brokery komunikatów są często wykorzystywane do następujących zastosowań:

  • Transakcje finansowe i przetwarzanie płatności: bardzo ważne jest, aby mieć pewność, że płatności są wysyłane raz i tylko raz. Korzystanie z brokera komunikatów do obsługi danych transakcyjnych daje pewność, że informacje płatnicze nie zostaną utracone ani przypadkowo zduplikowane. Ponadto zapewnia dowód odbioru i umożliwia systemom niezawodną komunikację, nawet wówczas, gdy sieci pośredniczące są wyłączone.
  • Przetwarzanie i realizacja zamówień w handlu elektronicznym: w przypadku działalności online reputacja marki zależy od niezawodności witryny internetowej i platformy e-handlu. Brokery komunikatów zwiększają odporność na błędy i gwarantują, że komunikaty są dostarczane raz i tylko raz, dlatego są naturalnym wyborem dla osób szukających rozwiązania do przetwarzania zamówień online.
  • Ochrona wysoce wrażliwych danych w ruchu i w spoczynku: gdy dana branża jest objęta surowymi regulacjami albo firma jest wystawiona na duże czynniki ryzyka, należy wybrać rozwiązanie komunikacyjne z funkcją kompleksowego szyfrowania.

Brokery komunikatów i IBM Cloud

Brokery komunikatów zyskują na znaczeniu, gdy organizacje modernizują swoje aplikacje podczas migracji do chmury. Wiele z największych firm na świecie — w tym 85% z listy Fortune 100 — korzysta z proponowanych przez IBM funkcji brokerów komunikatów, które są tworzone na potrzeby obecnych zwinnych środowisk programistycznych, infrastruktur opartych na mikrousługach i chmurze hybrydowej, a także z myślą o przeróżnych rodzajach systemów i spełnianiu wymogów dotyczących połączeń.

Wykonaj kolejny krok: Dowiedz się więcej o pakiecie IBM Cloud Pak for Integration, który został zbudowany w oparciu o podstawową funkcję IBM MQ, czołowe rozwiązanie do przesyłania wiadomości w przedsiębiorstwie.

Załóż konto IBM Cloud już dzisiaj.