Middleware wiadomości to technologia middleware składająca się z mechanizmu transmisji wiadomości lub trybu kolejki wiadomości, która wykorzystuje wydajny i niezawodny mechanizm komunikacji do wymiany danych niezależnej od platformy oraz integruje systemy rozproszone oparte na komunikacji danych. Obecnie w branży jest wiele produktów MQ, takich jak RabbitMQ, ActiveMQ, ZeroMQ itd., które są doskonałym middleware komunikacyjnym, ale który powinniśmy wybrać w tym projekcie? Niniejszy artykuł ocenia i porównuje następujące produkty kolejki wiadomości: RabbitMQ, ZeroMQ, ActiveMQ, MSMQ, Redis oraz memcacheQ
Odbiegając od tematu: Najpierw możemy pomyśleć o małym pytaniu: "Dlaczego potrzebujemy usług kolejki wiadomości w aplikacjach webowych?" ”
Na przykład duża liczba żądań insert, update i innych pojawia się jednocześnie do MySQL, co bezpośrednio prowadzi do niezliczonych blokad wierszy i tabel, a nawet zbyt wielu żądań na koniec, co powoduje zbyt wiele błędów połączeń. Dzięki wykorzystaniu kolejek wiadomości możemy przetwarzać żądania asynchronicznie, co odciąża system.
RabbitMQ
Jest to otwartoźródłowa kolejka wiadomości napisana w Erlang, która obsługuje wiele protokołów: AMQP, XMPP, SMTP, STOMP, co czyni ją bardzo wymagającą i bardziej odpowiednią do rozwoju na poziomie korporacyjnym. Jest to wiodąca implementacja protokołu AMQP, który wykorzystuje architekturę brokera, co oznacza, że wiadomości mogą być kolejkowane na węźle centralnym przed wysłaniem do klienta. Jest dobre wsparcie dla routingu, load balancing lub utrzymywania danych. Ta funkcja sprawia, że RabbitMQ jest łatwy w użyciu i wdrażaniu, odpowiedni do wielu scenariuszy, takich jak routowanie, równoważenie obciążenia czy utrzymywanie wiadomości, i może być realizowany za pomocą zaledwie kilku linii kodu z kolejkami wiadomości. Jednak to sprawia, że jest mniej skalowalny i wolniejszy, ponieważ węzeł centralny zwiększa opóźnienia i jest większy po enkapsulacji wiadomości. Aby skonfigurować RabbitMQ, musisz zainstalować środowisko Erlang na docelowym komputerze.
Kliknij, aby zobaczyć ten obraz w nowym oknie
? MQ(ZeroMQ)
Jest znany jako najszybszy system kolejkowania wiadomości, szczególnie w scenariuszach o wysokiej przepustowości na zapotrzebowaniu. Jest to bardzo lekki system komunikacji, opracowany specjalnie dla scenariuszy o wysokiej przepustowości i niskich opóźnieniach, często spotykany w zastosowaniach w świecie finansów. W porównaniu do RabbitMQ, ZeroMQ obsługuje wiele zaawansowanych scenariuszy komunikatów, ale musisz zaimplementować pojedyncze bloki w ramach ZeroMQ (np. gniazda, urządzenia itp.).
? MQ (ZeroMQ) może implementować zaawansowane/złożone kolejki, w których RabbitMQ nie radzi sobie dobrze, ale deweloperzy muszą samodzielnie łączyć wiele frameworków technicznych, a złożoność techniczna stanowi wyzwanie dla skutecznego zastosowania tego MQ. ZeroMQ ma unikalny model niemiddleware, w którym nie musisz instalować i uruchamiać serwera wiadomości ani middleware, ponieważ twoja aplikacja będzie pełnić tę rolę usługową. Wystarczy po prostu odwołać się do biblioteki ZeroMQ, którą można zainstalować za pomocą NuGet, i bez problemu wysyłasz wiadomości między aplikacjami. Jednak ZeroMQ udostępnia tylko kolejki nietrwałe, co oznacza, że jeśli maszyna przestanie działać, dane zostaną utracone. Wśród nich Storm Twittera wykorzystuje ZeroMQ do przesyłania strumieni danych. ZeroMQ jest bardzo elastyczny, ale musisz poznać jego 80-stronicowy podręcznik (jeśli piszesz o systemie rozproszonym, koniecznie go przeczytaj).
ZeroMQ nie posiada architektury middleware i nie wymaga żadnych procesów serwisowych ani uruchamiań. W rzeczywistości to właśnie endpoint aplikacji pełni tę rolę usługową. To bardzo ułatwia wdrożenie, ale obawa polega na tym, że nie masz gdzie obserwować, jeśli coś pójdzie nie tak. Z tego co wiemy, ZeroMQ oferuje tylko kolejki nietrwałe. Możesz wdrożyć własne możliwości audytu i odzyskiwania danych tam, gdzie są potrzebne.
Kliknij, aby zobaczyć ten obraz w nowym oknie
MSMQ
To jedyna rzecz w produkcie Microsoftu, która jest uznawana za wartościową. Jeśli MSMQ udowodni, że poradzi sobie z tego typu zadaniami, zdecydują się go użyć. Chodzi o to, że to nie jest skomplikowane, nic poza odbieraniem i wysyłaniem; Ma pewne twarde ograniczenia, takie jak maksymalny rozmiar wiadomości wynoszący 4MB. Jednak może rozwiązać te problemy, łącząc się z oprogramowaniem, takim jak MassTransit czy NServiceBus.
Kliknij, aby zobaczyć ten obraz w nowym oknie
Jafka/Kafka
Kafka (która dystrybuuje wiadomości między różnymi węzłami) to rozproszony system MQ opracowany i udostępniony jako open source przez LinkedIn w grudniu 2010 roku, obecnie będący projektem inkubacyjnym Apache, wysokowydajnego międzyjęzykowego systemu kolejkowania wiadomości Publish/Subscribe, a Jafka jest inkubowana na Kafce, będącej ulepszoną wersją Kafki. Posiada następujące cechy: szybkie utrzymywanie wiadomości, które może utrzymywać wiadomości pod narzutem systemu O(1); Wysoka przepustowość, która może osiągnąć przepustowość 10W/s na zwykłym serwerze; System całkowicie rozproszony, Broker, Producer i Consumer – wszyscy natywnie wspierają rozproszone i automatycznie osiągają złożoną równowagę. Obsługuje równoległe ładowanie danych Hadoop, co jest wykonalnym rozwiązaniem dla danych logowych i systemów analizy offline, takich jak Hadoop, ale z ograniczeniami przetwarzania w czasie rzeczywistym. Kafka jednoczy przetwarzanie wiadomości online i offline poprzez mechanizm równoległego ładowania Hadoop, co jest również ważne dla systemu badanego w tym temacie. Apache Kafka to bardzo lekki system komunikacji w porównaniu do ActiveMQ, a oprócz bardzo dobrej wydajności, jest także systemem rozproszonym, który działa dobrze.
Kliknij, aby zobaczyć ten obraz w nowym oknie
Apache ActiveMQ
ActiveMQ plasuje się gdzieś pomiędzy tymi dwoma (RabbitMQ i ZeroMQ), podobnie jak ZemoMQ, i może być wdrażany zarówno w trybie proxy, jak i P2P. Podobnie jak RabbitMQ, łatwo wdrażać zaawansowane scenariusze i wymaga niskiego zużycia.
ActiveMQ jest znany jako kręgosłup świata Javy. Ma długą historię i jest szeroko stosowany. Jest też wieloplatformowy, zapewniając naturalny punkt integracji dla produktów, które nie są dostępne na platformie Microsoftu. Jednak można go rozważyć tylko wtedy, gdy przeszedł przez MSMQ. Aby skonfigurować ActiveMQ, musisz zainstalować środowisko Java na docelowej maszynie.
Kliknij, aby zobaczyć ten obraz w nowym oknie
Warto zauważyć, że produktem nowej generacji ActiveMQ jest Apollo, oparty na prototypie ActiveMQ i jest szybszym, bardziej niezawodnym oraz łatwiejszym w utrzymaniu narzędziem do brokera wiadomości. Apache nazywa Apollo najszybszym i najbardziej odpornym serwerem STOMP (Streaming Text Orientated Message Protocol).
Cechy Apollo są następujące:
Obsługiwane są protokoły Stomp 1.0 i Stomp 1.1
Tematy i kolejki
Przeglądarka kolejek
Subskrypcje trwałe z motywem
Kolejka lustrzana
Niezawodne wiadomości
Wygaśnięcie i wymiana wiadomości
Wyszukiwarka wiadomości
JAAS zweryfikowany
Autoryzacja oparta na ACL
Wspieraj walidację SSL/TLS i certyfikatów
API zarządzania REST
Kliknij, aby zobaczyć ten obraz w nowym oknie
Redis
Jest to baza danych NoSQL oparta na kluczu-wartości, która jest aktywnie rozwijana i utrzymywana, choć jest to system przechowywania danych Key-Value, ale obsługuje funkcje MQ, dzięki czemu może być używana jako lekka usługa kolejkowa. Dla operacji onboardingu i out-queue RabbitMQ i Redis każdy z nich wykonuje się po milion razy, a czas wykonania jest rejestrowany co 100 000 razy. Dane testowe dzielą się na cztery różne rozmiary: 128 bajtów, 512 bajtów, 1K i 10K. Eksperymenty pokazują, że dołączając do zespołu, wydajność Redis jest wyższa niż RabbitMQ, gdy porównanie danych jest małe, a jeśli rozmiar danych przekracza 10K, Redis jest nieznośnie wolny. Po odejściu z zespołu Redis wykazał się bardzo dobrą wydajnością niezależnie od wielkości danych, podczas gdy RabbitMQ był znacznie niższy niż Redisa.
MemcacheQ
Trwała kolejka wiadomości Memcacheq (w skrócie MCQ) to lekka kolejka wiadomości, MemcacheQ posiada:
1 Proste i łatwe w użyciu
2 Szybkie przetwarzanie
3 Kolejki wielokrotne
4 Dobre wyniki współbieżności
5 Kompatybilność z protokołem Memcache. Oznacza to, że wystarczy zainstalować rozszerzenie memcache, nie są potrzebne dodatkowe wtyczki.
6 Jest też wygodny w użyciu w frameworku zend.
Ostatecznie te produkty:
1. Oba mają własne API klienckie lub obsługują wiele języków programowania;
2. Istnieje wiele dokumentacji;
3. Udzielono pozytywnego wsparcia.
4. ActiveMQ, RabbitMQ, MSMQ, Redis wszystkie muszą uruchamiać procesy usługowe, które można monitorować i konfigurować, a pozostałe są problematyczne
5. Wszystkie zapewniają stosunkowo dobrą niezawodność (spójność), skalowalność i równowagę obciążenia, a także oczywiście wydajność
Nie będę tu gadał bzdur, poniżej załączono zestaw wyników testów przechwyconych z Internetu. Wyświetlana jest liczba wysyłanych i odbieranych wiadomości na sekundę. Cały proces wygenerował łącznie 1 milion wiadomości 1K. Test przeprowadzono na samodzielnym komputerze z systemem Windows Vista.
Jak widać, ZeroMQ to nie poziom jak wszystko inne. Jego wydajność jest zaskakująco wysoka. Mimo to produkt ten nie zapewnia trwałości komunikatów, nie pozwala łatwo przechowywać i monitorować procesów pośrednich oraz wymaga samoaudytu i odzyskiwania danych, dlatego nie jest satysfakcjonujący pod względem łatwości obsługi i HA. Wniosek jest jasny: jeśli chcesz, aby aplikacja wysyłała wiadomości jak najszybciej, wybierasz ZeroMQ. Jest to bardziej wartościowe, gdy nie zależy ci na przypadkowej utracie pewnych wiadomości.
Bloger w tym artykule ma nadzieję (i nie ma na to wielkiej nadziei) korzystać z Rabbit, Rabbitmq ma wbudowane narzędzia, haha, jeśli utworzysz klaster, nie musisz martwić się o takie problemy jak balans obciążenia, a możesz ustawić mirror queue. Ale takie rzeczy polegają na tym, że powinno być więcej testów i w efekcie masz ulubioną postać, a wszystko, co słyszałem i czytałem o Rabbit, sprawia, że czuję, iż to powinien być najlepszy wybór.
|
Opublikowano 15.12.2016 10:52:40
|
|
|
|
