Os sistemas Erlang devem ser monolíticos?

5

Os sistemas Erlang (ou qualquer coisa que funcione na VM do BEAM) devem ser monolíticos, isto é, tudo funcionando no mesmo aplicativo distribuído, ou devem ser divididos em múltiplos microservices como qualquer loja de python / go / c ++ faria?

Como cada processo em Erlang tem seu próprio espaço de memória, parece que eles se comportam como microsserviços internamente e, portanto, um único aplicativo Erlang deve ser suficiente, mas talvez haja algo que eu tenha esquecido?

    
por Filip Haglund 03.06.2016 / 12:45
fonte

2 respostas

2

Por favor, note que não há conceito de namespace ou isolamento do processo dentro do Erlang VM. Você pode ter apenas um módulo com um nome específico, então, se você tentar executar muitos aplicativos diferentes, você poderá acabar com nomes conflitantes.

Tendo dito isto, não há nada que impeça uma VM Erlang de pegar todos os recursos disponíveis e crescer o tamanho que for necessário. Eu trabalhei com sistemas executando uma única VM em 32 sistemas de CPU com 100 GB de memória. O BEAM simplesmente lança um agendador por CPU e distribui os processos Erlang por todos os recursos disponíveis.

É mais uma questão de carga antecipada, escalabilidade de desenvolvimento e o design da arquitetura geral. Alguns pontos a considerar:

  1. Cada nó é atualizado como uma unidade - se algo der errado, a única VM falha e precisa para ser reiniciado. Imagine que o nó rodando em 32 CPUs, levando 100 GB de memória, e lidando com centenas de milhares de usuários por vez, falha durante a atualização do software e iniciar demora uma hora, porque é o tempo que leva para carregar os dados do banco de dados para a memória. Se esse é o seu cenário, você pode querer desacoplar o nó em múltiplos micro serviços que podem ser atualizados isoladamente. No entanto, se você tem 10 nós como esse e o tráfego é distribuído entre eles, então você pode usar a rota de menor resistência.

  2. Devido à falta de namespaces e isolamento de processos do ponto de vista de desenvolvimento, pode ser mais fácil manter um repositório comum com todos os aplicativos (para evitar conflito de nomes), mas criar vários Erlang releases , cada um executando um serviço específico usando apenas uma seleção de aplicativos disponíveis naquele repositório (micro-serviço).

  3. O teste é muito mais fácil se você tiver vários microsserviços que podem ser testados isoladamente, onde os outros nós são ridicularizados do que se você tivesse um grande nó multiuso para fazer tudo e a pia da cozinha.

por 03.06.2016 / 18:29
fonte
1

O Erlang foi projetado para ser massivamente escalável. Os processos Erlang são leves; você pode ter milhões deles, se quiser. Assim, cada "microserviço" ao qual você se refere provavelmente mapeará para várias instâncias Erlang.

Provavelmente é mais útil pensar em cada microsserviço como um Módulo , não como um processo. Minha sugestão seria criar um módulo para cada microsserviço e iniciar um processo Erlang para cada solicitação de microsserviço recebida.

Leitura adicional
Módulos Erlang
Processos Erlang

    
por 03.06.2016 / 16:41
fonte