Microservices e sistemas distribuídos

TL;DR

Este galho cobre como vários serviços formam uma plataforma distribuída: o modelo e a tese honesta, o ecossistema Spring Cloud, service discovery, API Gateway, resiliência com Resilience4j, comunicação síncrona entre serviços, segurança serviço a serviço, tracing distribuído com OpenTelemetry, consistência e service mesh. A tese que atravessa tudo: microservices é um trade-off, não o default. Quase sempre o monólito modular basta, e a rede é o inimigo — toda chamada que vira HTTP ganha latência, falha parcial e complexidade operacional. São 24 notas em 3 fases (Iniciado, Adepto, Magus).

Sobre este galho

A audiência é o desenvolvedor pleno avançando para senior, preparando-se para entrevista internacional, que precisa não só conhecer os padrões de Spring Cloud mas saber defender quando NÃO usá-los. Este é um galho híbrido: parte de pesquisa nova sobre o ecossistema distribuído e parte de poda reversa do tronco Spring Boot.md, extraindo o conteúdo de microservices que estava acoplado ao monólito.

A fronteira-assinatura é dupla. Atrás dele fica o Galho 14 (Mensageria e eventos) — saga, outbox, idempotência e gRPC vivem lá, porque são a face assíncrona do problema distribuído. À frente fica o Galho 17 (Cloud-native e produção) — containers, orquestração e operação em produção. Este galho 16 ocupa o meio: a plataforma síncrona de serviços, sua descoberta, seu roteamento e sua resiliência.

Iniciado

• O que são microservices e a tese honesta — definição, promessas, custos reais e por que o default deveria ser o monólito modular.
• Monorepo vs multi-repo — como organizar o código de vários serviços e os trade-offs de cada estratégia.
• Os 12 fatores e o serviço cloud-native — o checklist do Twelve-Factor App aplicado a um serviço Spring.
• Panorama do Spring Cloud — e o que morreu — o mapa do ecossistema, o que sobreviveu e os projetos descontinuados (Ribbon, Hystrix, Zuul).
• Comunicação inter-serviços — síncrono vs assíncrono — os dois estilos de comunicação e quando cada um é a escolha certa.

Adepto

• Service discovery — o conceito e o Eureka — por que serviços precisam se encontrar dinamicamente e como o Eureka resolve isso.
• Discovery — Consul e Kubernetes-native — alternativas ao Eureka e o discovery que o próprio Kubernetes oferece.
• Client-side load balancing — Spring Cloud LoadBalancer — balanceamento no cliente após a morte do Ribbon.
• Comunicação síncrona — OpenFeign e HTTP Interface — clientes declarativos para chamadas HTTP entre serviços.
• API Gateway — papel, roteamento, predicates e filters — a porta de entrada da plataforma e seu modelo de roteamento.
• Gateway reativo vs MVC — as duas variantes — Spring Cloud Gateway reativo versus a variante baseada em Servlet/MVC.
• Config centralizado — Spring Cloud Config — configuração externalizada e centralizada para muitos serviços.
• Resiliência I — a falha distribuída e o Circuit Breaker — por que a falha parcial existe e como o Circuit Breaker do Resilience4j a contém.
• Resiliência II — Retry e Time Limiter — repetição segura de chamadas e limites de tempo.
• Resiliência III — Bulkhead e Rate Limiter — isolamento de recursos e controle de vazão.
• Resiliência IV — compondo os padrões — a ordem correta de empilhar os decorators e o efeito combinado.
• Segurança entre serviços — propagação de identidade, tokens e mTLS na comunicação serviço a serviço.
• Tracing distribuído I — correlação no código — spans, contexto e correlação com Micrometer Tracing.
• Tracing distribuído II — exportando o trace — exportação via OpenTelemetry para backends como Tempo, Jaeger ou Zipkin.

Magus

• Consistência em sistemas distribuídos — CAP, consistência eventual e os limites do que a rede permite garantir.
• Os padrões de falha distribuída — anti-padrões e armadilhas recorrentes em arquiteturas distribuídas.
• Service mesh — quando a resiliência sai do código — Istio, Linkerd e o trade-off de mover resiliência para a infraestrutura.
• Quando NÃO fazer microservices — os sinais de que o monólito modular é a resposta certa.
• Capstone — uma requisição ponta a ponta na plataforma — o trajeto completo de uma requisição cruzando gateway, discovery, resiliência e tracing.

Rotas alternativas

• Completa: 01 → 02 → 03 → 04 → 05 → 06 → 07 → 08 → 09 → 10 → 11 → 12 → 13 → 14 → 15 → 16 → 17 → 18 → 19 → 20 → 21 → 22 → 23 → 24, em ordem.
• Entrevista internacional: 01 (a tese honesta) → 04 (panorama Spring Cloud) → 05 (síncrono vs assíncrono) → 13 (Circuit Breaker) → 16 (compondo a resiliência) → 18 (tracing no código) → 20 (consistência) → 23 (quando NÃO fazer) → 24 (capstone ponta a ponta).
• A plataforma Spring Cloud na prática: 04 (panorama) → 06 (discovery/Eureka) → 08 (load balancing) → 09 (OpenFeign/HTTP Interface) → 10 (API Gateway) → 11 (reativo vs MVC) → 12 (config centralizado).
• Resiliência (meio galho, cai muito): 13 (Circuit Breaker) → 14 (Retry e Time Limiter) → 15 (Bulkhead e Rate Limiter) → 16 (compondo os padrões) → 21 (padrões de falha distribuída).
• Arquitetura e julgamento: 01 (a tese honesta) → 02 (monorepo vs multi-repo) → 03 (12 fatores) → 20 (consistência) → 22 (service mesh) → 23 (quando NÃO fazer).

Veja também

• Trilha Java
• Mensageria e eventos (Galho 14)
• Segurança (Galho 12)
• Programação Reativa (Galho 11)
• Web e APIs REST (Galho 9)
• Build e tooling (Galho 15)
• Dicionário de Java
• Cloud-native e produção (Galho 17)
• Galho 18 — OCP / Certificação (planejado)

Notas do galho

TABLE fase, status
FROM "03-Dominios/Java/Microservices e sistemas distribuídos"
WHERE type = "concept"
SORT file.name ASC