Olá, Habr. Hoje dou continuidade a uma série de publicações que escrevi especificamente para o início de uma nova vertente 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 aplicações de construção e responder à questão de qual estilo arquitetônico é mais preferível. No processo de apresentação, tentarei traçar uma cadeia lógica que explique o desenvolvimento de estilos arquitetônicos de monólitos a microsserviços.
Da última vez falamos sobre os diferentes tipos de monólitos e o uso de componentes para construí-los, tanto componentes de construção quanto componentes de implantação. Entendemos a arquitetura orientada a serviços.
Agora iremos finalmente definir as principais características de uma arquitetura de microsserviços.
Relacionamento de arquiteturas
É necessário entender que com base nas definições dadas nos 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:
- Organizado em torno de capacidades de negócios
- Produtos, não projetos
- Endpoints inteligentes e pipes burros
- Governança Descentralizada
- Gerenciamento descentralizado de dados
- Automação de infraestrutura
- Projeto para o fracasso
- Arquitetura com desenvolvimento evolutivo (Design Evolutivo)
O primeiro ponto vem da arquitetura orientada a serviços porque os 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: 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 passagens e uma equipe de cinco pessoas desenvolveu um compilador de cinco passagens.
Se estamos falando de monólitos e microsserviços, se o desenvolvimento for organizado por departamentos funcionais (backend, frontend, administradores de banco de dados), teremos um monólito clássico.
Para obter microsserviços, as equipes devem ser organizadas por capacidade de negócio (pedidos, remessas, equipe de catálogo). Essa organização permitirá que as equipes se concentrem na construção de partes específicas do aplicativo.
Produtos, não projetos
Uma abordagem de projeto em que uma equipe transfere a funcionalidade desenvolvida para outras equipes é completamente inadequada no caso de uma arquitetura de microsserviços. A equipe deve apoiar o sistema durante todo o seu ciclo de vida. A Amazon, uma das líderes na implementaçã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 pipes burros
A arquitetura SOA prestou grande atenção aos canais de comunicação, em particular ao Enterprise Service Bus. O que muitas vezes leva à Caixa de Espaguete Errada, ou seja, a complexidade do monólito se transforma na complexidade das conexões entre os serviços. A arquitetura de microsserviços usa apenas métodos de comunicação simples.
Governança Descentralizada
As principais decisões sobre microsserviços devem ser tomadas pelas pessoas que realmente desenvolvem os microsserviços. Aqui, decisões importantes significam escolhas
linguagens de programação, metodologia de implantação, contratos de interface pública, etc.
Gerenciamento descentralizado de dados
A abordagem padrão, em que a aplicação depende de uma única base de dados, não pode levar em conta as especificidades de cada serviço específico. MSA envolve gerenciamento descentralizado de dados, incluindo o uso de diversas tecnologias.
Automação de infraestrutura
A MSA oferece suporte a processos contínuos de implantação e entrega. Isso só pode ser alcançado 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 se tornar enfadonho. O segundo aspecto está relacionado ao gerenciamento de serviços em um ambiente de produto. Sem automação, o gerenciamento de processos executados em diferentes ambientes operacionais torna-se impossível.
Projeto 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 muito importante que não utilizemos mais a comunicação entre serviços durante o processo; em vez disso, recorremos ao HTTP para comunicação, que não é tão confiável.
Arquitetura com desenvolvimento evolutivo (Design Evolutivo)
A arquitetura do sistema MSA deverá evoluir de forma evolutiva. É aconselhável limitar as alterações necessárias aos limites de um único serviço. O impacto noutros serviços também deve ser tido em conta. A abordagem tradicional é tentar resolver esse problema com versionamento, mas a MSA sugere usar o versionamento em
como último recurso.
Conclusão
Depois de tudo isso, podemos formular o que são microsserviços. A arquitetura de microsserviços é uma abordagem para desenvolver um único aplicativo como uma coleção de pequenos serviços, cada um executando seu próprio processo e interagindo por meio de mecanismos leves, geralmente uma API de recurso HTTP. Esses serviços são construídos com base em recursos de negócios e podem ser implantados de forma independente usando recursos totalmente
mecanismo de implantação automatizado. Existe um nível mínimo de gerenciamento centralizado desses serviços, que podem ser escritos em diferentes linguagens de programação e utilizar diferentes tecnologias de armazenamento de dados.
Fonte: habr.com