Bom caso de uso para Akka [fechado]

Ouvi muitos elogios sobre o Akka framework (plataforma de serviço Java / Scala), mas até agora não vi muitos exemplos reais de casos de uso para os quais seria bom. Então, eu estaria interessado em ouvir sobre as coisas que os desenvolvedores usaram com sucesso.

Apenas uma limitação: não inclua o caso de escrever um servidor de bate-papo. (por quê? como isso foi usado em excesso como um exemplo para muitas coisas semelhantes)

Eu o usei até agora em dois projetos reais com muito sucesso. ambos estão no campo de informações de tráfego quase em tempo real (tráfego como em carros nas rodovias), distribuídos por vários nós, integrando mensagens entre várias partes, sistemas de back-end confiáveis. Ainda não tenho a liberdade de especificar detalhes sobre os clientes, quando eu receber o OK, talvez ele possa ser adicionado como referência.

A Akka realmente se destacou nesses projetos, apesar de termos começado na versão 0.7. (estamos usando scala por sinal)

Uma das grandes vantagens é a facilidade com que você pode compor um sistema a partir de atores e mensagens quase sem caldeira, dimensiona-se extremamente bem sem todas as complexidades da segmentação manual e você recebe mensagens assíncronas passando entre objetos quase de graça.

É muito bom na modelagem de qualquer tipo de manipulação de mensagens assíncronas. Eu preferiria escrever qualquer tipo de sistema de serviços (web) nesse estilo do que qualquer outro estilo. (Você já tentou escrever um serviço da Web assíncrono (lado do servidor) com JAX-WS? Isso é muito complicado). Então, eu diria que qualquer sistema que não deseja travar em um de seus componentes, porque tudo é chamado implicitamente usando métodos síncronos, e que um componente está travando em alguma coisa. É muito estável e a solução para falhas do supervisor let-it-crash + realmente funciona bem. Tudo é fácil de configurar programaticamente e não é difícil fazer o teste de unidade.

Depois, existem os excelentes módulos complementares. O módulo Camel realmente se conecta bem ao Akka e permite um desenvolvimento tão fácil de serviços assíncronos com pontos de extremidade configuráveis.

Estou muito feliz com a estrutura e ela está se tornando um padrão defacto para os sistemas conectados que construímos.

Disclaimer: Eu sou o PO da Akka

Além de oferecer um smorgasbord de simultaneidade que é muito mais simples de raciocinar e se corrigir (atores, agentes, simultaneidade de fluxo de dados) e com controle de simultaneidade na forma de STM.

Aqui estão alguns casos de uso que você pode considerar:

1. Processamento de transações (jogos online, finanças, estatísticas, apostas, mídias sociais, telecomunicações, ...)
   • ampliar, dimensionar, tolerância a falhas / HA
2. Serviço de back-end (qualquer setor, qualquer aplicativo)
   • serviço REST, SOAP, cometa etc
   • agir como hub de mensagens / camada de integração
   • ampliar, dimensionar, tolerância a falhas / HA
3. Simultaneidade / paralelismo de snap-in (qualquer aplicativo)
   • Corrigir
   • Simples de trabalhar e entender
   • Basta adicionar os jars ao seu projeto JVM existente (use Scala, Java, Groovy ou JRuby)
4. Processamento em lote (qualquer setor)
   • Integração de camelo para conectar-se a fontes de dados em lote
   • Os atores dividem e conquistam as cargas de trabalho em lote
5. Hub de comunicações (telecomunicações, mídia da web, mídia móvel)
   • ampliar, dimensionar, tolerância a falhas / HA
6. Servidor de jogos (jogos online, apostas)
   • ampliar, dimensionar, tolerância a falhas / HA
7. BI / datamining / trituração de uso geral
   • ampliar, dimensionar, tolerância a falhas / HA
8. insira outros casos de uso legais aqui

Um exemplo de como o usamos seria em uma fila prioritária de transações com cartão de débito / crédito. Temos milhões deles e o esforço do trabalho depende do tipo de string de entrada. Se a transação é do tipo CHECK, temos muito pouco processamento, mas se é um ponto de venda, há muito o que fazer, como mesclar com metadados (categoria, rótulo, tags, etc.) e fornecer serviços (alertas por email / sms, detecção de fraudes, baixo saldo de fundos, etc). Com base no tipo de entrada, compomos classes de várias características (chamadas mixins) necessárias para lidar com o trabalho e depois executar o trabalho. Todos esses trabalhos entram na mesma fila no modo em tempo real de diferentes instituições financeiras. Depois que os dados são limpos, eles são enviados para diferentes armazenamentos de dados para persistência, análise ou envio por push a uma conexão de soquete ou para o ator Lift cometa. Os atores que trabalham são constantemente auto-balanceados, para que possamos processar os dados o mais rápido possível. Também podemos obter serviços adicionais, modelos de persistência estm para pontos críticos de decisão.

