Microservice Architecture
Descrição
Microservice Architecture estrutura a aplicação como dois ou mais serviços implantáveis de forma independente e fracamente acoplados. Cada serviço contém um ou mais subdomínios, e cada subdomínio pertence a um único serviço (exceto bibliotecas compartilhadas).
Uma equipe é dona dos serviços que contêm seus subdomínios. Tipicamente cada serviço tem seu próprio repositório e pipeline de implantação, e um API Gateway serve como ponto de entrada para os clientes. Operações que atravessam serviços são implementadas com padrões de colaboração, como Saga e API Composition.
O estilo troca a simplicidade de um componente único por autonomia de equipes e flexibilidade, ao custo de lidar com os desafios de sistemas distribuídos.
Problemas que resolve
- Como agrupar os subdomínios da aplicação em componentes implantáveis ou executáveis.
- Necessidade de componentes simples, fáceis de entender, com autonomia de equipe para desenvolver e implantar.
- Necessidade de pipelines rápidos, viabilizados por componentes pequenos.
- Suporte a múltiplas pilhas tecnológicas.
- Segregação de subdomínios por escalabilidade, disponibilidade ou segurança.
Quando usar
- Aplicações críticas que precisam mudar de forma rápida, frequente e confiável.
- Organizações com várias equipes multifuncionais e entrega contínua automatizada.
- Quando subdomínios têm requisitos distintos de escala, disponibilidade, segurança ou tecnologia.
Quando evitar
- Aplicações pequenas ou com domínio ainda instável, onde as fronteiras de serviço seriam adivinhadas.
- Equipes sem maturidade em automação, observabilidade e operação de sistemas distribuídos.
- Quando transações ACID entre subdomínios e baixa latência de interação são requisitos centrais.
Trade-offs
| Ganho | Custo / Risco |
|---|---|
| Serviços pequenos e fáceis de entender | Operações distribuídas são complexas de entender e depurar |
| Equipes desenvolvem, testam e implantam de forma independente | Algumas operações distribuídas podem ser ineficientes |
| Build e testes rápidos por serviço | Banco por serviço costuma exigir consistência eventual |
| Pilhas tecnológicas diferentes por serviço | Acoplamento em tempo de execução pode reduzir a disponibilidade |
| Agrupamento por escalabilidade, segurança etc. | Acoplamento em tempo de projeto pode forçar mudanças coordenadas |
- Exige investimento em observabilidade, descoberta de serviços, resiliência e automação de implantação.
- Definir fronteiras corretas (por capacidade de negócio ou subdomínio) é decisivo para reduzir acoplamento.
Diagrama
Cada serviço é implantado de forma independente, possui seu próprio banco e é acessado por um API Gateway; a colaboração entre serviços ocorre por mensagens ou chamadas remotas.
Padrões relacionados
- Monolithic Architecture — estilo alternativo, com um único componente implantável.
- Decompose by Business Capability — define as fronteiras dos serviços.
- Decompose by Subdomain — define as fronteiras dos serviços a partir do DDD.
- Database per Service — cada serviço possui seus próprios dados.
- Saga — consistência em operações que atravessam serviços.
- API Composition — consultas que combinam dados de vários serviços.
- CQRS — consultas eficientes sobre dados distribuídos.
- Messaging — comunicação assíncrona entre serviços.
- Remote Procedure Invocation — comunicação síncrona entre serviços.
- Transactional Outbox — publicação atômica de mensagens e atualizações de dados.
- API Gateway — ponto de entrada para os clientes.
- Client-side Discovery — localização de instâncias de serviço.
- Server-side Discovery — localização de instâncias via roteador.
- Circuit Breaker — evita falhas em cascata entre serviços.
- Access Token — propagação da identidade entre serviços.
- Log Aggregation — observabilidade de sistemas distribuídos.
- Distributed Tracing — rastreamento de requisições entre serviços.
- Health Check API — verificação da saúde de cada serviço.
- Service Component Test — teste isolado de cada serviço.
- Microservice Chassis — preocupações transversais reutilizáveis.
- Externalized Configuration — configuração fora do artefato.