Czy Akka przestarzała brokerów komunikatów JMS / AMQP? [Zamknięte]

Zamknięte . To pytanie jest oparte na opiniach . Obecnie nie przyjmuje odpowiedzi.

Chcesz poprawić to pytanie? Zaktualizuj pytanie, aby można było na nie odpowiedzieć faktami i cytatami, edytując ten post .

Zamknięte 4 lata temu .

Spędziłem ostatni tydzień głęboko nurkując w dokumentach Akka i wreszcie zrozumiałem, czym są systemy aktorów i problemy, które rozwiązują.

Moje zrozumienie (i doświadczenie) tradycyjne JMS / AMQP brokerów wiadomość jest taka, że istnieją one dostarczyć następujące:

Przetwarzanie asynchroniczne między producentem a konsumentem; i
Gwarancja dostarczenia wiadomości, w tym trwałość, próby i awarie

Ale czy Akka nie zapewnia tego bez całej wymaganej infrastruktury i kosztów operacyjnych?

W Akce cała komunikacja z aktorem jest asynchroniczna i nie blokuje; i
W Akka SupervisorStrategiesistnieją, aby wykonać próbę, wycofanie i eskalację. Podmioty mogą zostać skonfigurowane tak, aby utrzymywały się praktycznie w każdym sklepie, jeśli jest to również wymagane.

Zastanawiam się więc: czy moja aplikacja korzysta z Akka, czy kiedykolwiek muszę przedstawiać brokerów JMS / AMQP (np. ActiveMQ, RabbitMQ, Kafka)? Innymi słowy, czy kiedykolwiek zdarzy się przypadek użycia, w którym nowa aplikacja oparta na Akce również uzasadniałaby wprowadzenie nowego klastra brokera JMS / AMQP? Dlaczego lub dlaczego nie?

Jedynym argumentem byłoby to, że być może moja aplikacja Akka musi się zintegrować z innym systemem. Ale w takim przypadku moduł Akka-Camel pozwala Akce skorzystać z wyczerpującej, prawie nieskończonej listy możliwości integracji Camela (TCP, FTP, ZeroMQ, lista jest długa ...).

Myśli?

— smeeb
źródło

Czy twój ostatni akapit nie jest powodem, dla którego Akka nie czyni brokerów wiadomości przestarzałymi? Na przykład pracuję nad aplikacją Java, która współdziała ze zdalnymi aplikacjami C ++ za pośrednictwem brokera komunikatów zgodnego z JMS. Mógłbym napisać moją aplikację Java za pomocą Akka-Camel, ale nadal potrzebowałbym brokera z powodu aplikacji C ++.

— Thomas Owens

Ahhh dzięki @ThomasOwens (+1), ale (słusznie) źle zrozumiałeś moje pytanie. Zmienię sformułowanie za kilka minut, aby było bardziej oczywiste. Co ja naprawdę pytaniem jest: czy buduję aplikację Akka, bym kiedykolwiek trzeba również wprowadzić nową JMS / AMQP brokera? Myślę, że odpowiedź brzmi „nie”, ponieważ Akka + Camel (znowu myślę ) rozwiązuje wszystkie problemy zazwyczaj rozwiązywane przez brokera. W twoim przykładzie broker JMS już istnieje jako sposób komunikacji z aplikacją C ++; Nie dodam go wraz z moją nową aplikacją Akka. I tak moduł Akka-Camel zajmie się przesyłaniem wiadomości.

— smeeb

Może się mylę, ale Camel nie zastępuje JMS (na przykład), ale zapewnia interfejs, którego można używać do wysyłania wiadomości za pośrednictwem JMS. Możesz zamienić JMS na AMQP, RabbitMQ lub XMPP. W moim przykładzie, nawet jeśli moje aplikacje Java + Akka i C ++ były zupełnie nowe, aby mogły komunikować się przez JMS, nadal musiałbym wprowadzić jakąś kolejkę komunikatów zgodną z JMS, a następnie mogłem użyć Akka-Camel do komunikować się z tym. Wielbłąd nie zapewnia pośrednika, a jedynie środki komunikacji w ramach szeregu protokołów. Akka-Camel zapewnia bardziej znany interfejs w stosunku do interfejsu Camela.

— Thomas Owens

