Olá, Habr. Neste momento, a OTUS está com inscrições abertas para uma nova turma do curso . Antecipando o início do curso, quero compartilhar com vocês meu artigo autoral.
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 a construção de aplicações e responder à pergunta de quando determinado estilo arquitetônico é mais preferível. Durante a exposição, tentarei traçar uma linha lógica que explica a evolução dos estilos arquitetônicos, desde monólitos até microsserviços.
Um pouco de história
Se você tentar perguntar aos desenvolvedores: "Por que os microsserviços são necessários?", receberá respostas variadas. Você ouvirá que os microsserviços melhoram a escalabilidade, facilitam a compreensão do código e aprimoram a resiliência, e às vezes pode até ouvir que eles permitem "limpar o código". Vamos olhar para a história para entender qual era o objetivo do surgimento dos microsserviços.
Em resumo, os microsserviços em nossa compreensão atual surgiram da seguinte forma: em 2011, James Lewis, ao analisar o trabalho de várias empresas, notou o surgimento de um novo padrão "micro-app" que otimizava o SOA em termos de acelerar o desenvolvimento de serviços. Algum tempo depois, em 2012, o padrão foi renomeado para microsserviço em uma cúpula arquitetônica. Assim, o objetivo inicial da implementação de microsserviços era melhorar o famoso time to market.
Na "onda do hype", os microsserviços estavam em alta em 2015. Segundo algumas pesquisas, nenhuma conferência deixava de ter uma apresentação sobre o tema microsserviços. Além disso, algumas conferências eram dedicadas exclusivamente a microsserviços. Atualmente, muitos projetos são iniciados com esse estilo arquitetônico, e se um projeto contém toneladas de código legado, certamente está ocorrendo uma migração ativa para microsserviços.
Apesar de tudo isso, ainda é uma quantidade relativamente pequena de desenvolvedores que pode definir o conceito de "microsserviço". Mas falaremos sobre isso mais adiante...
Monolito
O estilo arquitetônico que se opõe ao microsserviço é o monolito (ou "tudo em um"). Não faz muito sentido falar sobre o que é um monolito, então vou listar imediatamente as desvantagens desse estilo arquitetônico que iniciaram o desenvolvimento de novos estilos arquitetônicos: tamanho, acoplamento, implantação, escalabilidade, confiabilidade e rigidez. Abaixo, proponho que nos familiarizemos com cada uma das desvantagens separadamente.
Tamanho
O monólito é muito grande. E, geralmente, ele se comunica com um banco de dados igualmente grande. O aplicativo se torna complexo demais para ser compreendido por um único desenvolvedor. Apenas aqueles que passaram muito tempo neste código conseguem trabalhar bem com monólitos, enquanto novatos gastam muito tempo tentando entender o monólito, sem garantias de que conseguirão. Normalmente, ao trabalhar com um monólito, sempre há um 'sênior' que conhece o monólito razoavelmente bem e orienta outros desenvolvedores novatos ao longo de um ano ou um ano e meio. É claro que esse sênior se torna um ponto único de falha, e sua saída pode levar à ruína do monólito.
Coesão
Um monólito é como um 'grande novelo de barbante' (big ball of mud), cujas alterações podem levar a consequências imprevisíveis. Ao fazer mudanças em um local, pode-se danificar o monólito em outro (é o famoso 'coçou a orelha, e a @&*# se soltou'). Isso acontece porque os componentes dentro do monólito têm relações muito complexas e, principalmente, não óbvias.
Implantação
A implantação de um monólito, devido às complexas inter-relações entre seus componentes, é um processo longo, com seus próprios rituais. Esses rituais geralmente não estão completamente padronizados e são transmitidos 'de boca em boca'.
Escalabilidade
Os módulos de um monólito podem ter necessidades de recursos conflitantes, o que exige uma busca por compromisso do ponto de vista de hardware. Imagine que seu monólito seja composto pelos serviços A e B. O serviço A exige muito espaço em disco, enquanto o serviço B demanda muita memória RAM. Nesse caso, ou a máquina onde o monólito é instalado deve atender os requisitos de ambos os serviços, ou um dos serviços precisará ser manualmente desligado.
Outro exemplo (mais clássico): o serviço A é muito mais popular que o serviço B, portanto, você deseja que haja 100 instâncias do serviço A e 10 do serviço B. Novamente, temos duas opções: ou implantamos 100 monólitos completos, ou teremos que desligar manualmente os serviços B em algumas das instâncias.
Confiabilidade
Como todos os serviços estão juntos, se o monolito falha, todos os serviços falham 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 erro em uma funcionalidade usada por 0,001% dos usuários, você pode perder todos os usuários de seu sistema.
Rigidez
Devido ao tamanho do monolito, é difícil migrar para novas tecnologias. Como resultado, uma tarefa separada é manter aquele senior hipotético. A pilha de tecnologia escolhida no início do projeto pode se tornar um obstáculo ao desenvolvimento do produto.
Conclusão
Na próxima vez, vamos discutir como as pessoas tentaram resolver os problemas mencionados passando para componentes e SOA.
Leia mais:
Fonte: habr.com
