O Akka obsoleta os intermediários de mensagens JMS / AMQP? [fechadas]

Fechado . Esta questão é baseada em opiniões . No momento, não está aceitando respostas.

Deseja melhorar esta pergunta? Atualize a pergunta para que ela possa ser respondida com fatos e citações editando esta postagem .

Fechado há 4 anos .

Passei a última semana mergulhando profundamente nos documentos da Akka e finalmente entendendo o que são os sistemas de atores e os problemas que eles resolvem.

Meu entendimento (e experiência) com os intermediários de mensagens JMS / AMQP tradicionais é que eles existem para fornecer o seguinte:

Processamento assíncrono entre produtor e consumidor; e
Garantia de entrega de mensagens, persistência, tentativas e fallbacks incluídos

Mas a Akka não fornece isso, sem toda a infraestrutura necessária e as despesas operacionais?

No Akka, toda a comunicação com o ator é assíncrona e sem bloqueio; e
Em Akka, SupervisorStrategiesexistem para realizar novas tentativas, fallback e escalação. Os atores podem ser configurados para persistir em praticamente qualquer tipo de loja, se isso também for um requisito.

Então, isso me fez pensar: se meu aplicativo usa o Akka, é necessário trazer os agentes JMS / AMQP (por exemplo, ActiveMQ, RabbitMQ, Kafka)? Em outras palavras, existe um caso de uso em que um novo aplicativo baseado em Akka também justificaria a introdução de um novo cluster do JMS / AMQP broker? Por que ou por que não?

O único argumento seria que talvez meu aplicativo Akka precise se integrar a outro sistema. Mas, nesse caso, o módulo Akka-Camel permite que a Akka aproveite a lista exaustiva e quase infinita de recursos de integração do Camel (TCP, FTP, ZeroMQ, a lista continua ...).

Pensamentos?

— smeeb
fonte

O seu último parágrafo não é uma razão pela qual a Akka não torna obsoletos os intermediários de mensagens? Por exemplo, estou trabalhando em um aplicativo Java que interage com aplicativos remotos C ++ por meio de um intermediário de mensagens compatível com JMS. Eu poderia escrever meu aplicativo Java usando Akka-Camel, mas ainda precisaria do broker por causa do aplicativo C ++.

— Thomas Owens

Ahhh, obrigado @ThomasOwens (+1), mas você (com razão) não entendeu minha pergunta. Vou mudar a redação em alguns minutos, para que fique mais óbvio. O que realmente estou perguntando é: se estou criando um aplicativo Akka, precisaria também introduzir um novo broker JMS / AMQP? Eu acho que a resposta é "não", porque a Akka + Camel (novamente eu acho ) resolve todos os problemas normalmente resolvidos por um corretor. No seu exemplo, o broker JMS já existe como a maneira de se comunicar com o aplicativo C ++; Não o estou adicionando ao meu novo aplicativo Akka. E assim o módulo Akka-Camel cuidará das mensagens para mim.

— smeeb

Talvez eu esteja entendendo mal, mas o Camel não substitui o JMS (por exemplo), mas fornece uma interface que pode ser usada para enviar mensagens via JMS. É possível substituir o JMS por AMQP, RabbitMQ ou XMPP. No meu exemplo, mesmo que meus aplicativos Java + Akka e C ++ fossem novos, para que eles se comuniquem pelo JMS, ainda seria necessário introduzir algum tipo de fila de mensagens compatível com JMS e então eu poderia usar o Akka-Camel para comunicar com ele. Camel não fornece um corretor, apenas meios para se comunicar dentro de vários protocolos. O Akka-Camel fornece uma interface mais familiar sobre a interface do Camel.

— Thomas Owens

Mais uma vez obrigado @ThomasOwens (+1) - Acho que você está pensando demais :-). No seu exemplo, existe um aplicativo C ++ existente - talvez algum sistema legado, e existe um broker compatível com JMS existente que o aplicativo C ++ já usa para integração com o mundo externo. Nesse caso, meu novo aplicativo Akka usaria, como você disse, o módulo Akka-Camel para produzir / consumir mensagens de / para este broker. Mas não é isso que estou perguntando aqui! Eu estou querendo saber se há sempre uma razão que eu precisaria para construir 2 coisas : (1) o meu novo aplicativo Akka, e (2) um corretor JMS / AMQP, ao mesmo tempo ...

— smeeb

Você menciona as infinitas capacidades de integração do Camel, mas ele não pode se integrar ao Nothing. Precisa haver algo para se integrar, caso contrário, você está apenas desfrutando do suporte a vários serviços que não está executando. Inicie o JMS, um servidor HTTP ou FTP ou algo assim, se desejar usar o Camel para integrar-se a algo. Caso contrário, é apenas um prazer em fornecer recursos de integração infinitos enquanto se integra com nada.

— Jimmy Hoffa

Modelo do ator

O modelo de ator é uma estratégia de ciência da computação para criar aplicativos que lidam com muita computação simultânea e processamento com estado. Não é a única estratégia, mas é uma abordagem muito bem testada, simples e confiável que move a computação para os atores , que se comunicam por meio de mensagens que eles processam uma de cada vez e em ordem.

O Akka é uma estrutura que implementa o modelo de ator e permite que você construa sistemas de atores com toda a infraestrutura e recursos já construídos (como usar JQuery em vez de javascript).

Mensagens

Os sistemas de mensagens são aplicativos que podem enviar e recuperar mensagens. Existem muitas variedades, de filas básicas a softwares para grandes empresas, com tópicos, pub / sub, persistência e outros recursos, mas o objetivo final é o mesmo. Salve alguns bytes em algum lugar e recupere-os mais tarde, com algum tipo de pedido. O principal caso de uso hoje é desacoplar sistemas e permitir o processamento assíncrono em diferentes agendamentos ou velocidades. RabbitMQ, NATS, Kafka, etc, são exemplos de sistemas de mensagens.

Comparação

O modelo Actor e a estrutura Akka são ferramentas de baixo nível que são uma ótima maneira de criar aplicativos , como filas de mensagens.

Você pode usar o Akka em vez de uma fila de mensagens? Certo. Se você está criando um software que já usa o modelo de ator, provavelmente não precisa de uma fila de mensagens externa, especialmente para enviar mensagens no mesmo encadeamento ou aplicativo. Você pode usar os recursos do Akka Remoting para enviar mensagens para outros sistemas de atores em execução em outras máquinas.

No entanto, isso torna os sistemas de mensagens obsoletos? Absolutamente não. Só porque você pode codificar tudo isso não significa que você precisa, especialmente quando um modelo de ator não é bom para o seu problema ou você precisa de diferentes idiomas, aplicativos, APIs externas, sistemas operacionais, bancos de dados etc. para se comunicar uns com os outros (sejam eles sistemas de atores ou não).

Se você só precisa passar algumas mensagens entre dois sistemas, use uma fila de mensagens. Se você precisar de processamento com estado escalável e mensagens de baixa latência no mesmo aplicativo, use o modelo de ator. Ambos existem em níveis completamente diferentes e como você os utiliza depende da solução que você está construindo.

Há uma ótima resposta no SO sobre esse mesmo modelo de ator x sistema de mensagens: /programming/5693346/when-to-use-actors-instead-of-messaging-solutions-such-as-websphere-mq- or-tibco

— Mani Gandham
fonte