Olá, habr. As inscrições para um novo fluxo de curso estão abertas agora na OTUS . Na véspera do início do curso, quero compartilhar com vocês meu artigo original.
Introdução
A escolha do estilo arquitetônico é uma das decisões técnicas fundamentais na construção de um sistema de informação. Nesta série de artigos, proponho analisar os estilos arquitetônicos mais populares para aplicações de construção e responder à questão de qual estilo arquitetônico é mais preferível. No processo de apresentação, tentarei traçar uma cadeia lógica que explique o desenvolvimento de estilos arquitetônicos de monólitos a microsserviços.
Um pouco de história
Se você tentar perguntar aos desenvolvedores: “Por que precisamos de microsserviços?”, você obterá uma variedade de respostas. Você ouvirá que os microsserviços melhoram a escalabilidade, tornam o código mais fácil de entender, melhoram a tolerância a falhas e, às vezes, você ouvirá que eles permitem "limpar seu código". Vejamos a história para entender o propósito por trás do surgimento dos microsserviços.
Em suma, os microsserviços no nosso entendimento atual surgiram da seguinte forma: em 2011, James Lewis, analisando o trabalho de diversas empresas, chamou a atenção para o surgimento de um novo padrão de “micro-app”, que otimizou SOA em termos de acelerar a implantação de Serviços. Um pouco mais tarde, em 2012, em um encontro de arquitetura, o padrão foi renomeado como microsserviço. Assim, o objetivo inicial da introdução de microsserviços era melhorar o notório tempo de mercado.
Os microsserviços estavam na onda do hype em 2015. Segundo alguns estudos, nenhuma conferência ficou completa sem um relatório 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 arquitetônico e, se o projeto contiver muito código legado, provavelmente a migração para microsserviços está sendo realizada ativamente.
Apesar de tudo isso, um número relativamente pequeno de desenvolvedores ainda pode definir o conceito de “microsserviço”. Mas falaremos sobre isso um pouco mais tarde...
Monólito
O estilo arquitetônico que contrasta os microsserviços é o monólito (ou tudo-em-um). Provavelmente não faz sentido dizer o que é um monólito, então listarei imediatamente as desvantagens desse estilo arquitetônico, que iniciou o desenvolvimento de estilos arquitetônicos: tamanho, conectividade, implantação, escalabilidade, confiabilidade e rigidez. Abaixo, proponho dar uma olhada em cada uma das deficiências separadamente.
Tamanho
O monólito é muito grande. E 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 trabalhando neste código podem trabalhar bem com o monólito, enquanto os iniciantes gastarão muito tempo tentando descobrir o monólito e não há garantia de que o descobrirão. Normalmente, ao trabalhar com um monólito, sempre há algum sênior “condicional” que conhece o monólito mais ou menos bem e vence a mão de outros novos desenvolvedores dentro de um ano e meio. Naturalmente, tal sênior condicional é um ponto único de falha, e sua partida pode levar à morte do monólito.
Conectividade
O monólito é uma “grande bola de lama”, cujas mudanças podem levar a consequências imprevisíveis. Ao fazer alterações em um lugar, você pode danificar o monólito em outro (o mesmo “você coçou a orelha, *@ caiu”). Isso se deve ao fato de que os componentes do monólito possuem relacionamentos muito complexos e, o mais importante, não óbvios.
Desdobramento, desenvolvimento
Implantar um monólito, devido às complexas relações entre seus componentes, é um processo longo e com ritual próprio. Tal ritual geralmente não é completamente padronizado e é transmitido “oralmente”.
Escalabilidade
Os módulos Monolith podem ter necessidades de recursos conflitantes, exigindo um compromisso em termos de hardware. Imagine que você tem um monólito composto pelos serviços A e B. O serviço A exige muito do tamanho do disco rígido e o serviço B exige RAM. Nesse caso, ou a máquina na qual o monólito está instalado deve suportar os requisitos de ambos os serviços, ou você terá que desabilitar manualmente e artificialmente um dos serviços.
Outro exemplo (mais clássico): o serviço A é muito mais popular que o serviço B, então você deseja que haja 100 serviços A e 10 serviços B. Novamente, duas opções: ou implantamos 100 monólitos completos ou em alguns então os serviços B terão que ser desabilitados manualmente.
Confiança
Como todos os serviços estão localizados juntos, se o monólito cair, todos os serviços cairão ao mesmo tempo. Na verdade, isso pode não ser tão ruim, pelo menos não haverá falhas parciais em um sistema distribuído, mas por outro lado, devido a um bug na funcionalidade que é utilizada por 0.001% dos usuários, 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, reter o mesmo idoso é uma tarefa separada. A pilha de tecnologia escolhida no início de um 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 migrando para componentes e SOA.
Consulte Mais informação:
Fonte: habr.com