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 analisar 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.
Da última vez , lidamos com o monólito e chegamos à conclusão de que ele tem vários problemas: tamanho, conectividade, implantação, escalabilidade, confiabilidade e conservadorismo.
Desta vez, proponho falar sobre as possibilidades de organização do sistema na forma de um conjunto de módulos / bibliotecas (arquitetura orientada a componentes) ou serviços (arquitetura orientada a serviços).
Arquitetura orientada a componentes
A arquitetura baseada em componentes implica a implementação do sistema como um conjunto de componentes que podem ser usados em projetos atuais e futuros. Ao dividir um sistema em componentes, os seguintes fatores são levados em consideração: sua adequação para reutilização, sua substituibilidade, independência do contexto, extensibilidade, encapsulamento e independência.
Com o uso adequado dos componentes, o problema de uma “grande bola de sujeira” (tamanho grande + alta conectividade) é resolvido, e os próprios componentes podem ser unidades de montagem (módulos, bibliotecas) e unidades de implantação (serviços). As unidades de implantação nem sempre são mapeadas para um processo em execução: por exemplo, um aplicativo da web e um banco de dados são implantados juntos.
Na maioria das vezes, os monólitos são projetados como um conjunto de módulos. Essa abordagem leva a garantir a independência do desenvolvimento, mas ao mesmo tempo os problemas de escalonamento e implantação independentes, tolerância a falhas e independência da pilha tecnológica geral permanecem. É por isso que o módulo é um componente parcialmente independente.
O maior problema com esse monólito é que a divisão em módulos é puramente lógica e pode ser facilmente quebrada pelos desenvolvedores. Um módulo central pode aparecer, que gradualmente se transforma em uma pilha de lixo, um gráfico de dependências entre os módulos pode crescer e assim por diante. Para evitar esses problemas, o desenvolvimento deve ser realizado por uma equipe muito madura ou sob a orientação de um "arquiteto" que está envolvido na revisão do código em tempo integral e bate nas mãos dos desenvolvedores que violam a estrutura lógica.
Um monólito "ideal" é um conjunto de módulos separados logicamente, cada um dos quais examina seu próprio banco de dados.
Arquitetura Orientada a Serviços
Se, no entanto, ele deve organizar o sistema na forma de um conjunto de serviços, então estamos falando de uma arquitetura orientada a serviços. Seus princípios são: interoperabilidade de aplicações orientadas ao usuário, reutilização de serviços de negócios, independência de um conjunto de tecnologias e autonomia (evolução independente, escalabilidade e implementabilidade).
A arquitetura orientada a serviços (SOA) resolve todos os problemas descritos do monolith: uma mudança afeta apenas um serviço e uma API bem definida oferece suporte a um bom encapsulamento de componentes.
Mas nem tudo é tão tranquilo: SOA apresenta novos problemas. As chamadas remotas são mais caras do que as chamadas locais e a redistribuição de responsabilidades entre os componentes tornou-se significativamente mais cara.
A propósito, a capacidade de implantar de forma independente é um recurso muito importante do serviço. Se os serviços devem ser implantados juntos, ou ainda mais em uma determinada sequência, o sistema não pode ser considerado orientado a serviços. Nesse caso, eles falam de um monólito distribuído (é considerado um antipadrão não só do ponto de vista de SOA, mas também de uma arquitetura de microsserviço).
A arquitetura orientada a serviços é bem suportada pela comunidade de arquitetura e fornecedores. Por isso, são muitos cursos e certificações, padrões bem desenvolvidos. Os últimos incluem, por exemplo, o barramento de serviço corporativo não desconhecido (ESB = barramento de serviço corporativo). Ao mesmo tempo, o ESB é a bagagem dos fornecedores, não precisa ser usado em SOA.
A popularidade da arquitetura orientada a serviços atingiu o pico por volta de 2008, depois disso começou a declinar, o que se tornou muito mais nítido após o surgimento dos microsserviços (~ 2015).
Conclusão
Depois de discutirmos as possibilidades de organizar sistemas de informação na forma de serviços e módulos, proponho finalmente passar para os princípios da arquitetura de microsserviço e prestar atenção especial à diferença entre a arquitetura de microsserviço e a arquitetura orientada a serviços na próxima parte.
