O mundo não para. O progresso cria novos desafios tecnológicos. De acordo com as demandas que mudaram, a arquitetura dos sistemas de informação deve evoluir. Hoje, vamos falar sobre arquitetura orientada a eventos, concorrência, paralelismo, assíncrono e como viver em harmonia com tudo isso em Erlang.
Introdução
Dependendo do tamanho do sistema projetado e de suas exigências, nós, desenvolvedores, escolhemos a maneira de trocar informações no sistema. Na maioria dos casos, para organizar a interação entre serviços, uma solução prática pode ser um esquema com um broker, como RabbitMQ ou Kafka. Mas às vezes, o fluxo de eventos, o SLA e o nível de controle sobre o sistema são tais que a solução de messaging pronta não se adequa. É claro que podemos complicar um pouco o sistema, assumindo a responsabilidade pelo nível de transporte e pela formação do cluster, por exemplo, utilizando ZeroMQ ou nanomsg. Mas se o sistema é suficiente em termos de capacidade e funcionalidades do cluster padrão Erlang, a questão de adicionar uma entidade extra requer um exame detalhado e uma justificativa econômica.
O tema de aplicações reativas distribuídas é bastante amplo. Para nos mantermos dentro do formato do artigo, o assunto da discussão de hoje será apenas ambientes homogêneos, baseados em Erlang/Elixir. O ecossistema Erlang/OTP permite implementar uma arquitetura reativa com o menor esforço. Mas, de qualquer forma, precisamos de uma camada de troca de mensagens.
Base teórica
O projeto começa com a definição de objetivos e restrições. O objetivo principal não está na área de desenvolvimento por desenvolver. Precisamos de uma ferramenta segura e escalável, com a qual possamos criar, e mais importante, desenvolver aplicações modernas de diferentes níveis: começando com aplicações de um único servidor, que atendem a uma pequena audiência, e que posteriormente podem evoluir para clusters de 50-60 nós, até federações de clusters. Assim, o objetivo principal é maximizar o lucro reduzindo o custo de desenvolvimento e a posse do sistema final.
Vamos destacar 4 principais requisitos para o sistema final:
- Comorientação a eventos.
O sistema está sempre pronto para processar o fluxo de eventos e realizar as ações necessárias; - Mescalabilidade.
Os blocos individuais podem ser escalados tanto vertical quanto horizontalmente. Todo o sistema deve ser capaz de crescimento horizontal infinito; - Anuitabilidade.
Todos os níveis e serviços devem ter a capacidade de recuperação automática em caso de falhas; - Garantia de tempo de resposta.
O tempo é valioso e os usuários não devem esperar muito tempo.
Lembre-se do velho conto "The little engine that could", também conhecido como "O trenzinho que conseguiu"? Para que o sistema projetado tenha sucesso ao sair da fase de protótipo e seja progressivo, sua fundação deve atender aos requisitos mínimos. CONSEGUIU.
A mensageria, como uma ferramenta de infraestrutura e base para todos os serviços, adiciona mais um ponto: a facilidade de uso para os programadores.
Orientação a eventos
Para que um aplicativo possa crescer de uma servidor para um cluster, sua arquitetura deve garantir um baixo acoplamento. Essa necessidade é atendida pelo modelo assíncrono. Nele, o remetente e o destinatário cuidam da carga informativa da mensagem e não se preocupam com a transmissão e roteamento dentro do sistema.
Escalabilidade
A escalabilidade e a eficiência do sistema caminham lado a lado. Os componentes do aplicativo devem ser capazes de utilizar todos os recursos disponíveis. Quanto mais eficientemente pudermos utilizar os recursos e quanto mais otimizados forem nossos métodos de processamento, menos dinheiro gastaremos em hardware.
Dentro de uma única máquina, Erlang cria um ambiente altamente concorrente. O equilíbrio entre concorrência e paralelismo pode ser definido pela escolha do número de threads do sistema operacional disponíveis para a Erlang VM e o número de escalonadores que utilizam essas threads.
Os processos Erlang não têm estado compartilhado e operam em modo não bloqueante. Isso garante uma latência relativamente baixa e uma maior largura de banda do que aplicações tradicionais construídas em sincronização bloqueante. O escalonador Erlang cuida da distribuição justa de CPU e IO, e a ausência de bloqueios permite que o aplicativo responda mesmo em picos de carga ou falhas.
No nível do cluster, também existe um problema com a utilização. É importante que todas as máquinas no cluster estejam igualmente carregadas, e a rede não sobrecarregada. Vamos imaginar a situação: o tráfego do usuário aterrissa nos balanceadores de carga de entrada (haproxy, nginx, etc.), que distribuem o máximo possível as solicitações para processamento entre um conjunto de backends disponíveis. Dentro da infraestrutura do aplicativo, o serviço que implementa a interface necessária é apenas a última milha e precisará solicitar uma série de outros serviços para responder à solicitação original. As solicitações internas também requerem roteamento e balanceamento.
Para gerenciar efetivamente os fluxos de dados, o messaging deve fornecer aos desenvolvedores uma interface para gerenciar roteamento e distribuição de carga. Com isso, os desenvolvedores poderão, utilizando padrões de microserviços (aggregator, proxy, chain, branch, etc.), resolver tanto problemas padrão quanto raramente recorrentes.
Do ponto de vista do negócio, escalabilidade é uma das ferramentas de gerenciamento de riscos. O principal é atender às solicitações dos clientes, utilizando o hardware da melhor forma:
- Ao aumentar a capacidade do hardware devido ao progresso. Ele não ficará ocioso devido à imperfeição do software. Erlang se escala perfeitamente de forma vertical e sempre será capaz de utilizar todos os núcleos da CPU e a memória disponível;
- Em ambientes de nuvem, podemos gerenciar a quantidade de hardware dependendo da carga atual ou prevista e garantir o SLA.
Resiliência
Vamos considerar duas axiomas: “Falhas são inaceitáveis” e “Falhas sempre ocorrerão”. Para os negócios, a falha do software significa perda de dinheiro, e o que é pior – de reputação. Ao equilibrar entre possíveis perdas e o custo de desenvolvimento de software à prova de falhas, muitas vezes pode-se encontrar um compromisso.
A curto prazo, uma arquitetura que incorpora resiliência economiza dinheiro na compra de soluções prontas de clusterização. Elas são caras e também têm erros.
A longo prazo, uma arquitetura resiliente paga seus custos diversas vezes em todas as fases de desenvolvimento.
A comunicação dentro da base de código ainda está em fase de desenvolvimento, permitindo uma abordagem detalhada da interação entre os componentes do sistema. Isso simplifica a tarefa de resposta e gerenciamento de falhas, uma vez que todos os componentes responsáveis lidam com falhas, e o sistema final sabe como retornar automaticamente ao seu estado normal após uma falha por design.
Reatividade
Independentemente das falhas, o aplicativo deve responder a solicitações e atender ao SLA. A realidade é que as pessoas não querem esperar, portanto, os negócios devem se adaptar. Cada vez mais aplicativos são esperados para ter alta reatividade.
Aplicativos reativos operam em um modo próximo do tempo real. A Erlang VM funciona em um modo de tempo real suave. Para algumas áreas, como negociação em bolsas, medicina e controle de equipamentos industriais, o modo de tempo real rígido é importante.
Sistemas reativos melhoram a experiência do usuário e são benéficos para os negócios.
Resumo preliminar
Ao planejar este artigo, eu queria compartilhar minha experiência na criação de um broker de mensagens e na construção de sistemas complexos com base nele. Mas a parte teórica e motivacional acabou sendo bastante extensa.
Na segunda parte do artigo, falarei sobre as nuances da implementação de pontos de troca, padrões de mensagens e suas aplicações.
Na terceira parte, abordaremos questões gerais sobre a organização de serviços, roteamento e balanceamento. Discutiremos o aspecto prático da escalabilidade e da resiliência dos sistemas.
Fim da primeira parte.
Foto .
Fonte: habr.com
