java - trigger - ▪ especificação dos casos de uso fluxos principais e de exceção




Bom caso de uso para Akka (8)

Já ouvi falar muito sobre o framework Akka (plataforma de serviços 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 coisas que os desenvolvedores usaram com sucesso.

Apenas uma limitação: por favor, não inclua caso de escrever um servidor de chat. (porque? porque isso tem sido usado como um exemplo para muitas coisas semelhantes)


Disclaimer: Eu sou o PO para Akka

Além de oferecer um smorgasbord de concorrência que é muito mais simples de raciocinar e obter correto (atores, agentes, simultaneidade de fluxo de dados) e com controle de concorrência 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, ...)
    • scale up, scale out, tolerância a falhas / HA
  2. Backend de serviço (qualquer setor, qualquer aplicativo)
    • serviço REST, SOAP, cometd etc
    • atuar como hub de mensagem / camada de integração
    • scale up, scale out, tolerância a falhas / HA
  3. Concordância de snap-in / paralelismo (qualquer aplicativo)
    • Corrigir
    • Simples de trabalhar e entender
    • Basta adicionar os jars ao seu projeto de JVM existente (use Scala, Java, Groovy ou JRuby)
  4. Processamento em lote (qualquer setor)
    • Integração de camelos para se conectar a fontes de dados em lote
    • 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)
    • scale up, scale out, tolerância a falhas / HA
  6. Servidor de jogos (jogos online, apostas)
    • scale up, scale out, tolerância a falhas / HA
  7. BI / datamining / trituração de propósito geral
    • scale up, scale out, tolerância a falhas / HA
  8. insira outros casos de uso agradáveis ​​aqui

Estamos usando a Akka em um projeto de larga escala da Telco (infelizmente não posso divulgar muitos detalhes). Atores Akka são implementados 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, esse modelo funcionou brilhantemente. Uma nota: estamos usando a API Java.


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

O caso de uso foi um mapa canônico simples para reduzir a implementação da contagem de caracteres. O conjunto de dados era uma coleção de strings geradas aleatoriamente (400 caracteres de comprimento) e calculava o número de vogais contidas nelas.

Para Akka eu usei um BalancedDispatcher (para balanceamento de carga entre threads) e RoundRobinRouter (para manter um limite em meus atores de função). Para Java, usei a técnica de junção bifurcada simples (implementada sem qualquer algoritmo de roubo de trabalho) que unificasse / reduzisse as execuções e unisse os resultados. Os resultados intermediários foram mantidos em filas de bloqueio para tornar a união o mais paralela possível. Provavelmente, se eu não estiver errado, isso imitaria de alguma forma o conceito de "caixa postal" dos atores Akka, onde eles recebem mensagens.

Observação: Até as cargas médias (~ entrada de 50000 cordas) os resultados foram comparáveis, variando ligeiramente em diferentes iterações. No entanto, à medida que aumentava minha carga para ~ 100000, a solução Java era suspensa. Eu configurei a solução Java com 20-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, parece que a Akka se sai melhor do que a tradicional solução multithread de Java. E provavelmente a razão é a mágica sob o capô do Scala.

Se eu puder modelar um domínio de problema como uma mensagem orientada a eventos passando um, 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 bit. 3 GB de ram. Processador Intel Core i5, velocidade de clock de 2,5 GHz

Por favor, note que o domínio do problema usado para o teste pode ser debatido e eu tentei ser tão justo quanto o meu conhecimento de Java permitiu :-)


Eu recentemente implemented o exemplo canonical map-reduce em Akka: Word count. Portanto, é um caso de uso da Akka: melhor desempenho. Foi mais uma experiência de 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 sobre a JVM.


Se você abstrair o servidor de bate-papo, você receberá a resposta.

A Akka fornece um sistema de mensagens que é semelhante à mentalidade de "deixar cair" de Erlang.

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

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

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

Não fique irritado com o exemplo de um servidor de bate-papo, pense nisso como um exemplo de uma determinada classe de solução.

Com toda a sua excelente documentação, sinto que uma lacuna é exatamente essa questão, 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 akka.)


Um exemplo de como o utilizamos seria em uma fila de prioridade de transações com cartão de débito / crédito. Nós temos milhões deles e o esforço do trabalho depende do tipo de string de entrada. Se a transação for do tipo CHECK, temos muito pouco processamento, mas se for um ponto de venda, há muito a fazer, como mesclar com metadados (categoria, rótulo, tags, etc) e fornecer serviços (alertas de email / sms, detecção de fraude, baixo saldo de fundos, etc). Com base no tipo de entrada, nós compomos classes de vários traços (chamados mixins) necessários 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, analítica ou enviados por push para uma conexão de soquete ou para o operador Aumentar cometa. Os atores que trabalham são constantemente auto-carregados, equilibrando o trabalho para que possamos processar os dados o mais rápido possível. Também podemos encaixar serviços adicionais, modelos de persistência e stm para pontos de decisão críticos.

A mensagem de estilo Erlang OTP transmitindo a JVM cria um ótimo sistema para o desenvolvimento de sistemas em tempo real sobre os ombros de bibliotecas e servidores de aplicativos existentes.

Akka permite que você faça a mensagem passando como você faria em um esb tradicional, mas com velocidade! Ele também fornece ferramentas na estrutura para gerenciar a grande quantidade de pools de atores, nós remotos e tolerância a falhas que você precisa para sua solução.


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

A questão com Akka é realmente mais "o que você não pode fazer com 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.


Usamos o Akka para processar chamadas REST de forma assíncrona - em conjunto com o servidor web assíncrono (com base no 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 de thread por usuário.

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





akka