Jeszcze raz dziękuję @ThomasOwens (+1) - Myślę, że po prostu przesadzasz z tym :-). W twoim przykładzie istnieje istniejąca aplikacja C ++ - być może jakiś starszy system, i istnieje broker zgodny z JMS , którego aplikacja C ++ już używa do integracji ze światem zewnętrznym. W tym przypadku moja nowa aplikacja Akka używałaby - tak jak powiedziałeś - modułu Akka-Camel do tworzenia / odbierania wiadomości do / od tego brokera. Ale nie o to tu proszę! Zastanawiam się, czy kiedykolwiek istnieje powód, dla którego musiałbym zbudować 2 rzeczy : (1) moją nową aplikację Akka i (2) brokera JMS / AMQP, jednocześnie ...

— smeeb

Wspominasz o nieskończonych możliwościach integracji Camela, ale nie można go zintegrować z niczym. Musi być coś do zintegrowania, w przeciwnym razie po prostu cieszysz się wsparciem dla wielu usług, których nie używasz. Uruchom JMS, serwer HTTP lub FTP lub coś innego, jeśli chcesz używać Camel do integracji z czymś. W przeciwnym razie zapewnia błogie możliwości nieskończonej integracji, integrując się z niczym.

— Jimmy Hoffa

Model aktora

Model aktora jest strategią informatyczną do budowania aplikacji, które obsługują wiele jednoczesnych obliczeń i stanowego przetwarzania. Nie jest to jedyna strategia, ale jest to bardzo dobrze przetestowane, proste i niezawodne podejście, które przenosi obliczenia na aktorów , którzy komunikują się za pośrednictwem komunikatów, które przetwarzają pojedynczo i po kolei.

Akka to framework, który implementuje model aktora i pozwala budować systemy aktorskie z całą infrastrukturą i funkcjami już zbudowanymi (np. Używając JQuery zamiast javascript).

Wiadomości

Systemy wiadomości to aplikacje, które mogą wysyłać i pobierać wiadomości. Istnieje wiele odmian, od podstawowych kolejek po oprogramowanie dla dużych przedsiębiorstw z tematami, publikacjami / napisami, trwałością i innymi funkcjami, ale cel końcowy jest taki sam. Zapisz gdzieś bajty i odzyskaj je później, z pewnym porządkiem. Podstawowym przypadkiem dzisiejszego zastosowania jest rozdzielenie systemów i umożliwienie asynchronicznego przetwarzania przy różnych harmonogramach lub prędkościach. RabbitMQ, NATS, Kafka itp. To przykłady systemów wiadomości.

Porównanie

Model Actor i środowisko Akka to narzędzia niskiego poziomu, które są świetnym sposobem na tworzenie aplikacji , takich jak kolejki komunikatów.

Czy możesz używać Akka zamiast kolejki wiadomości? Pewnie. Jeśli budujesz oprogramowanie, które już korzysta z modelu aktora, prawdopodobnie nie potrzebujesz kolejki komunikatów zewnętrznych, szczególnie do wysyłania wiadomości w tym samym wątku lub aplikacji. Możesz użyć funkcji Akka Remoting, aby nawet wysyłać wiadomości do innych systemów aktorów działających na innych komputerach.

Czy jednak powoduje to, że systemy przesyłania komunikatów stają się przestarzałe? Absolutnie nie. Tylko dlatego, że możesz sam kodować wszystkie te rzeczy, nie oznacza to, że musisz, szczególnie gdy model aktora nie jest dobry dla twojego problemu lub potrzebujesz różnych języków, aplikacji, zewnętrznych interfejsów API, systemów operacyjnych, baz danych itp. ze sobą (czy są to systemy aktorskie, czy nie).

Jeśli potrzebujesz tylko przekazać niektóre wiadomości między dwoma systemami, użyj kolejki komunikatów. Jeśli potrzebujesz skalowalnego przetwarzania stanowego i komunikatów o niskim opóźnieniu w tej samej aplikacji, użyj modelu aktora. Oba istnieją na zupełnie różnych poziomach, a sposób ich użycia zależy od budowanego rozwiązania.

Istnieje świetna odpowiedź na temat SO na ten sam model aktorów w porównaniu do przesyłania wiadomości: /programming/5693346/when-to-use-actors-instead-of-messaging-solutions-such-as-websphere-mq- lub-Tibet

— Mani Gandham
źródło