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, falamos sobre os diferentes tipos de monólitos e como usar componentes para construí-los, tanto componentes de montagem quanto componentes de implantação. Nós descobrimos a arquitetura orientada a serviços.
Agora vamos finalmente definir as principais características de uma arquitetura de microsserviço.
Relação de arquiteturas
Deve ser entendido que com base nos dados das definições anteriores, qualquer serviço é um componente, mas nem todo serviço é um microsserviço.
Características de uma arquitetura de microsserviço
As principais características de uma arquitetura de microsserviço são:
- Organizado em torno de capacidades de negócios
- Produtos, não Projetos
- Endpoints inteligentes e tubos burros
- Governança Descentralizada
- Gerenciamento de dados descentralizado
- Automação de infraestrutura
- Projetar para o fracasso
- Design Evolucionário
O primeiro ponto vem da Arquitetura Orientada a Serviços, porque microsserviços são um caso especial de serviços. Outros pontos merecem consideração separada.
Organizado em torno de capacidades de negócios
Agora é preciso lembrar a lei de Conway: as organizações que criam sistemas organizam sua arquitetura, copiando a estrutura de interação dentro dessas organizações. Como exemplo, podemos lembrar o caso da criação de um compilador: uma equipe de sete pessoas desenvolveu um compilador de sete passos e uma equipe de cinco desenvolveu um compilador de cinco passos.
Se estivermos falando sobre monólitos e microsserviços, se o desenvolvimento for organizado por departamentos funcionais (back-end, front-end, administradores de banco de dados), teremos um monólito clássico.
Para obter microsserviços, as equipes precisam ser organizadas por oportunidade de negócios (pedido, remessa, equipe de catálogo). Essa organização permite que as equipes se concentrem na criação de partes específicas do aplicativo.
Produtos, não Projetos
Uma abordagem de projeto em que a equipe transfere a funcionalidade desenvolvida para outras equipes, no caso de uma arquitetura de microsserviço, é completamente inadequada. A equipe deve apoiar o sistema em todo o seu ciclo de vida. A Amazon, um dos carros-chefe da adoção de microsserviços, afirmou: “você constrói, você executa”. A abordagem do produto permite que a equipe sinta as necessidades do negócio.
Endpoints inteligentes e tubos burros
A arquitetura SOA deu muita atenção aos canais de comunicação, em particular o Enterprise Service Bus (Enterprise Service Bus). O que muitas vezes leva à Erroneous Spaghetti Box, ou seja, a complexidade do monólito se transforma na complexidade das conexões entre os serviços. A arquitetura de microsserviço usa apenas métodos de comunicação simples.
Governança Descentralizada
As principais decisões para microsserviços devem ser feitas pelas pessoas que realmente desenvolvem microsserviços. Aqui, as principais decisões significam a escolha
de linguagens de programação, metodologia de implantação, contratos de interface pública, etc.
Gerenciamento de dados descentralizado
A abordagem padrão, na qual um aplicativo depende de um único banco de dados, não pode levar em conta as especificidades de cada serviço específico. O MSA pressupõe a gestão descentralizada dos dados, até a utilização de várias tecnologias.
Automação de infraestrutura
O MSA oferece suporte a processos contínuos de implantação e entrega. Isso só pode ser feito automatizando processos. Ao mesmo tempo, a implantação de um grande número de serviços não parece mais algo assustador. O processo de implantação deve ser enfadonho. O segundo aspecto está relacionado ao gerenciamento de serviços no ambiente do produto. Sem automação, o gerenciamento de processos em execução em diferentes ambientes operacionais torna-se impossível.
Projetar para o fracasso
Vários serviços MSA estão sujeitos a falhas. Ao mesmo tempo, o tratamento de erros em um sistema distribuído não é uma tarefa trivial. A arquitetura do aplicativo deve ser resiliente a tais falhas. Rebecca Parsons acha que é muito importante que nem mesmo usemos mais a comunicação em processo entre os serviços, em vez disso, usamos HTTP para comunicação, que não é tão confiável.
Design Evolucionário
A arquitetura do sistema MSA deve evoluir. É desejável limitar as mudanças necessárias aos limites de um serviço. Também é necessário considerar o impacto em outros serviços. A abordagem tradicional é tentar corrigir esse problema com o controle de versão, mas a MSA sugere o uso do controle de versão como
último recurso.
Conclusão
Depois de tudo isso, podemos formular o que são microsserviços. A arquitetura de microsserviço é uma abordagem para desenvolver um único aplicativo como uma coleção de pequenos serviços, cada um dos quais é executado em seu próprio processo e interage por meio de mecanismos leves, geralmente uma API de recurso HTTP. Esses serviços são construídos em recursos de negócios e podem ser implantados de forma independente usando 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. Leia a parte 2
