Czy są jakieś? Według mnie MB zna zarówno subskrybentów, jak i wydawców i działa jako mediator, powiadamiając subskrybentów o nowych wiadomościach (w zasadzie model „push”). Z drugiej strony MQ to bardziej model „ściągania”, w którym konsumenci pobierają komunikaty z kolejki.
Czy jestem tutaj całkowicie zboczony?
Odpowiedzi:
Ogólnie rzecz biorąc, jeśli chodzi o oprogramowanie dostawców, są one używane zamiennie i nie mają tak silnych rozróżnień pod względem wypychania lub ciągnięcia, jak to opisujesz.
BUS vs. KOLEJKI jest rzeczywiście nieco pojęciem dziedzictwo, ostatnio wynikające z systemów takich jak IBM MQ i Tibco Rendezvous. MQ pierwotnie był systemem 1: 1, w istocie kolejką oddzielającą różne systemy.
Natomiast Tibco było (sprzedawane jako) kręgosłupem przesyłania wiadomości, w którym można było mieć wielu wydawców i subskrybentów na te same tematy.
Jednak zarówno (jak i nowsze, konkurencyjne produkty) mogą w dzisiejszych czasach grać w swojej przestrzeni. Oba mogą być ustawione na przerywanie, jak również na odpytywanie nowych wiadomości. Obie pośredniczą w interakcjach między różnymi systemami.
Jednak fraza kolejka komunikatów jest również używana do wewnętrznych pomp komunikatów wewnątrz wątku i tym podobnych, aw tym kontekście użycie jest rzeczywiście inne. Jeśli myślisz o klasycznej pompie komunikatów systemu Windows, jest to rzeczywiście bardziej model ściągania, który opisujesz, ale tak naprawdę jest bardziej wewnątrz aplikacji niż między aplikacjami lub między skrzynkami.
Magistrala komunikatów
Message Bus jest infrastruktura wiadomości, aby umożliwić różne systemy do komunikacji przez wspólny zestaw interfejsów ( wiadomość autobusowego ).
Źródło: EIP
Kolejka wiadomości
Podstawowa idea kolejki komunikatów jest prosta:
Dwa (lub więcej) procesy mogą wymieniać informacje poprzez dostęp do wspólnej kolejki komunikatów systemu .
Proces wysyłania umieszcza za pośrednictwem jakiegoś modułu przesyłania komunikatów (OS) wiadomość w kolejce, która może zostać odczytana przez inny proces
Źródło: Dave Marshall
Różnica
Kolejka wiadomości zawiera regułę FIFO ( pierwsze weszło, pierwsze wyszło ), podczas gdy w usłudze Message Bus jej nie ma.
Wniosek
Obydwa WYGLĄDA jak wykonywanie tego samego rodzaju pracy - przekazywanie komunikatów między dwiema aplikacjami lub modułami lub interfejsami lub systemami lub procesami , z wyjątkiem niewielkiej różnicy FIFO
Doszło do zatarcia linii między tymi dwiema koncepcjami, ponieważ niektóre produkty obsługują teraz funkcje, które wcześniej należały tylko do jednej lub drugiej kategorii (na przykład Azure Service Bus obsługuje oba podejścia).
Kolejka komunikatów odbiera komunikaty z aplikacji i udostępnia je jednej lub większej liczbie innych aplikacji w trybie FIFO (First In First Out). W wielu scenariuszach architektonicznych, jeśli aplikacja A musi wysyłać aktualizacje lub polecenia do aplikacji B i C, wówczas można skonfigurować oddzielne kolejki komunikatów dla B i C. A zapisywałby oddzielne komunikaty do każdej kolejki, a każda zależna aplikacja czytałaby z jej własna kolejka (wiadomość jest usuwana po dekolejce). Ani B, ani C nie muszą być dostępne, aby A mógł wysłać aktualizacje. Każda kolejka komunikatów jest trwała, więc jeśli aplikacja zostanie ponownie uruchomiona, zacznie pobierać ze swojej kolejki po ponownym podłączeniu do trybu online. Pomaga to przełamać zależności między zależnymi systemami i może zapewnić aplikacjom większą skalowalność i odporność na błędy.
Magistrala komunikatów lub magistrala usług umożliwia jednej (lub większej liczbie) aplikacji przekazywanie komunikatów do jednej lub większej liczby innych aplikacji. Może nie być gwarancji zamówienia „pierwsze weszło pierwsze wyszło”, a abonenci autobusu mogą przychodzić i wychodzić bez wiedzy nadawców wiadomości. Zatem aplikacja A może zostać napisana w celu przekazywania aktualizacji statusu do aplikacji B za pośrednictwem magistrali komunikatów. Później napisano aplikację C, która również może skorzystać z tych aktualizacji. Aplikację C można skonfigurować tak, aby nasłuchiwała magistrali komunikatów i podejmowała działania również na podstawie tych aktualizacji, bez konieczności aktualizacji aplikacji A. W przeciwieństwie do kolejek, w których aplikacja wysyłająca jawnie dodaje komunikaty do każdej kolejki, magistrala komunikatów używa funkcji publikowania / subskrybuj model. Wiadomości są publikowane w magistrali i każda aplikacja, która zasubskrybowała tego rodzaju wiadomość, otrzyma ją.
Główną różnicą, która nie została wyraźnie wspomniana w innych odpowiedziach, jest to, że magistrala komunikatów zezwala na wielu subskrybentów, podczas gdy kolejka będzie usuwać elementy z kolejki jeden po drugim do wszystkiego, co jest w kolejce. Gdybyś chciał, aby wielu słuchaczy widziało te same pozycje wychodzące z kolejki, musiałbyś sobie z tym poradzić, autobus usługowy zrobiłby to za Ciebie po wyjęciu z pudełka.
Widzę to, że kolejka wiadomości tworzy magistralę wiadomości . Klienci (tj. Węzły) mogą wtedy nasłuchiwać magistrali komunikatów. Jest to szczególnie prawdziwe w przypadku, gdy masz MQ rozgłaszający wiadomości przez UDP, innymi słowy, wysyła wiadomości na adres broadcast / multicast bez wiedzy lub dbałości o to, kto je otrzyma. Bardziej szczegółowy opis tego scenariusza można znaleźć w tym artykule .
Service Bus to termin bardziej ogólny niż kolejka wiadomości.
MQ to proste FIFO, ale istnieją bardziej wyrafinowane sposoby implementacji Service Bus, tj. Event Hub, który jest ogromnym „centrum” manipulowania komunikatami. Oprócz funkcjonalności dostarczanej przez MQ, pozwala na przechowywanie wiadomości (a tym samym korzystanie z wielu abonentów) itp
Magistrala komunikatów to model dystrybucji 1 do wielu. Miejsce docelowe w tym modelu jest zwykle nazywane tematem lub tematem. Ta sama opublikowana wiadomość jest odbierana przez wszystkich subskrybentów. Można to również nazwać modelem „rozgłoszeniowym”. Możesz myśleć o temacie jako o odpowiedniku tematu we wzorcu projektowym obserwatora dla przetwarzania rozproszonego. Niektórzy dostawcy magistrali komunikatów efektywnie decydują się na implementację tego jako UDP zamiast TCP. W przypadku tematu wiadomość jest dostarczana w trybie „odpal i zapomnij” - jeśli nikt nie słucha, wiadomość po prostu znika. Jeśli nie tego chcesz, możesz skorzystać z „trwałych subskrypcji”.
Kolejka komunikatów jest miejscem docelowym komunikatów 1 do 1. Wiadomość jest odbierana tylko przez jednego z odbiorników odbierających (uwaga: konsekwentne używanie subskrybentów dla klienta tematu i odbiorcy dla klienta kolejki pozwala uniknąć nieporozumień). Wiadomości wysłane do kolejki są przechowywane na dysku lub w pamięci, dopóki ktoś ich nie odbierze lub nie wygaśnie. Dlatego kolejki (i trwałe subskrypcje) wymagają aktywnego zarządzania pamięcią masową, należy więc pomyśleć o powolnych konsumentach.
Twierdzę, że w większości środowisk tematy są lepszym wyborem, ponieważ zawsze można dodać dodatkowe komponenty bez konieczności zmiany architektury. Dodane komponenty mogą obejmować monitorowanie, logowanie, analitykę, itp. Na początku projektu nigdy nie wiadomo, jakie będą wymagania za 1 rok, 5 lat, 10 lat. Zmiana jest nieunikniona, przyjmij ją :-)