Является ли Akka устаревшим брокером сообщений JMS / AMQP? [закрыто]

19

На прошлой неделе я глубоко погрузился в документы Akka и, наконец, понял, что такое системы актеров и какие проблемы они решают.

Мое понимание (и опыт работы) с традиционными JMS / AMQP брокерами сообщений заключается в том, что они существуют для обеспечения следующего:

  • Асинхронная обработка между производителем и потребителем; и
  • Гарантия доставки сообщений, включая постоянство, повторные попытки и откат

Но разве Акка не обеспечивает это без всей необходимой инфраструктуры и эксплуатационных расходов?

  • В Akka все коммуникации Actor являются асинхронными и неблокирующими; и
  • В Акке SupervisorStrategiesсуществуют попытки выполнить повторную попытку, восстановление и эскалацию. Актеры могут быть настроены на сохранение практически в любом типе хранилища, если это тоже требование.

Поэтому у меня возникает вопрос: если мое приложение использует Akka, возникает ли у меня необходимость привлечь брокеров JMS / AMQP (например, ActiveMQ, RabbitMQ, Kafka)? Другими словами, существует ли когда-либо сценарий использования, когда новое приложение на основе Akka будет также оправдывать введение нового кластера JMS / AMQP-брокера? Почему или почему нет?

Единственным аргументом будет то, что, возможно, мое приложение Akka должно интегрироваться с другой системой. Но в этом случае модуль Akka-Camel позволяет Akka использовать исчерпывающий, почти бесконечный список возможностей интеграции Camel (TCP, FTP, ZeroMQ, этот список можно продолжать и продолжать ...).

Мысли?

asynchronous-programming message-queue messaging akka smeeb
источник
3
Разве ваш последний абзац не является причиной, по которой Akka не делает брокеров сообщений устаревшими? Например, я работаю над приложением Java, которое взаимодействует с удаленными приложениями C ++ через JMS-совместимый брокер сообщений. Я мог бы написать свое Java-приложение, используя Akka-Camel, но мне все равно нужен брокер из-за приложения C ++.
Томас Оуэнс
Аааа, спасибо @ThomasOwens (+1), но вы (по праву так) неправильно поняли мой вопрос. Я изменю формулировку через несколько минут, чтобы она стала более очевидной. Что я действительно спрашиваю: если я создаю приложение Akka, нужно ли мне когда-нибудь также представлять нового JMS / AMQP-брокера? Я думаю, что ответ «нет», потому что Akka + Camel (опять же, я думаю ) решают все проблемы, обычно решаемые брокером. В вашем примере JMS-брокер уже существует как способ связи с приложением C ++; Я не добавляю его вместе с моим новым приложением Akka. И поэтому модуль Akka-Camel позаботится об обмене сообщениями за меня.
Смееб
2
Может быть, я неправильно понимаю, но Camel не заменяет JMS (например), но предоставляет интерфейс, который можно использовать для отправки сообщений через JMS. Вы можете заменить JMS на AMQP, RabbitMQ или XMPP. В моем примере, даже если бы мои приложения Java + Akka и C ++ были совершенно новыми, для того чтобы они могли взаимодействовать через JMS, мне все равно нужно было бы представить какую-то JMS-совместимую очередь сообщений, а затем я мог бы использовать Akka-Camel для общаться с этим. Camel не предоставляет брокера, а просто средство для общения по ряду протоколов. Akka-Camel предоставляет более знакомый интерфейс через интерфейс Camel.
Томас Оуэнс
Еще раз спасибо @ThomasOwens (+1) - я думаю, вы просто обдумываете это :-). В вашем примере есть существующее приложение C ++ - возможно, какая-то устаревшая система, и существует существующий JMS-совместимый брокер, который приложение C ++ уже использует для интеграции с внешним миром. В этом случае мое новое приложение Akka, как вы сказали, будет использовать модуль Akka-Camel для создания / приема сообщений от этого брокера. Но это не то, что я спрашиваю здесь! Мне интересно, есть ли причина, по которой мне нужно было бы построить 2 вещи : (1) мое новое приложение Akka и (2) брокер JMS / AMQP одновременно ...
smeeb
3
Вы упоминаете о бесконечных возможностях интеграции Camel, но они не могут интегрироваться ни с чем. Для этого должно быть что-то, с чем можно интегрироваться, иначе вы просто наслаждаетесь поддержкой множества сервисов, которые вы не используете. Поднимите JMS или HTTP или FTP-сервер или что-то, если вы хотите использовать Camel для интеграции с чем-либо. В противном случае это просто блаженство, обеспечивающее бесконечные возможности интеграции при интеграции с ничем.
Джимми Хоффа

Ответы:

12

Актер модель

Модель актора - это компьютерная стратегия для создания приложений, которые обрабатывают много параллельных вычислений и обработку состояний. Это не единственная стратегия, но это очень хорошо проверенный, простой и надежный подход, который переносит вычисления в участников , которые передают сообщения, которые они обрабатывают по одному и по порядку.

Akka - это фреймворк, реализующий модель акторов и позволяющий создавать системы акторов со всей уже созданной инфраструктурой и функциями (например, с использованием JQuery вместо javascript).

обмен сообщениями

Системы сообщений - это приложения, которые могут отправлять и получать сообщения. Существует множество разновидностей, от базовых очередей до крупномасштабного программного обеспечения с темами, публикациями / подпрограммами, постоянством и другими функциями, но конечная цель та же. Сохраните несколько байтов где-нибудь и получите их позже, с некоторым порядком. Основным вариантом использования сегодня является разъединение систем и обеспечение асинхронной обработки с разным графиком или скоростью. RabbitMQ, NATS, Kafka и т. Д. Являются примерами систем сообщений.

сравнение

Модель Actor и инфраструктура Akka являются низкоуровневыми инструментами, которые являются отличным способом создания приложений , таких как очереди сообщений.

Можете ли вы использовать Akka вместо очереди сообщений? Конечно. Если вы создаете программное обеспечение, в котором уже используется модель актора, вам, вероятно, не понадобится внешняя очередь сообщений, особенно для отправки сообщений в пределах одного потока или приложения. Вы можете использовать возможности Akka Remoting, чтобы даже отправлять сообщения другим акторам, работающим на других машинах.

Однако делает ли это системы обмена сообщениями устаревшими? Точно нет. Просто потому, что вы можете сами кодировать все эти вещи, не означает, что вам это нужно, особенно когда модель актера не подходит для вашей проблемы или вам нужны разные языки, приложения, внешние API, операционные системы, базы данных и т. Д. друг с другом (независимо от того, являются ли они актерскими системами или нет).

Если вам просто нужно передать несколько сообщений между двумя системами, используйте очередь сообщений. Если вам требуется масштабируемая обработка с отслеживанием состояния и обмен сообщениями с малой задержкой в ​​одном приложении, используйте модель актора. Они оба существуют на совершенно разных уровнях, и от того, как вы их используете, зависит решение, которое вы создаете.

На SO есть отличный ответ об этой же модели актера против обмена сообщениями: /programming/5693346/when-to-use-actors-instead-of-messaging-solutions-such-as-websphere-mq- или-TIBCO

Мани Гэндхэм
источник