A mensagem de estilo Erlang OTP transmitida na JVM é um ótimo sistema para o desenvolvimento de sistemas em tempo real nas costas das bibliotecas e servidores de aplicativos existentes.

O Akka permite que você faça a passagem de mensagens como faria em um esbmas com velocidade! Também fornece ferramentas na estrutura para gerenciar a grande quantidade de conjuntos de atores, nós remotos e tolerância a falhas que você precisa para sua solução.

Usamos o Akka para processar chamadas REST de forma assíncrona - juntamente com o servidor da Web assíncrono (baseado em Netty), podemos obter uma melhoria de 10 vezes no número de usuários atendidos por nó / servidor, comparando com o modelo tradicional de solicitação por usuário / thread.

Diga ao seu chefe que a sua conta de hospedagem da AWS vai cair pelo fator 10 e é um acéfalo! Shh ... não conte para a Amazon embora ... :)

Estamos usando o Akka em um projeto Telco em larga escala (infelizmente não posso divulgar muitos detalhes). Os atores Akka são implantados e acessados ​​remotamente por um aplicativo da web. Dessa forma, temos um modelo RPC simplificado baseado no protobuffer do Google e alcançamos o paralelismo usando o Akka Futures. Até agora, este modelo funcionou brilhantemente. Uma observação: estamos usando a API Java.

Se você abstrair o servidor de bate-papo em um nível superior, obterá a resposta.

A Akka fornece um sistema de mensagens semelhante à mentalidade de "deixar bater" de Erlang.

Portanto, exemplos são coisas que precisam de níveis variados de durabilidade e confiabilidade das mensagens:

• Servidor de bate-papo
• Camada de rede para um MMO
• Bomba de dados financeiros
• Sistema de notificação para um aplicativo para iPhone / celular / qualquer que seja
• Servidor REST
• Talvez algo parecido com o WebMachine (suposição)

As coisas boas do Akka são as opções que ele oferece para persistência, é implementação do STM, servidor REST e tolerância a falhas.

Não fique chateado com o exemplo de um servidor de bate-papo, pense nele como um exemplo de uma certa classe de solução.

Com toda sua excelente documentação, sinto que uma lacuna é essa pergunta exata, casos de uso e exemplos. Tendo em mente os exemplos não são triviais.

(Escrito apenas com a experiência de assistir a vídeos e brincar com a fonte, não implementei nada usando o akka.)

Usamos o Akka em vários projetos em andamento, o mais interessante deles relacionado ao reparo de colisão de veículos. Principalmente no Reino Unido, mas agora expandindo para os EUA, Ásia, Australásia e Europa. Utilizamos atores para garantir que as informações sobre reparo em acidentes sejam fornecidas em tempo real para permitir o reparo seguro e econômico de veículos.

A questão com a Akka é realmente mais 'o que você não pode fazer com a Akka'. Sua capacidade de integração com estruturas poderosas, sua poderosa abstração e todos os aspectos de tolerância a falhas o tornam um kit de ferramentas muito abrangente.

Você pode usar o Akka para vários tipos diferentes de coisas.

Eu estava trabalhando em um site, onde migrei a pilha de tecnologia para Scala e Akka. Nós o usamos para praticamente tudo o que aconteceu no site. Mesmo que você pense que um exemplo de bate-papo é ruim, todos são basicamente iguais:

• Atualizações ao vivo no site (por exemplo, visualizações, curtidas, ...)
• Mostrando comentários de usuários ao vivo
• Serviços de notificação
• Pesquisa e todos os outros tipos de serviços

Especialmente, as atualizações ao vivo são fáceis, pois se resumem ao que é um exemplo de bate-papo. A parte de serviços é outro tópico interessante, porque você pode simplesmente optar por usar atores remotos e, mesmo que seu aplicativo não esteja em cluster, você pode implantá-lo em diferentes máquinas com facilidade.

Também estou usando o Akka para um aplicativo de autorouter de PCBs com a idéia de poder escalar de um laptop para um data center. Quanto mais energia você der, melhor será o resultado. Isso é extremamente difícil de implementar se você tentar usar a simultaneidade usual, porque o Akka também oferece transparência de localização.

