Arquitetura & Componentes

A loja agora tem seis serviços. Cada um deles precisa de HTTPS, precisa verificar quem é o usuário, precisa ser encontrado pelos outros mesmo que os seus containers subam e desçam, precisa de configuração e de segredos, e precisa produzir logs e métricas. Se cada time resolver esses problemas dentro do próprio serviço, a plataforma acaba com seis implementações ligeiramente diferentes (e ligeiramente erradas) da mesma coisa. A resposta é levar essas preocupações transversais (cross-cutting concerns) — preocupações que todo serviço tem, mas que não fazem parte de nenhum domínio de negócio — para uma infraestrutura compartilhada.

Um sistema de microsserviços em produção é mais do que uma coleção de serviços independentes. Ele exige um conjunto de componentes de infraestrutura que cuidam das preocupações transversais — roteamento, segurança, descoberta, configuração e observabilidade — para que cada serviço possa se manter focado no seu domínio de negócio¹.

Componentes

Balanceador de carga

Distribui o tráfego de entrada entre várias instâncias de um serviço. Impede que uma única instância vire gargalo e desvia o tráfego das instâncias não saudáveis.

• Camada 4 (TCP): rápido, roteia por IP/porta — usado para vazão bruta.
• Camada 7 (HTTP): roteia por caminho da URL, headers ou cookies — permite roteamento baseado em conteúdo e canary deployments.

No curso, o Hands-on 7 coloca o Nginx na frente de várias réplicas do gateway, usando o algoritmo least_conn (cada nova requisição vai para a réplica com o menor número de conexões ativas).

CDN (Content Delivery Network)

Uma rede de caches distribuída geograficamente que serve arquivos estáticos (imagens, JS, CSS) a partir do local mais próximo do usuário. Reduz a latência para clientes no mundo todo e alivia o tráfego dos servidores de origem.

API Gateway

O ponto de entrada único para todos os clientes externos. O gateway é responsável por:

