Quando um grande produto é concebido ou um pequeno software começa a se transformar em um leviatã, qual caminho de desenvolvimento devo escolher? Devo reescrever tudo do zero ou continuar as tradições "historicamente estabelecidas"? Enfim, vale a pena revisar o próprio conceito de arquitetura?
Olá, Khabrovites! Meu nome é Konstantin e sou o principal desenvolvedor de um sistema razoavelmente grande que começou uma vez como um experimento. Um pequeno site PHP criado literalmente "no joelho" e, é claro, um monólito. Com o passar do tempo, o site cresceu e se deparou com vários problemas, cuja solução colocou a questão "e depois como?".
Monólito ou microsserviços? O que escolher? A diferença básica entre as abordagens, na minha opinião, é que um monólito implica um ciclo centralizado para processar a solicitação de um usuário e microsserviços - um descentralizado. As vantagens e desvantagens comuns de ambas as abordagens são amplamente conhecidas e listadas mais de uma vez (por exemplo,
aqui ,
aqui ou
aqui ). No entanto, não existem fatores tão óbvios e óbvios que influenciam a escolha da arquitetura.
- Carregando funcionários em período integral . Com o rápido desenvolvimento do produto, um conjunto de tarefas se acumula, que não pode ser resolvido em um período de tempo aceitável - todos estão ocupados. E se esse "bloqueio" for único, não faz sentido expandir a equipe de desenvolvedores. A solução óbvia são contratados externos (empresas ou freelancers). Mas como dar a eles um pedaço do produto para trabalhar sem correr o risco de transformá-lo em um código aberto, grosso modo? No caso de usar microsserviços, essa tarefa é muito mais fácil de resolver.
- A dificuldade de mergulhar . Quanto maior o produto, mais tempo leva para um novo funcionário se sentir confortável nele. Especialmente se houver muitos padrões diferentes no código (sim, uma boa documentação facilita muito o processo, mas se não acontecer?) E personalizações para casos especiais individuais. Deste ponto de vista, lidar com uma pequena parte independente é muito mais fácil do que com todo o produto imediatamente.
- Recursos em cargas de pico . Em minha prática, houve um caso em que a carga nos servidores às vezes chegava a valores inaceitáveis (e se especificamente - a RAM estava esgotada, uma troca era ativada e o servidor se tornava um vegetal por um tempo), durante o trabalho livre o tempo todo (o carregamento não era superior a 30% em termos de RAM ) E esses picos ocorreram irregularmente e com longas pausas. No caso de um monólito (acreditamos que não há lugar para otimizar o código), apenas a conexão de novos servidores com uma cópia de todo o sistema para o balanceamento de carga é salva. E, no caso de microsserviços, você pode organizar uma fila de processamento (é claro, isso se aplica apenas a operações com tempo crítico que são rápidas e não esperadas, como descarregar uma tabela do Excel).
- Executando tarefas em segundo plano . A maneira como esse fator "sacode o barco" depende de seu tamanho e complexidade. Como regra, um monólito e um cronômetro (cron) são suficientes. Mas se as tarefas começarem a se acumular em grandes grupos, também surgirão problemas. Já é necessário equilibrar as tarefas cron. Os microsserviços facilitam muito essa situação.
- A complexidade do rastreamento . No caso dos microsserviços, os requisitos para a manutenção do ferro são aumentados - onde, o que e como deve ser configurado. Monólito - grosso modo, algumas configurações para todos os nós, microsserviços - dependem dos requisitos de microsserviços específicos em execução no nó.
- Requisitos de qualificação . Quanto mais tecnologias o zoológico (e geralmente cresce se o sistema for microsserviço), maiores serão os requisitos para as habilidades e o conhecimento dos funcionários regulares. Afinal, se houver melhorias ou problemas, eles devem lidar. Ou são necessários mais profissionais para cobrir toda a pilha.
Existe alguma necessidade de escolha? O jogo vale a pena? Eu acho que definitivamente vale a pena. Mas é preciso abordar a questão com a cabeça fria. Caso contrário, alguns problemas serão simplesmente substituídos por outros.
No meu caso, ocorreu um ponto de virada quando o site deixou de se "encaixar" nos recursos de um servidor. Decidiu-se reescrever o sistema de acordo com a melhor opção na minha opinião - um híbrido. Existem
recomendações gerais para o desenvolvimento de produtos no "caso híbrido". Mas gostaria de complementá-lo com algumas recomendações.
Ao projetar um monólito inicial, as possibilidades de conexão adicional de serviços externos precisam ser estabelecidas imediatamente. Crie imediatamente comunicações entre componentes como se esses componentes já (ou quase já) fossem "serviços externos". Especialmente se eles consomem muitos recursos.
Pense imediatamente em uma política para trabalhar com caches e armazenamento de dados (bancos de dados e arquivos). Por exemplo, compartilhe a sessão de um usuário.
E o mais importante é não se apressar a extremos. Para mim, deduzi a seguinte fórmula para um bom projeto: "um sistema eficaz é um sistema equilibrado". Em particular, isso se expressa no fato de que em microsserviços retiro apenas grandes fragmentos logicamente isolados do kernel. E então, apenas se pelo menos uma das condições for atendida:
- é necessária limitação de carga e previsão, o atraso de tempo devido à execução da tarefa não é crítico por sua vez
- o isolamento proporcionará um aumento significativo na produtividade.
Como resultado dessa abordagem, obtivemos um sistema, 95% da funcionalidade localizada no kernel e 5% em microsserviços. Mas, ao mesmo tempo, o núcleo responde por apenas 60% da carga total. E, ao mesmo tempo, você pode garantir que a carga em servidores individuais não exceda os valores críticos.
Portanto, os microsserviços são (de um determinado tamanho do produto) bons se você os usar apenas se for absolutamente necessário, e não por causa da moda ou "porque é legal". Existem
produtos grandes que vivem com sucesso como um monólito. Mas às vezes um monólito não pode resolver o problema ...
Obrigada