O mundo não pára. O progresso cria novos desafios tecnológicos. De acordo com os requisitos variáveis, a arquitetura dos sistemas de informação também deve evoluir. Hoje falaremos sobre arquitetura orientada a eventos, competitividade, concorrência, assincronia e como você pode viver em paz com tudo isso em Erlang.
1. Introdução
Dependendo do tamanho do sistema que está sendo projetado e dos requisitos, nós, os desenvolvedores, escolhemos o método de troca de informações no sistema. Na maioria dos casos, para organizar a interação de serviços, uma opção de trabalho pode ser um esquema com um broker, por exemplo, baseado em RabbitMQ ou kafka. Mas, às vezes, o fluxo de eventos, o SLA e o nível de controle sobre o sistema são de tal ordem que as mensagens prontas não nos agradam. Obviamente, você pode complicar um pouco o sistema assumindo a responsabilidade pela camada de transporte e formação de cluster, por exemplo, usando ZeroMQ ou nanomsg. Mas se o sistema tiver largura de banda suficiente e os recursos de um cluster Erlang padrão, a questão da introdução de uma entidade adicional requer um estudo detalhado e justificativa econômica.
O tópico de aplicativos distribuídos reativos é bastante extenso. Para manter o formato do artigo, o assunto da discussão de hoje será apenas ambientes homogêneos criados com base no Erlang / Elixir. O ecossistema Erlang / OTP permite uma arquitetura reativa de baixo custo. Mas, em qualquer caso, precisamos de uma camada de mensagens.
Base teórica
O design começa com a definição de objetivos e limitações. O objetivo principal não está no desenvolvimento para o desenvolvimento. Precisamos obter uma ferramenta segura e escalável com base na qual possamos criar e, o mais importante, desenvolver aplicativos modernos de diferentes níveis: dos de servidor único, atendendo a um pequeno público, que posteriormente poderá se transformar em clusters de até 50 a 60 nós, terminando em federações de cluster. Assim, o principal objetivo é maximizar os lucros, reduzindo o custo de desenvolvimento e propriedade do sistema final.
Existem 4 requisitos principais para o sistema final:
- Com orientação cotidiana.
O sistema está sempre pronto para passar por si mesmo um fluxo de eventos e executar as ações necessárias; - Escalabilidade.
Blocos individuais podem ser dimensionados na vertical e na horizontal. Todo o sistema deve ser capaz de crescimento horizontal infinito; - Sobre tolerância a falhas.
Todos os níveis e todos os serviços devem poder se recuperar automaticamente de falhas; - Tempo de resposta garantido.
O tempo é valioso e os usuários não devem esperar muito tempo.
Lembre-se do velho conto de fadas sobre "O pequeno mecanismo que poderia", também conhecido como "O mecanismo que poderia"? Para que o sistema projetado saia com sucesso do estágio de protótipo e seja progressivo, sua base deve atender aos requisitos mínimos do SMOG .
Outra coisa é adicionada ao sistema de mensagens como uma ferramenta de infraestrutura e uma base para todos os serviços: usabilidade para programadores.
Orientação do evento
Para que um aplicativo cresça de um único servidor para um cluster, sua arquitetura deve fornecer conectividade fraca. O modelo assíncrono atende a esse requisito. Nele, o remetente e o destinatário cuidam da carga de informações da mensagem e não se preocupam com a transmissão e o roteamento dentro do sistema.
Escalabilidade
A escalabilidade e o desempenho do sistema estão lado a lado. Os componentes do aplicativo devem poder utilizar todos os recursos disponíveis. Quanto mais eficientes pudermos utilizar as capacidades e mais otimizados nossos métodos de processamento, menos gastaremos dinheiro em equipamentos.
Erlang cria um ambiente altamente competitivo em uma única máquina. O equilíbrio entre simultaneidade e simultaneidade pode ser definido selecionando o número de threads do sistema operacional disponíveis para o Erlang VM e o número de agendadores que utilizam esses threads.
Os processos Erlang não têm um estado comum e funcionam no modo sem bloqueio. Isso fornece uma latência relativamente baixa e maior largura de banda do que os aplicativos tradicionais criados com base na sincronização de bloqueio. O planejador Erlang cuida da distribuição justa de CPU e E / S, e a ausência de bloqueios permite que o aplicativo responda mesmo em cargas ou falhas de pico.
No nível do cluster, também existe um problema de reciclagem. É importante que todas as máquinas do cluster sejam carregadas uniformemente e a rede não esteja sobrecarregada. Imagine uma situação: o tráfego do usuário chega aos balanceadores de entrada (haproxy, nginx etc.), eles distribuem as solicitações de processamento da maneira mais uniforme possível entre o conjunto de back-end disponíveis. Na estrutura da infraestrutura do aplicativo, um serviço que implementa a interface necessária é apenas a última milha e precisará solicitar vários outros serviços para responder à solicitação inicial. As consultas internas também exigem roteamento e balanceamento.
Para gerenciar efetivamente os fluxos de dados, o sistema de mensagens deve fornecer aos desenvolvedores uma interface para controlar o roteamento e o balanceamento de carga. Graças a isso, os desenvolvedores poderão, usando padrões de microsserviços (agregador, proxy, cadeia, filial, etc.), resolver tarefas padrão e que raramente surgem.
Da perspectiva dos negócios, a escalabilidade é uma das ferramentas de gerenciamento de riscos. O principal é satisfazer as demandas dos clientes usando o equipamento de maneira otimizada:
- Com um aumento na capacidade do equipamento como resultado do progresso. Não ficará ocioso devido a imperfeições do software. O Erlang é dimensionado perfeitamente na vertical e sempre pode reciclar todos os núcleos da CPU e memória disponível;
- Em ambientes nublados, podemos controlar a quantidade de equipamentos, dependendo da carga atual ou prevista, e garantir o SLA.
Tolerância a falhas
Considere dois axiomas: "Falhas são inaceitáveis" e "Falhas sempre serão". Para as empresas, falha de software é perda de dinheiro e, pior, reputação. Equilibrando entre as perdas em potencial e o custo do desenvolvimento de software tolerante a falhas, muitas vezes você pode encontrar um compromisso.
No curto prazo, a arquitetura com tolerância a falhas economiza dinheiro na compra de soluções de cluster turnkey. Eles são caros e também têm erros.
A longo prazo, a arquitetura tolerante a falhas paga repetidamente pelos custos de sua aplicação em todas as etapas do desenvolvimento.
As mensagens dentro da base de código no estágio de design permitem que você trabalhe em detalhes a interação dos componentes dentro do sistema. Isso simplifica a tarefa de responder e gerenciar falhas, uma vez que todos os componentes críticos lidam com falhas e o sistema resultante sabe como retornar automaticamente ao normal após uma falha, por design.
Responsividade
Independentemente de falhas, o aplicativo deve responder a solicitações e satisfazer SLAs. A realidade é que as pessoas não querem esperar, então os negócios devem se ajustar. Espera-se que mais aplicativos sejam altamente responsivos.
Os aplicativos responsivos funcionam em modo quase em tempo real. O Erlang VM opera no modo de tempo real suave. Para algumas áreas, como comércio de câmbio, medicamentos, gerenciamento de equipamentos industriais, o modo rígido em tempo real é importante.
Os sistemas responsivos aprimoram o UX e ajudam as empresas.
Resultado preliminar
Ao planejar este artigo, queria compartilhar a experiência de criar um broker de mensagens e criar sistemas complexos com base em eles. 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, modelos de mensagens e sua aplicação.
Na terceira parte, consideramos as questões gerais de organização, roteamento e balanceamento de serviços. Vamos falar sobre o lado prático da escalabilidade e tolerância a falhas dos sistemas.
O fim da primeira parte.
Foto @lucabravo .