O gateway é a fronteira entre a internet pública e a rede interna confiável. No curso, ele é uma aplicação Spring Cloud Gateway (Hands-on 2); as rotas são declaradas no application.yaml, por exemplo Path=/accounts/** → http://account:8080.

Provedor de identidade

Gerencia a autenticação e a autorização dos usuários usando protocolos padrão:

• OAuth 2.0 — framework de delegação: um usuário concede a um cliente acesso aos seus recursos sem compartilhar a senha.
• OpenID Connect (OIDC) — camada de identidade sobre o OAuth 2.0: fornece um token de identidade JWT (id_token) além do token de acesso.
• JWT (JSON Web Token) — um token assinado e autocontido que codifica claims (ID do usuário, papéis, expiração). Os serviços validam a assinatura sem chamar o provedor de identidade a cada requisição.

No curso, o serviço de autenticação cumpre esse papel de forma simplificada: ele cadastra e autentica usuários, emite um JWT (guardado em um cookie) e resolve um token de volta para um id de conta para o gateway (Hands-on 3). OAuth 2.0 e OIDC são abordados em Segurança.

Descoberta e registro de serviços

Em um ambiente dinâmico, em que as instâncias dos serviços escalam para cima e para baixo e os endereços IP mudam, os serviços não podem ter endpoints fixos no código. Um registro de serviços (Consul, Eureka, DNS do Kubernetes) armazena a localização atual de todas as instâncias. Os serviços se registram ao iniciar e se descadastram ao desligar.

• Descoberta no cliente (client-side): quem chama consulta o registro e faz o próprio balanceamento de carga.
• Descoberta no servidor (server-side): o balanceador de carga ou o gateway consulta o registro em nome de quem chama.

No curso, o DNS da plataforma é o registro. O Docker Compose dá a cada serviço um hostname igual ao seu nome, então a rota do gateway e o cliente Feign simplesmente usam http://account:8080; com várias réplicas, o nome resolve para todas elas. No Kubernetes (Hands-on 5), um objeto Service ganha um nome DNS estável e distribui o tráfego entre os pods por trás dele — descoberta no servidor, sem Eureka nem Consul para operar.

Serviço de configuração

Centraliza a configuração de todos os serviços (Spring Cloud Config, AWS Parameter Store, Vault). As mudanças podem ser enviadas aos serviços em execução sem um novo deploy. Os segredos (credenciais, chaves de API) são armazenados criptografados e injetados em tempo de execução.

No curso, a configuração segue a regra twelve-factor de mantê-la no ambiente³: o application.yaml lê variáveis como ${DATABASE_HOST}, cujos valores vêm do arquivo .env e do compose.yaml, e depois dos ConfigMaps e Secrets do Kubernetes. A mesma imagem roda em todos os ambientes; só o ambiente muda.

Message broker

Transporta eventos entre os serviços de forma assíncrona, para que o produtor não espere — nem sequer conheça — os seus consumidores. O curso usa o Apache Kafka: o serviço de pedidos publica OrderCreated no tópico order-events e o serviço de notificação o consome (Hands-on 9, Arquitetura orientada a eventos).

Cache distribuído

Um armazenamento em memória compartilhado por todas as réplicas de um serviço, usado para evitar repetir chamadas ou consultas caras. Com várias réplicas do gateway, um cache local em cada JVM guardaria dados diferentes; o Redis dá a elas um único cache compartilhado (Hands-on 8).

Stack de observabilidade

Com dezenas de processos, "olhar o log" não funciona mais. A plataforma coleta métricas (o Prometheus coleta o /actuator/prometheus de cada serviço; o Grafana desenha os dashboards — Hands-on 6) e traces que acompanham uma requisição através dos serviços (OpenTelemetry + Jaeger — Hands-on 10). Veja Observabilidade.

Resumo: a plataforma do curso

Nossa arquitetura

O diagrama abaixo mostra a arquitetura de referência usada neste curso:

flowchart LR
  subgraph client["Internet"]
    direction LR
    Web
    Mobile
    Desktop
  end
  subgraph trusted ["Camada confiável"]
    direction LR
    lb(["Balanceador de carga"])
    gateway["API Gateway"]
    auth["Auth Service"]
    subgraph bm ["Microsserviços de negócio"]
      direction LR
      ms1["Serviço 1"]
      ms2["Serviço 2"]
      ms3["Serviço 3"]
      db1[("Banco de dados 1")]
      db2[("Banco de dados 2")]
    end
  end
  subgraph third-party["APIs de terceiros"]
    direction LR
    tp1["Serviço externo"]
  end
  client --> lb --> gateway
  gateway --> ms1
  gateway --> ms2
  gateway --> ms3
  ms1 --> db1
  ms2 --> db2
  ms2 --> ms3
  ms3 --> tp1
  gateway --> auth

Na loja, os microsserviços de negócio são account, product e order; o serviço de câmbio é o que chama uma API de terceiros.

Principais decisões de projeto desta arquitetura:

• Todo o tráfego externo entra pelo gateway. Os serviços internos não são acessíveis pela internet.
• A autenticação é um serviço separado. O gateway delega a validação do token ao Auth Service (POST /auth/solve) e repassa a identidade de quem chamou no header id-account; os microsserviços de negócio confiam nesse header e nunca interpretam o JWT por conta própria.
• Cada serviço tem o próprio banco de dados. Sem esquema compartilhado. Os serviços se comunicam por APIs, não por tabelas compartilhadas.
• Os serviços podem chamar uns aos outros. O Serviço 2 chama o Serviço 3 para uma suboperação. Em fluxos síncronos, isso é aceitável; para confiabilidade em escala, considere padrões orientados a eventos.

Acompanhando uma requisição

Um usuário autenticado faz um pedido. Cada componente acima cumpre o seu papel, nesta ordem:

sequenceDiagram
    autonumber
    actor U as Navegador
    participant N as Nginx
    participant G as Gateway
    participant A as Auth
    participant O as Order
    participant P as Product
    participant K as Kafka
    U->>N: POST /orders (cookie com JWT)
    N->>G: repassa para uma réplica do gateway
    G->>A: POST /auth/solve (token)
    A-->>G: idAccount
    G->>O: POST /orders + header id-account
    O->>P: GET /products/{id}
    P-->>O: produto com preço
    O->>O: salva o pedido no próprio esquema
    O-)K: OrderCreated (assíncrono)
    O-->>G: 201 Created
    G-->>N: 201 Created
    N-->>U: 201 Created

• 1–2 O balanceador de carga escolhe uma réplica do gateway.
• 3–4 O gateway verifica o token com o serviço de autenticação e descobre quem é o usuário.
• 5 Ele roteia para o serviço de pedidos, adicionando o header id-account.
• 6–7 O serviço de pedidos pergunta o preço à API de produtos (nunca à tabela de produtos).
• 8–9 Ele salva o pedido no próprio esquema e publica um evento no broker, sem esperar o serviço de notificação.
• 10–12 A resposta faz o caminho de volta. Um trace no Jaeger mostra exatamente esses saltos como spans.

Boas práticas

Essas práticas são desenvolvidas em aulas próprias: Padrões de resiliência, Deploy, Observabilidade e Versionamento REST².

Pontos-chave

• As preocupações transversais (roteamento, autenticação, descoberta, configuração, observabilidade) pertencem à infraestrutura compartilhada, não a cada serviço.
• O gateway é o ponto de entrada único e a fronteira de confiança; o balanceador de carga distribui a carga entre réplicas idênticas.
• No curso, o gateway resolve o JWT por meio do serviço de autenticação e repassa o id-account; os serviços nunca interpretam tokens.
• A descoberta é o DNS da plataforma (Docker Compose, depois Services do Kubernetes); a configuração vem do ambiente.
• Kafka, Redis, Prometheus/Grafana e OpenTelemetry/Jaeger completam a plataforma — cada um é construído em um hands-on.

Conexões

• Construa os componentes: Hands-on 2 — Gateway, 3 — Segurança, 5 — Orquestração, 6 — Observabilidade, 7 — Balanceador de carga, 8 — Cache, 9 — Kafka, 10 — Rastreamento.
• Por que e onde dividir: Microsserviços, Domain-Driven Design.
• Fazendo o deploy de tudo: Projeto.