Atualmente, como um projeto de tempo livre, estou construindo uma estrutura da Web usando apenas atores. Novamente, os benefícios são a escalabilidade de uma única máquina para um cluster inteiro de máquinas. Além disso, o uso de uma abordagem orientada a mensagens torna o serviço de software orientado desde o início. Você tem todos esses componentes legais, conversando entre si, mas não necessariamente se conhecendo, vivendo na mesma máquina, nem mesmo no mesmo data center.

E desde que o Google Reader foi desligado, comecei com um leitor de RSS, usando o Akka, é claro. É tudo sobre serviços encapsulados para mim. Como conclusão: o próprio modelo de ator é o que você deve adotar primeiro e o Akka é uma estrutura muito confiável, ajudando você a implementá-lo com muitos benefícios que você receberá ao longo do caminho.

Estamos usando o akka com seu plug-in camel para distribuir nossa análise e processamento de tendências para twimpact.com . Temos que processar entre 50 e 1000 mensagens por segundo. Além do processamento de vários nós com camelo, também é usado para distribuir o trabalho em um único processador para vários trabalhadores para obter o máximo desempenho. Funciona muito bem, mas requer alguma compreensão de como lidar com congestionamentos.

Eu estava tentando minhas mãos no Akka (Java api). O que tentei foi comparar o modelo de concorrência baseado em ator da Akka com o modelo de concorrência Java simples (classes java.util.concurrent).

O caso de uso era um mapa canônico simples, reduzindo a implementação da contagem de caracteres. O conjunto de dados era uma coleção de seqüências geradas aleatoriamente (400 caracteres de comprimento) e calculava o número de vogais nelas.

Para a Akka, usei um BalancedDispatcher (para balanceamento de carga entre threads) e RoundRobinRouter (para manter um limite nos meus atores de função). Para Java, usei a técnica simples de junção de bifurcação (implementada sem nenhum algoritmo de roubo de trabalho) que mapearia / reduziria execuções e juntaria os resultados. Resultados intermediários foram realizados em filas de bloqueio para tornar a junção o mais paralela possível. Provavelmente, se não estou errado, isso imitaria de alguma forma o conceito de "caixa de correio" dos atores Akka, onde eles recebem mensagens.

Observação: Até cargas médias (~ 50000 entradas de string), os resultados foram comparáveis, variando ligeiramente em diferentes iterações. No entanto, conforme eu aumentava minha carga para ~ 100000, a solução Java era interrompida. Eu configurei a solução Java com 20 a 30 threads sob essa condição e ela falhou em todas as iterações.

Aumentar a carga para 1000000, também foi fatal para a Akka. Posso compartilhar o código com qualquer pessoa interessada em fazer uma verificação cruzada.

Então, para mim, o Akka parece melhor do que a solução multithread Java tradicional. E provavelmente o motivo é a mágica oculta de Scala.

Se eu puder modelar um domínio de problema como uma mensagem orientada a eventos passando uma, acho que o Akka é uma boa opção para a JVM.

Teste realizado em: versão Java: 1.6 IDE: Eclipse 3.7 Windows Vista 32 bits. 3GB de RAM. Processador Intel Core i5, velocidade de clock de 2,5 GHz

Observe que o domínio do problema usado para o teste pode ser debatido e tentei ser o mais justo que meu conhecimento de Java permitia :-)

Usamos Akka em sistemas de diálogo falado ( primetalk ). Internamente e externamente. Para executar simultaneamente muitos canais de telefonia em um único nó do cluster, é obviamente necessário ter alguma estrutura de multithreading. Akka funciona perfeitamente. Temos um pesadelo anterior com a concorrência de java. E com a Akka é como um balanço - simplesmente funciona. Robusto e confiável. 24 * 7, sem parar.

Dentro de um canal, temos um fluxo de eventos em tempo real que são processados ​​em paralelo. Em particular: - reconhecimento de fala automático demorado - é feito com um ator; - produtor de saída de áudio que mistura algumas fontes de áudio (incluindo fala sintetizada); - a conversão de texto em fala é um conjunto separado de atores compartilhados entre canais; - processamento semântico e de conhecimento.

Para fazer interconexões do processamento complexo de sinais, usamos o SynapseGrid . Ele tem o benefício da verificação em tempo de compilação do DataFlow nos sistemas de atores complexos.

Eu recentemente implementei o exemplo canônico de redução de mapa no Akka: contagem de palavras. Portanto, é um caso de uso da Akka: melhor desempenho. Foi mais um experimento dos atores de JRuby e Akka do que qualquer outra coisa, mas também mostra que Akka não é apenas Scala ou Java: funciona em todas as linguagens da JVM.