Akka.Net - cenários reais de uso

5

Agora estou tentando entender o modelo de ator. Eu conheço conceitos principais como e tudo é um ator etc. Eu vejo muitas palavras como "é muito bom do ponto de vista do desempenho", "sem bloqueios porque não há recursos compartilhados e as mensagens são imutáveis ". Mas ainda não entendi alguns pontos:

  1. No caso da aplicação CRUD old school, faz sentido substituir o processamento simples da solicitação UI > BL- > DL pelo sistema de agente? Se não, quais cenários reais do modelo de ator de uso? Estou perguntando não sobre

Transaction processing (Online Gaming, Finance/Banking, Trading, Statistics, Betting, Social Media, Telecom), Service backend (any industry, any app)...

mas sobre casos reais de uso. Porque para mim ainda não está claro por que eu deveria preferir Akka.NET (eu sou .net desenvolvedor) em vez de maneira "tradicional".

  1. O modelo e o banco de dados do ator residem em um mundo ou em paralelo? Como eles trabalham juntos?
  2. Último pensamento: o modelo de ator evita desvantagens da sincronização de threads porque funciona usando mensagens. Mas se eu precisar ter acesso a recursos compartilhados, como algum cache estático ou algo assim, ainda preciso de sincronização. Eu realmente não entendo esse ponto.
por mtkachenko 12.02.2017 / 16:02
fonte

2 respostas

3

Eu acho que sua pergunta não é específica do Akka.NET exclusivamente. Então eu vou responder sendo o desenvolvedor Akka / Scala.

0 Nem tudo é um ator. Funções ainda são funções com toda a composição funcional e pureza.

  1. O modelo de ator se torna muito útil quando você se estende além do CRUD na terra do Design Orientado a Domínio e da Arquitetura Hexagonal.
  2. Não posso dizer para o .NET, mas no mundo da JVM a maioria das chamadas de banco de dados (JDBC) está bloqueando. Enquanto isso, o sistema de ator geralmente funciona em um conjunto limitado de threads comparado ao tamanho do número de núcleos de CPU. Portanto, se o seu sistema de agente trabalhar com o bloqueio de chamadas, o Akka permitirá configurar o conjunto de encadeamentos separado para esse subsistema, ou seja, a subárvore da árvore de supervisão do sistema do agente. Assim, você pode deixar seu núcleo de negócios não bloqueado com 4 encadeamentos e fornecer 200 encadeamentos para o subsistema de armazenamento.
  3. Estruturas de dados imutáveis (persistentes e funcionais) são a chave. Você não precisa de sincronização para usá-los. Embora às vezes você precise passar uma referência para, por exemplo, ByteStream. Bem, você deve verificar se o remetente não tenta trabalhar com a instância depois que ela foi enviada.

Em geral, qual é a principal diferença entre as implementações de Erlang e Akka? Em Erlang, cada ator tem seu próprio heap e coletor de lixo. Daí, nenhum estado mutável compartilhado, nenhum stop-the-world gc. Isso nos dá uma qualidade suave em tempo real. Mas você paga na cópia de dados de ator para ator. Na JVM (e .NET?), O heap e o gc são compartilhados. Você não tem sobrecarga como em Erlang, mas deve ser disciplinado a não atirar em seu próprio pé.

Agora, alguns casos de uso que eu mesmo encontrei. Você conhece o RabbitMQ: trocas, filas, ligações ... Se a conexão falhar - alguns drivers podem redecorá-los automaticamente. Eu implementei essa lógica com Akka, porque o motorista não atendia às minhas necessidades. Primeiro foi difícil descobrir essa lógica, mas depois de um conseguiu separar, o que era efêmero, e o que deveria persistir no fracasso - as coisas clicaram. O primeiro foi para os atores trabalhadores, enquanto a carta residia nos adereços do ator (que é efetivamente uma configuração de instância do ator) e nos supervisores. É isso que significa quando você ouve falar de resiliência e autocura do ator. Ele não está pronto para uso, mas os atores ajudam muito a implementar essa lógica da forma mais direta possível, logo depois que você a descobre.

Arquitetura hexagonal e simultaneidade. Eu implementei o CAS 3.0 Protocol Specification para necessidades internas usando o Akka.

Primeiro de tudo, núcleo de negócios, servidor http, cliente http, interação db - todos foram separados em diferentes subsistemas de ator e tinham uma superfície de interação clara. Você pode testá-los separadamente. Núcleo de negócios não sabe, o que é um protocolo http. Só sabia como lidar com comandos de negócios. Não sabe nada sobre o db incluindo interfaces. Só sabe quais mensagens enviar e o que receber. E o ActorRef do db, claro.

Em segundo lugar, no protocolo CAS, existem algumas coisas que você precisa verificar para uma única solicitação do usuário. Então, eu implementei cada cheque em atores de trabalho separados. Eles são configurados com o necessário ActorRef-s e um tempo limite. Ou eles terminam o processamento antes do tempo limite e cometem suicídio, ou o tempo limite é atingido, e a resposta de erro de produção e, novamente, cometem suicídio. Enquanto isso, existem outros atores, que eu chamo de serviços. Eles atuam como supervisores para os trabalhadores mencionados e existiam desde que todo o tempo de execução. Seus ActorRef-s são endereços estáticos, que você pode usar para configurar diferentes componentes de tempo de execução durante a inicialização do aplicativo.

Espero que isso ajude

    
por 17.03.2017 / 12:33
fonte
1

As razões pelas quais você usaria o Akka.NET estão listadas na primeira página do site. Você usaria quando precisasse de concorrência simples & computação distribuída, usando abstrações de alto nível, como Atores e Máquinas de estados finitos, em vez de threads e corrotinas.

Algumas outras características da Akka:

  • Alto desempenho: 50 milhões de msg / s em uma única máquina. Pegada de memória pequena; ~ 2,5 milhões de atores por GB de heap.

  • Resilientes pelo design: Escreva sistemas que se auto-curam. Hierarquias de supervisor remoto e / ou local.

  • elástico & Descentralizada: balanceamento de carga adaptável, roteamento, particionamento e comunicação remota orientada por configuração.

Cada ator acessa o estado compartilhado (como um banco de dados ou cache), como qualquer outro programa faria. O banco de dados cuida da sincronização para você.

Você não necessariamente usaria o Akka.NET com operações CRUD comuns. Em vez disso, o Akka.NET entra em ação quando você inicia a funcionalidade que precisa das características descritas acima.

    
por 12.02.2017 / 17:36
fonte