Onde o Elixir / erlang se encaixa na abordagem de microsserviços? [fechadas]


109

Ultimamente, tenho feito alguns experimentos com o docker compose para implantar vários microsserviços de colaboração. Posso ver os muitos benefícios que os microsserviços oferecem e, agora que existe um bom conjunto de ferramentas para gerenciá-los, acho que não é extremamente difícil entrar no vagão dos microsserviços.

Mas também tenho experimentado o Elixir e gosto muito dos benefícios que ele proporciona. Dado que incentiva a compactação de seu código em vários aplicativos desacoplados e oferece suporte a atualizações de código quente, como você misturaria docker com elixir (ou erlang, por falar nisso)?

Por exemplo, se eu quiser usar docker porque ele fornece paridade dev-prod, como o elixir se encaixa nisso? Visto que os contêineres docker são imutáveis, perco a capacidade de fazer atualizações de hot-code, certo? E quanto às implantações azul / verde ou versões canário?

Quer dizer, eu poderia simplesmente escrever microsserviços com Elixir e usá-los como se fossem escritos em qualquer outra linguagem. O poliglotismo é um dos benefícios dos microsserviços de qualquer maneira, mas não estou obtendo todos os benefícios de usar a plataforma OTP, acho que os aplicativos erlang colaborativos puros são muito mais ideais do que o uso de filas intermediárias para a comunicação entre microsserviços escritos em linguagens diferentes (ou não).


7
Vejo que o downvote é porque a pergunta "não mostra nenhum esforço de pesquisa". É triste porque não é verdade, claro que o problema pode estar na própria pergunta, mas não posso ser acusado de não pesquisar porque ultimamente é a única coisa que tenho feito. Muito.
Papipo

1
Esta questão é muito ampla - questões sobre stackoverflow devem incluir problemas específicos.
Paweł Obrok

4
devo movê-lo para outro site stackexchange? Porque o quesiton é legítimo IMO.
Papipo

2
Eu acho que é uma pergunta interessante, mas pode pertencer ao stackexchange de programadores? Dito isso, não votamos para fechar
George Mauer

1
É incrível e totalmente feito para o trabalho.
bryan hunt

Respostas:


138

Esta é uma questão muito aberta, mas tentarei ilustrar por que Elixir / Erlang pode ser a melhor plataforma para desenvolver sistemas distribuídos (independentemente se você está trabalhando com microsserviços).

Primeiro, vamos começar com alguns antecedentes. A VM Erlang e sua biblioteca padrão foram projetadas antecipadamente para a construção de sistemas distribuídos e isso realmente aparece. Pelo que eu sei, é o único tempo de execução e VM amplamente usados ​​na produção, projetados inicialmente para este caso de uso.

Formulários

Por exemplo, você já sugeriu "aplicativos". Em Erlang / Elixir, o código é empacotado dentro de aplicativos que:

  1. são iniciados e parados como unidade. Iniciar e parar o seu sistema é uma questão de iniciar todos os aplicativos nele
  2. fornece uma estrutura de diretório unificada e API de configuração (que não é XML!). Se você já trabalhou e configurou um aplicativo OTP, sabe como trabalhar com qualquer outro
  3. contém a árvore de supervisão do aplicativo, com todos os processos (por processo, quero dizer "processos VM" que são threads leves de computação) e seu estado

O impacto desse design é enorme. Isso significa que os desenvolvedores Elixir, ao escrever aplicativos, têm uma abordagem mais explícita para:

  1. como seu código é iniciado e interrompido
  2. quais são os processos que fazem parte de um aplicativo e, portanto, qual é o estado do aplicativo
  3. como esses processos irão reagir e ser afetados em caso de falhas ou quando algo der errado

Além disso, o conjunto de ferramentas em torno dessa abstração é ótimo. Se você tem Elixir instalado, abra-se "IEX" e digite: :observer.start(). Além de mostrar informações e gráficos sobre o seu sistema ativo, você pode matar processos aleatórios, ver o uso de memória, estado e muito mais. Aqui está um exemplo de execução em um aplicativo Phoenix:

