Introdução
A escolha de um estilo arquitetônico é uma das soluções técnicas fundamentais na construção de um sistema de informação. Nesta série de artigos, proponho desmontar os estilos arquitetônicos mais populares para aplicações de construção e responder à pergunta de quando é o estilo arquitetônico preferido. No processo, tentarei desenhar uma cadeia lógica que explica o desenvolvimento de estilos arquitetônicos de monólitos a microsserviços.
Um pouco de historia
Se você tentar fazer uma pergunta aos desenvolvedores: “Por que precisamos de microsserviços?”, Você obterá uma variedade de respostas. Você ouvirá que os microsserviços melhoram o escalonamento, tornam seu código mais fácil de entender, melhoram a tolerância a falhas, às vezes você ouvirá que eles permitem "limpar o código". Vamos voltar à história para entender qual foi o propósito do surgimento dos microsserviços.
Em suma, os microsserviços em nosso entendimento atual surgiram da seguinte forma: em 2011, James Lewis, analisando o trabalho de várias empresas, chamou a atenção para o surgimento de um novo padrão "micro-aplicativo" que otimizava SOA em termos de aceleração da implantação de serviços. Um pouco mais tarde, em 2012, no encontro de arquitetura, o padrão foi renomeado para microsserviço. Assim, o objetivo inicial de introduzir microsserviços era melhorar o notório tempo de colocação no mercado .
Os microsserviços estiveram na "onda do hype" em 2015. De acordo com alguns estudos, nenhuma conferência foi concluída sem uma palestra sobre o tema microsserviços. Além disso, algumas conferências foram dedicadas exclusivamente a microsserviços. Hoje em dia, muitos projetos começam a usar esse estilo de arquitetura e, se o projeto contiver toneladas de código legado, provavelmente a migração para microsserviços é realizada ativamente.
Apesar de tudo isso, ainda existem alguns desenvolvedores que podem definir o termo "microsserviço". Mas falaremos sobre isso um pouco mais tarde ...
Monolith
O estilo arquitetônico versus microsserviço é monólito (ou tudo-em-um). Provavelmente não faz sentido dizer o que é um monólito, então vou listar imediatamente as deficiências desse estilo arquitetônico que iniciou o desenvolvimento posterior de estilos arquitetônicos: tamanho, coerência, implantação, escalabilidade, confiabilidade e inércia. A seguir, proponho conhecer cada uma das desvantagens separadamente.
O tamanho
O monólito é muito grande. E ele geralmente se comunica com um banco de dados muito grande. O aplicativo se torna muito grande para um desenvolvedor entender. Somente aqueles que passaram muito tempo por trás desse código podem trabalhar bem com um monólito, enquanto os iniciantes gastarão muito tempo tentando descobrir o monólito e não o fato de que irão descobri-lo. Normalmente, ao trabalhar com um monólito, há sempre um certo idoso “condicional” que conhece o monólito mais ou menos bem e dá tapas em outros novos desenvolvedores por um ano ou meio. Naturalmente, tal sênior condicional é um ponto único de falha, e sua partida pode levar à morte do monólito.
Conectividade
Um monólito é uma "grande bola de lama", mudanças nas quais podem levar a consequências imprevisíveis. Ao fazer alterações em um lugar, você pode danificar o monólito em outro (o mesmo "arranhou minha orelha, * @ caiu"). Isso se deve ao fato de que os componentes no monólito têm relacionamentos muito complexos e, o mais importante, não óbvios.
Desdobramento, desenvolvimento
A implantação de um monólito, devido às complexas relações entre seus componentes, é um longo processo com seu próprio ritual. Esse ritual geralmente não é completamente padronizado e é passado oralmente.
Escalabilidade
Os módulos Monolith podem ter requisitos de recursos conflitantes, o que exige um compromisso em termos de hardware. Imagine que o seu monólito consiste nos serviços A e B. O serviço A exige muito do tamanho do disco rígido, enquanto o serviço B exige RAM. Nesse caso, a máquina na qual o monolith está instalado deve oferecer suporte aos requisitos de ambos os serviços ou você terá que desconectar manualmente um dos serviços.
Outro exemplo (mais clássico): o serviço A é muito mais popular do que o serviço B, então você deseja que os serviços A sejam 100 e os serviços B 10. Novamente, duas opções: implantar 100 monólitos completos ou em alguns então os serviços B terão que ser desativados manualmente.
Confiabilidade
Como todos os serviços estão juntos, se o monólito cair, todos os serviços cairão ao mesmo tempo. Na verdade, talvez isso não seja tão ruim, pelo menos não haverá falhas parciais em um sistema distribuído, mas por outro lado, devido a um erro na funcionalidade que 0,001% dos usuários utilizam, você pode perder todos os usuários do seu sistema.
Inércia
Devido ao tamanho do monólito, é difícil mudar para novas tecnologias. Como resultado, a retenção desse idoso condicional é uma tarefa separada. A pilha tecnológica escolhida no início do projeto pode se tornar um bloqueio que atrapalha o desenvolvimento do produto.
Conclusão
Na próxima vez, falaremos sobre como as pessoas tentaram resolver esses problemas passando para os componentes e SOA.
Consulte Mais informação: