Arquitetura baseada em micro serviços

O que é?

A arquitetura de micro serviços é uma abordagem na qual a aplicação é fragmentada em componentes mínimos e independentes, onde estes quando unidos formam a aplicação final.

Qual objetivo da utilização?

Construir um conjunto de pequenas aplicações, cada uma responsável por executar uma função.

Principais características:

- Componentização via serviços

Componente é uma unidade de software
independente que pode ser substituída ou atualizada, ou seja, na arquitetura de micro serviços os serviços são divididos em unidades independentes que nas quais comunicam-se gerando um serviço maior.

- Organização em torno de capacidades de negócios

Na arquitetura em de micro serviços a organização tem que ser em torno do negócio e não técnica. Então, cada micro serviço é um
produto e esses produtos precisam estar organizados dentro do contexto do produto. Visando essas características pode-se
observar pontos importantes a serem adotados: squads de desenvolvimento por produtos, squads multidisplinar (imagine uma squad formada por: front-ends, back-end, designer, QA, product
owner e scrum master)

- Produtos não Projetos

Micro serviços devem ser orientados a produtos e não ao projeto em si, quando a orientação é focada no projeto normalmente temos uma equipe com objetivo de concluir o desenvolvimento do software e normalmente quando essa equipe conclui o software ela é dissolvida ou diminuída restando alguns integrantes para a manutenção, já quando a arquitetura é focado no produto temos uma equipe com toda responsabilidade daquele produto desde a codificação quanto a manutenção. A equipe ficará com responsabilidade de manter esse serviço funcionando e evoluindo de acordo com as necessidades.

- Smart endpoints and dumb pipes

Há diversas formas dos sistemas se comunicarem, quando falamos de micro serviços temos que entender que essa forma de comunicação deverá ser simples e rápida. Quando falamos em smart endpoints queremos dizer que: são endpoints onde sejam possíveis enviar e receber informações de maneira rápida, um exemplo disso seria comunicação via REST. Entretanto, o que são dump pipes? São os serviços que não tem uma lógica em si (por isso o dump que em tradução livre seria canos burros), eles apenas tem as responsabilidades de enviar informação para uma
fila ou escutar informação de uma fila, esses serviços são também conhecidos como serviços de mensageria (rabbitMQ ou Kafka, por
exemplo)

- Governança descentralizada

Conforme falado em princípios anteriores os micro serviços são baseados em produtos e cada produto tem sua necessidade diferente no que concerne a tecnologia e padrões de desenvolvimento. Com isso, o conceito da governança descentralizada chega para oferecer que cada micro serviço tenha um arsenal de ferramentas diferentes de acordo com sua
necessidade.

- Gerenciamento de dados descentralizado

Na arquitetura baseada em micro serviços temos cada micro serviço sendo capaz de gerenciar seu próprio banco de dados. Sejam instancias diferentes do mesmo banco de dados ou até
banco de dados diferentes, também é possível que um outro micro serviço não tenha a necessidade persistir dados. Contudo, há
outras implicações em abordagens como esta, apesar de ganharmos em velocidade, podemos perder em consistência. Entretanto, há varias maneiras que possibilitam gerenciar as
inconsistências, recuperando ou corrigindo os erros que possam surgir.

- Automação de infraestrutura

Quando se é adotado a arquitetura de micro serviços é necessário haver uma agilidade no que concerne a infraestrutura dos serviços
construídos, ou seja é preciso haver uma velocidade ao fazer o deploy dos serviços em produção. É necessário haver um processo
para que seja possível escalar rapidamente os micro serviços, por exemplo: Caso uma aplicação tenha pico de acessos a infra precisa estar preparada para esse contexto.

- Projetado para falhas

Uma das consequências da componentizaçao dos serviços é que esses precisam serem projetados para que possam tolerar eventuais falhas, qualquer serviço pode cair e provavelmente
haverá outros serviços que dependem dele. É preciso ter um plano mapeado caso um cenário como este aconteça. Essas decisões variam também por negocio, imagine o seguinte cenário: Temos uma loja virtual e o serviço de estoque por algum motivo está fora do ar. Uma das decisões seria fazer com que o cliente prossiga
com a venda e quando o serviço voltar, dar baixa no estoque (caso não tenha o produto em questão, gerar um estorno para o cliente
cancelando a venda). Perceba que do ponto de vista negocial não faria sentido cancelar a venda do cliente apenas porque o serviço
de estoque caiu.

- Design Evolutivo

Os seus serviços/produtos tem que estar bem definidos e preparados para possíveis evoluções, no ponto de vista negocial os produtos podem ser extintos ou evoluídos. Quando se fala em design evolutivo é imprescindível falar em gerenciamento
de versões, ou seja, tenho um e-commerce e preciso atualizar o serviço da pagamentos, entretanto esse serviço não pode ficar “offline” para a alteração. É preciso disponibilizarmos uma nova versão do serviço (que será modificada) enquanto a antiga ainda continuará funcionando, apenas depois que a nova versão tiver sido implementada e testada que faremos a troca dos serviços.

Fonte: Microservices by Martin Fowler - https://bit.ly/32NdkSN

Escrito por: Hennan Gadelha