Observer executando com um aplicativo Phoenix

A diferença aqui é que Aplicativos e Processos fornecem uma abstração para raciocinar sobre seu código em produção . Muitas linguagens fornecem pacotes, objetos e módulos principalmente para organização de código, sem reflexo no sistema de tempo de execução. Se você tem um atributo de classe ou um objeto singleton: como você pode raciocinar sobre as entidades que podem manipulá-lo? Se você tiver um vazamento de memória ou um gargalo, como poderá encontrar a entidade responsável por isso?

Se você perguntar a qualquer pessoa que esteja executando um sistema distribuído, esse é o tipo de percepção que ela deseja, e com Erlang / Elixir você tem isso como o bloco de construção.

Comunicação

Tudo isso é apenas o começo. Ao construir um sistema distribuído, você precisa escolher um protocolo de comunicação e o serializador de dados. Muitas pessoas escolhem HTTP e JSON que, quando você pensa sobre isso, é uma combinação muito detalhada e cara para realizar o que realmente são chamadas RPC.

Com Erlang / Elixir, você já tem um protocolo de comunicação e um mecanismo de serialização prontos para uso. Se você quiser que duas máquinas se comuniquem entre si, você só precisa dar nomes a elas, garantir que tenham o mesmo segredo e pronto.

Jamie falou sobre isso na Erlang Factory 2015 e como eles puderam aproveitar isso para construir uma plataforma de jogo: https://www.youtube.com/watch?v=_i6n-eWiVn4

Se você deseja usar HTTP e JSON, tudo bem e bibliotecas como Plug e frameworks como Phoenix garantirão que você seja produtivo aqui também.

Microsserviços

Até agora não falei sobre microsserviços. Isso porque, até este ponto, eles realmente não importam. Você já está projetando seu sistema e nós em torno de processos muito pequenos que estão isolados. Chame-os de nanoserviços se quiser!

Além disso, eles também são empacotados em aplicativos, que os agrupam como entidades que podem ser iniciadas e interrompidas como unidade. Se você tem aplicativos A, B e C, e deseja implantá-los como [A, B] + [C] ou [A] + [B] + [C], você terá muito poucos problemas para fazer isso devido ao seu design inerente. Ou, melhor ainda, se você quiser evitar adicionar a complexidade das implantações de microsserviços em seu sistema antecipadamente, pode simplesmente implantá-los juntos no mesmo nó.

E, no final do dia, se você está executando tudo isso usando o protocolo distribuído Erlang, você pode executá-los em nós diferentes e eles serão capazes de alcançar outros contanto que você se refira a eles por em {:node@network, :name}vez de :name.

Eu poderia ir mais longe, mas espero ter convencido você neste ponto. :)


Na verdade, eu gosto muito de Elixir e OTP, a questão era mais sobre como obter alguns benefícios de microsserviços (como paridade dev-prod, lançamentos canário, etc) ao usar o Elixir.
Papipo

Eu tinha um parágrafo sobre Docker, mas ele se perdeu. :) O ponto principal é que você o usa para implantação de nó, de modo que você escolhe quais aplicativos fazem sentido por nó. As implantações azul / verde são definitivamente alcançáveis, mas dependem do protocolo, tipo de estado e outros fatores.
José Valim

5
A palestra que mencionei cobre uma camada de roteamento que pode ser usada para azul / verde ou canário. Novamente, depende do protocolo de escolha, mas você pode ir de uma entrada global em Erlang distribuído, algo usando consul, ou haproxy para algo baseado em HTTP.
José Valim

A abordagem de descoberta de serviço faz sentido. Acho que sempre pensei em termos de balanceamento de carga.
Papipo

1
Que tal um dos outros benefícios dos microsserviços, como escolher o melhor idioma para uma tarefa específica. Eu adoro elixir, porém não é a melhor linguagem para todas as tarefas. O que quero dizer é que pode ser necessário que um microsserviço específico use uma linguagem diferente em vez do elixir. Ele ainda deve seguir uma arquitetura tradicional de micro serviços?
Jeancarlo
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.