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.
Na última vez, falamos sobre os diferentes tipos de monólitos e o uso de componentes para construí-los, tanto os componentes de montagem quanto os componentes de implantação. Analisamos a arquitetura orientada a serviços.
Agora, finalmente vamos definir as principais características da arquitetura de microsserviços.
Relação das arquiteturas
É importante entender que, com base nos dados dos artigos anteriores, qualquer serviço é um componente, mas nem todo serviço é um microsserviço.
Características da arquitetura de microsserviços
As principais características da arquitetura de microsserviços são:
- Organização em torno das capacidades de negócios (Organized around Business Capabilities)
- Produtos, não projetos (Products not Projects)
- Pontos de entrada inteligentes e canais simples (Smart endpoints and dumb pipes)
- Governança descentralizada (Decentralized Governance)
- Gerenciamento de dados descentralizado (Decentralized Data Management)
- Automação de infraestrutura (Infrastructure Automation)
- Design para falhas (Design for failure)
- Arquitetura com evolução (Evolutionary Design)
O primeiro ponto vem da arquitetura orientada a serviços, pois os microsserviços são um caso particular dos serviços. Os outros pontos merecem uma consideração separada.
Organização em torno das capacidades de negócios (Organized around Business Capabilities)
Agora, é necessário lembrar da Lei de Conway: organizações que criam sistemas organizam sua arquitetura para refletir a estrutura de interação dentro dessas organizações. Um exemplo é o caso de criação de um compilador: uma equipe de sete pessoas desenvolveu um compilador de sete passagens, enquanto uma equipe de cinco desenvolveu um de cinco passagens.
Se falarmos sobre monólitos e microsserviços, quando o desenvolvimento é organizado por departamentos funcionais (backend, frontend, administradores de banco de dados), resulta em um monólito clássico.
Para obter microsserviços, as equipes precisam ser organizadas em torno das capacidades de negócios (equipe de pedidos, expedição, catálogo). Essa organização permitirá que as equipes se concentrem na criação de partes específicas da aplicação.
Produtos, não projetos (Products not Projects)
A abordagem de projeto em que a equipe transfere a funcionalidade desenvolvida para outras equipes em um cenário de arquitetura de microserviços não é adequada. A equipe deve manter o sistema ao longo de todo o seu ciclo de vida. A Amazon, uma das líderes na implementação de microserviços, afirmou: "você constrói o produto e você o executa" ("you build, you run it"). A abordagem orientada ao produto permite que a equipe sinta as necessidades do negócio.
Pontos de entrada inteligentes e canais simples (Smart endpoints and dumb pipes)
A arquitetura SOA deu grande atenção aos canais de comunicação, especialmente ao Enterprise Service Bus (barramento de serviços empresariais). Isso frequentemente leva ao Erroneous Spaghetti Box, ou seja, a complexidade do monólito se transforma na complexidade das interações entre os serviços. Na arquitetura de microserviços, são utilizadas apenas maneiras simples de interação.
Governança descentralizada (Decentralized Governance)
Decisões-chave sobre microserviços devem ser tomadas pelas pessoas que realmente os desenvolvem. Aqui, decisões-chave se referem à escolha
de linguagens de programação, metodologias de implantação, contratos de interfaces públicas etc.
Gerenciamento de dados descentralizado (Decentralized Data Management)
A abordagem padrão, onde o aplicativo depende de um único banco de dados, não pode levar em conta as especificidades de cada serviço. O MSA pressupõe uma gestão descentralizada de dados, incluindo a aplicação de diferentes tecnologias.
Automação de infraestrutura (Infrastructure Automation)
O MSA apoia processos de implantação e entrega contínuas. Isso só é possível através da automação dos processos. Nesse sentido, a implantação de um grande número de serviços não parece mais algo assustador. O processo de implantação deve se tornar rotineiro. O segundo aspecto está relacionado à gestão de serviços em um ambiente de produto. Sem automação, gerenciar processos que são executados em diferentes ambientes operacionais se torna impossível.
Design para falhas (Design for failure)
Numerosos serviços MSA estão sujeitos a falhas. Nesse caso, o tratamento de erros em um sistema distribuído é uma tarefa bastante não-trivial. A arquitetura das aplicações deve ser resiliente a tais falhas. Rebecca Parsons considera muito importante que não utilizemos mais nem mesmo a interação intra-processo entre os serviços; em vez disso, recorremos ao HTTP para comunicação, que não é, de forma alguma, tão confiável.
Arquitetura com evolução (Evolutionary Design)
A arquitetura do sistema MSA deve evoluir de forma gradual. É preferível limitar as mudanças necessárias aos limites de um único serviço. Também é importante considerar o impacto sobre outros serviços. A abordagem tradicional consiste em tentar resolver esse problema por meio de gerenciamento de versões, mas o MSA sugere usar o gerenciamento de versões como
uma medida extrema.
Conclusão
Após tudo que foi dito, podemos definir o que são microserviços. A arquitetura de microserviços é uma abordagem para desenvolver um aplicativo específico na forma de um conjunto de pequenos serviços, cada um operando em seu próprio processo e interagindo por meio de mecanismos leves, frequentemente interfaces de API de recursos HTTP. Esses serviços são construídos com base em oportunidades de negócios e podem ser implantados independentemente por meio de um mecanismo de implantação totalmente
automatizado. Existe um nível mínimo de gerenciamento centralizado desses serviços, que podem ser escritos em diferentes linguagens de programação e usar diferentes tecnologias de armazenamento de dados.
Fonte: habr.com
