6 min leitura • Guide 851 of 877
Padrões de Comunicação de Microservices
Padrões de comunicação de microservices habilitam interação confiável entre serviços distribuídos. O GitScrum ajuda times a rastrear dependências de serviços, falhas de comunicação e coordenação inter-serviços em arquiteturas complexas de microservices.
Fundamentos de Comunicação de Microservices
Arquitetura de microservices depende de padrões eficientes de comunicação para manter confiabilidade e performance do sistema. Design pobre de comunicação pode levar a falhas em cascata, acoplamento forte e pesadelos de manutenção.
Desafios de Comunicação em Microservices
- Confiabilidade de rede: Serviços comunicam via redes propensas a falhas
- Latência: Chamadas de rede são mais lentas que comunicação in-process
- Consistência de dados: Manter consistência através de fronteiras de serviço
- Service discovery: Localização dinâmica de serviços em ambientes distribuídos
- Compatibilidade de versão: Gerenciar mudanças de API através de versões de serviço
Padrões de Comunicação Síncrona
APIs HTTP RESTful
PADRÃO REQUEST-RESPONSE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Client Service ──► API Gateway ──► Service A ──► Service B │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ HTTP Request Route & Auth Business Logic Data │
│ (JSON/XML) & Rate Limiting & Response │
│ │
└─────────────────────────────────────────────────────────────┘
BENEFÍCIOS:
├── Semântica HTTP simples e familiar
├── Payloads human-readable (JSON/XML)
├── Cache e suporte de browser built-in
├── Fácil de testar e debugar
DESVANTAGENS:
├── Chamadas síncronas bloqueantes
├── Potencial para falhas em cascata
├── Acoplamento forte entre serviços
├── Acúmulo de latência de rede
Comunicação gRPC
RPC BASEADO EM PROTOCOL BUFFER:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Client ──► Load Balancer ──► Service Instance │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ Proto Service Discovery Business Logic │
│ Request & Routing & Proto Response │
│ │
└─────────────────────────────────────────────────────────────┘
BENEFÍCIOS:
├── Alta performance com serialização binária
├── Contratos fortemente tipados com proto files
├── Suporte built-in a streaming
├── Agnóstico de linguagem com code generation
DESVANTAGENS:
├── Menos human-readable que JSON
├── Requer gerenciamento de proto files
├── Limitações de suporte em browser
├── Curva de aprendizado mais íngreme
Padrões de Comunicação Assíncrona
Message Queues e Arquitetura Event-Driven
PADRÃO PUBLISHER-SUBSCRIBER:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Publisher Service ──► Message Broker ──► Consumer 1 │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ Publish Event Queue/Topic Process Event │
│ to Topic/Queue Management & Update State │
│ Consumer 2 │
│ │ │
│ ▼ │
│ Process Event │
│ & Send Response │
│ │
└─────────────────────────────────────────────────────────────┘
BENEFÍCIOS:
├── Acoplamento solto entre serviços
├── Tolerância a falhas e escalabilidade melhoradas
├── Modelo de consistência eventual
├── Fit natural para eventos de domínio
DESVANTAGENS:
├── Complexidade de consistência eventual
├── Debugging de transações distribuídas
├── Desafios de ordenação de mensagens
├── Tratamento de mensagens duplicadas
Event Sourcing e CQRS
COMMAND QUERY RESPONSIBILITY SEGREGATION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Command Side ──► Event Store ──► Read Models │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ Validate & Store Events Query Data │
│ Generate as Sequence from Projections │
│ Events │
│ │
└─────────────────────────────────────────────────────────────┘
BENEFÍCIOS:
├── Audit trail de todas as mudanças
├── Queries temporais e time travel
├── Modelos de read e write escaláveis
├── Fundação para arquitetura event-driven
DESVANTAGENS:
├── Complexidade aumentada
├── Eventual consistency
├── Mais infraestrutura necessária
├── Curva de aprendizado significativa
Padrões de Resiliência
Circuit Breaker
PADRÃO CIRCUIT BREAKER:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ESTADOS DO CIRCUIT: │
│ │
│ ┌──────────┐ falhas > threshold ┌──────────┐ │
│ │ CLOSED │ ──────────────────────► │ OPEN │ │
│ │ (normal) │ │ (falhas) │ │
│ └──────────┘ └──────────┘ │
│ ▲ │ │
│ │ │ timeout │
│ │ sucesso ▼ │
│ │ ◄────────────────────────── ┌──────────┐ │
│ │ │HALF-OPEN │ │
│ │ falha │ (teste) │ │
│ └───────────────────────────────┴──────────┘ │
│ │
│ IMPLEMENTAÇÃO: │
│ ────────────── │
│ • Falhas consecutivas > 5 → OPEN │
│ • OPEN por 30 segundos → HALF-OPEN │
│ • 1 sucesso em HALF-OPEN → CLOSED │
│ • 1 falha em HALF-OPEN → OPEN │
│ │
└─────────────────────────────────────────────────────────────┘
Retry com Exponential Backoff
ESTRATÉGIA DE RETRY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ EXPONENTIAL BACKOFF: │
│ ───────────────────── │
│ Tentativa 1: Imediato │
│ Tentativa 2: Espera 1s │
│ Tentativa 3: Espera 2s │
│ Tentativa 4: Espera 4s │
│ Tentativa 5: Espera 8s │
│ Max retries: 5 │
│ │
│ COM JITTER (evita thundering herd): │
│ ──────────────────────────────────── │
│ delay = min(cap, base × 2^attempt) + random(0, 1000ms) │
│ │
│ QUANDO USAR: │
│ ───────────── │
│ ✓ Erros transientes (timeout, 503) │
│ ✓ Falhas de rede temporárias │
│ ✗ Erros de negócio (400, 422) │
│ ✗ Autenticação falhou (401, 403) │
│ │
└─────────────────────────────────────────────────────────────┘
Rastreamento no GitScrum
Mapeando Dependências de Serviço
RASTREAMENTO DE MICROSERVICES NO GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MAPA DE DEPENDÊNCIAS: │
│ ───────────────────── │
│ │
│ [Order Service] │
│ │ │
│ ├──► [Payment Service] (sync, crítico) │
│ │ │ │
│ │ └──► [Fraud Detection] (sync) │
│ │ │
│ ├──► [Inventory Service] (sync) │
│ │ │
│ └──► [Notification Service] (async, não-crítico) │
│ │
│ TAREFAS POR SERVIÇO: │
│ ─────────────────── │
│ [Label: service:order] │
│ [Label: service:payment] │
│ [Label: integration] │
│ │
│ IMPACTO DE MUDANÇA: │
│ ─────────────────── │
│ Mudança em Payment Service → │
│ Verificar: Order Service, Fraud Detection │
│ │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Checklist de Implementação
CHECKLIST DE COMUNICAÇÃO DE MICROSERVICES
═════════════════════════════════════════
DESIGN:
☐ Comunicação síncrona vs assíncrona decidida
☐ Contratos de API definidos
☐ Versionamento planejado
☐ Dependências mapeadas
RESILIÊNCIA:
☐ Circuit breakers implementados
☐ Retries com backoff
☐ Timeouts configurados
☐ Fallbacks definidos
OBSERVABILIDADE:
☐ Distributed tracing
☐ Métricas de comunicação
☐ Alertas para falhas
☐ Logs correlacionados
TESTING:
☐ Contract testing
☐ Integration testing
☐ Chaos testing
☐ Load testing
Comunicação bem projetada entre microservices é a fundação de sistemas distribuídos confiáveis e escaláveis.