Olá, Habr. Hoje eu continuo a série de publicações que escrevi especialmente para o início do novo fluxo do curso .
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.
Em nós entendemos o monólito e chegamos à conclusão de que o monólito possui uma série de problemas: tamanho, acoplamento, implantação, escalabilidade, confiabilidade e rigidez.
Desta vez, proponho discutir as possibilidades de organizar o 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 orientada a componentes pressupõe a execução do sistema na forma de um conjunto de componentes que podem ser utilizados tanto em projetos atuais quanto futuros. Ao dividir o sistema em componentes, considera-se: a adequação para reutilização, a substituibilidade, a independência do contexto, a extensibilidade, a encapsulação e a independência.
Quando usados corretamente, os componentes resolvem o problema do "grande bloco de sujeira" (tamanho grande + alta coesão), e os próprios componentes podem representar tanto unidades de montagem (módulos, bibliotecas) quanto unidades de implantação (serviços). Unidades de implantação nem sempre refletem o processo em execução: por exemplo, uma aplicação web e um banco de dados são implantados em conjunto.
Os monólitos são frequentemente desenvolvidos na forma de um conjunto de módulos. Essa abordagem garante a independência no desenvolvimento, mas os problemas de escalabilidade e implantação independentes, resiliência e independência do stack tecnológico comum permanecem. É por isso que um módulo é um componente parcialmente independente.
O maior problema de tal monolito é que a divisão em módulos é puramente lógica e pode ser facilmente violada pelos desenvolvedores. Pode surgir um módulo core que, gradualmente, se transforma em um lixo; pode crescer um gráfico de dependências entre os módulos e assim por diante. Para evitar tais problemas, o desenvolvimento deve ser conduzido por uma equipe muito madura ou sob a supervisão de um "arquiteto" que se dedica em tempo integral à revisão de código e corrige os desenvolvedores que violam a estrutura lógica.
Um monolito "ideal" consiste em um conjunto de módulos logicamente separados, cada um dos quais se conecta à sua própria base de dados.
Arquitetura orientada a serviços
Se ainda se presume a organização do sistema como um conjunto de serviços, estamos falando de uma arquitetura orientada a serviços. Seus princípios são: interoperabilidade de aplicações focadas no usuário, reutilização de serviços de negócio, independência do conjunto de tecnologias e autonomia (evolução, escalabilidade e implantação independentes).
A arquitetura orientada a serviços (SOA = service oriented architecture) resolve todos os problemas identificados do monolito: durante uma modificação, apenas um serviço é afetado, enquanto uma API bem definida mantém uma boa encapsulação dos componentes.
Mas nem tudo é tão simples: SOA traz novos problemas. Chamadas remotas são mais caras que chamadas locais, e a redistribuição de responsabilidades entre os componentes se tornou significativamente mais cara.
Vale mencionar que a possibilidade de implantação independente é uma característica muito importante de um serviço. Se os serviços devem ser implantados em conjunto ou, ainda mais, em uma determinada sequência, o sistema não pode ser considerado orientado a serviços. Nesses casos, fala-se de um monolito distribuído (considerado um antipadrão tanto em relação ao SOA quanto à arquitetura de microsserviços).
A arquitetura orientada a serviços é bem apoiada pela comunidade de arquitetura e fornecedores. Daí a existência de muitos cursos e certificações, com padrões bem elaborados. Um exemplo desses padrões é o conhecido barramento de serviços empresariais (ESB = enterprise service bus). Vale ressaltar que o ESB é uma herança dos fornecedores, e não precisa ser necessariamente utilizado em SOA.
O pico da popularidade da arquitetura orientada a serviços ocorreu por volta de 2008, após o qual houve uma queda, que se tornou significativamente mais acentuada após o surgimento dos microsserviços (por volta de 2015).
Conclusão
Depois de discutirmos as possibilidades de organizar sistemas de informação na forma de serviços e módulos, proponho finalmente abordar os princípios da arquitetura de microsserviços e dedicar atenção especial à distinção entre arquitetura de microsserviços e arquitetura orientada a serviços na próxima parte.
Fonte: habr.com
