Arquitetura baseada em micro serviços
Tags: microservices, architecture
Published: 2022-02-02 03:07:52

**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.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wz577a7p3wjb8zctlqe7.png)

**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_