Arquitetura de Microsserviços - Fundamentos de Design de Sistemas Distribuídos

O que são Microsserviços

Arquitetura de microsserviços é uma abordagem de design que constrói aplicações como um conjunto de pequenos serviços independentes. Cada serviço tem uma responsabilidade única e pode ser implantado e escalado independentemente.

Netflix, Amazon, Uber e outros grandes serviços web adotam essa arquitetura.

Diferença do Monolito: Na arquitetura monolítica (bloco único), todas as funcionalidades estão contidas em uma única aplicação. Nos microsserviços, os serviços são divididos por funcionalidade.

De Monolito para Microsserviços

flowchart TB
    subgraph Mono["Arquitetura Monolítica"]
        subgraph App["Aplicação Única"]
            M1["Autenticação"]
            M2["Produtos"]
            M3["Pedidos"]
            M4["Pagamentos"]
        end
        SharedDB["Banco de Dados Compartilhado"]
        App --> SharedDB
    end

    subgraph Micro["Arquitetura de Microsserviços"]
        Auth["Serviço de<br/>Autenticação"] --> AuthDB["DB"]
        Product["Serviço de<br/>Produtos"] --> ProductDB["DB"]
        Order["Serviço de<br/>Pedidos"] --> OrderDB["DB"]
        Payment["Serviço de<br/>Pagamentos"] --> PaymentDB["DB"]
    end

Princípios de Design de Microsserviços

1. Princípio da Responsabilidade Única

Cada serviço se especializa em uma funcionalidade de negócio.

Bom exemplo:
- Serviço de Autenticação: Login, gerenciamento de tokens
- Serviço de Produtos: Informações de produtos, gerenciamento de estoque
- Serviço de Pedidos: Processamento de pedidos, histórico

Mau exemplo:
- Serviço de Usuário: Autenticação + Perfil + Notificações + Configurações
  → Responsabilidades demais

2. Autonomia

Serviços devem poder ser implantados e operados independentemente, sem depender de outros serviços.

3. Gerenciamento de Dados Distribuído

Cada serviço possui seus próprios dados e não acessa diretamente o banco de dados de outros serviços.

4. Isolamento de Falhas

Design para que a falha de um serviço não se propague para todo o sistema.

Padrões de Comunicação entre Serviços

Comunicação Síncrona (REST/gRPC)

Cliente → API Gateway → Serviço A → Serviço B
                              ↑
                         Aguarda resposta

• REST API: Baseado em HTTP, simples
• gRPC: Comunicação eficiente com Protocol Buffers

Comunicação Assíncrona (Fila de Mensagens)

Serviço A → [Fila de Mensagens] → Serviço B
            (RabbitMQ, Kafka)
               ↑
            Resposta imediata, processamento posterior

• Orientado a eventos: Realiza acoplamento fraco entre serviços
• Confiabilidade: Persistência e reenvio de mensagens

Abordagem para Divisão de Serviços

Domain-Driven Design (DDD)

Divida serviços por Bounded Context (Contexto Delimitado).

flowchart TB
    subgraph EC["Exemplo de Site E-Commerce"]
        subgraph ProductCtx["Contexto de Produto"]
            P1["Produto"]
            P2["Categoria"]
            P3["Estoque"]
        end

        subgraph OrderCtx["Contexto de Pedido"]
            O1["Pedido"]
            O2["Itens do Pedido"]
            O3["Envio"]
        end

        subgraph CustomerCtx["Contexto de Cliente"]
            C1["Cliente"]
            C2["Endereço"]
        end

        subgraph PaymentCtx["Contexto de Pagamento"]
            Pay1["Pagamento"]
            Pay2["Faturamento"]
        end
    end

Critérios de Divisão

Desafios e Soluções dos Microsserviços

Complexidade de Sistemas Distribuídos

Padrão Circuit Breaker

Situação normal:
Cliente → Serviço A → Serviço B
                ↓
           Resposta normal

Situação de falha (Circuito aberto):
Cliente → Serviço A ✕ Serviço B (falha)
                ↓
           Resposta de fallback
           (Cache ou valor padrão)

Quando Escolher Microsserviços

Casos Apropriados

• Desenvolvimento paralelo com equipes grandes
• Uso de stacks tecnológicos diferentes por serviço
• Escalar apenas funcionalidades específicas independentemente
• Domínio claramente divisível

Casos Não Apropriados

• Aplicações de pequena escala
• Equipes pequenas (5 pessoas ou menos)
• Conhecimento de domínio insuficiente
• Estrutura operacional não estabelecida

Monolith First: É frequentemente recomendado começar com monolito e dividir em microsserviços conforme o crescimento.

Resumo

Microsserviços são um poderoso padrão de arquitetura para gerenciar a complexidade de sistemas de grande escala. No entanto, também trazem desafios específicos de sistemas distribuídos. É importante escolher a arquitetura adequada considerando o tamanho da equipe, complexidade do negócio e capacidade operacional.