Trilha de estudo
Trilha Arquitetura de Microsserviços: tudo o que estudar, tópico por tópico
Avaliação abrangente de arquitetura de microsserviços cobrindo decomposição de serviços, padrões de comunicação, gerenciamento de dados, resiliência e operações de produção. Cobre os princípios fundamentais de Sam Newman em Building Microservices.
Resposta curta
Para aprender Arquitetura de Microsserviços, percorra 6 módulos e 26 tópicos na ordem em que um apoia o próximo. Comece por Fundamentos de Microsserviços e siga para Design de Serviços e Padrões de Comunicação. Use o mapa como checklist, ou meça seu nível e estude só o que falta.
O que você vai estudar
Os tópicos estão agrupados por módulo. Abra um para ver os objetivos e os conceitos-chave.
1 · Fundamentos de Microsserviços5 tópicos
Trade-offs Monólito vs Microsserviços
Análise dos trade-offs entre arquitetura monolítica e microsserviços, incluindo quando cada abordagem é mais adequada.
Objetivos
- Justificar a escolha entre monólito e microsserviços para um contexto específico
- Identificar as falácias dos sistemas distribuídos e seus impactos práticos
Conceitos-chave
- vantagens do monólito
- falácias dos sistemas distribuídos
- overhead operacional de microsserviços
- quando NÃO usar microsserviços
- acoplamento e coesão no nível de implantação
- grande bola de lama
- custo de migração
Decomposição por Capacidade de Negócio
Estratégia de decomposição de serviços alinhada a capacidades de negócio para maximizar o acoplamento fraco.
Objetivos
- Construir um mapa de capacidades de negócio para decompor um sistema de e-commerce
- Identificar fronteiras de serviço baseadas em capacidades de negócio
Conceitos-chave
- capacidade de negócio
- mapa de capacidades
- acoplamento fraco por domínio
- time por serviço
- decomposição de Sam Newman
- fronteira de serviço
- propriedade de domínio
Decomposição por Subdomínio (Alinhada ao DDD)
Uso de conceitos de DDD para guiar a decomposição em microsserviços, alinhando contextos delimitados a fronteiras de serviço.
Objetivos
- Mapear subdomínios de DDD para fronteiras de microsserviços
- Aplicar o padrão strangler fig para decompor um monólito gradualmente
Conceitos-chave
- contexto delimitado
- subdomínio central
- subdomínio de suporte
- subdomínio genérico
- strangler fig
- identificação de costuras
- alinhamento de linguagem de domínio
Lei de Conway e Design Organizacional
A Lei de Conway afirma que sistemas de software refletem a estrutura de comunicação das organizações que os constroem.
Objetivos
- Aplicar a manobra inversa de Conway para projetar times que produzam a arquitetura desejada
- Identificar antipadrões organizacionais que geram serviços mal acoplados
Conceitos-chave
- Lei de Conway
- manobra inversa de Conway
- topologias de time
- time orientado a stream
- time de plataforma
- time habilitador
- carga cognitiva
Modelo de Maturidade de Microsserviços
Avaliação do nível de maturidade operacional e técnica necessário para adotar microsserviços com sucesso.
Objetivos
- Avaliar a maturidade de microsserviços de uma organização usando um modelo estruturado
- Identificar pré-requisitos operacionais antes de migrar para microsserviços
Conceitos-chave
- implantabilidade independente
- maturidade operacional
- completude de telemetria
- prontidão de service mesh
- implantação sem downtime
- rollback automatizado
- modelo de maturidade de Richardson
2 · Design de Serviços5 tópicos
Granularidade e Dimensionamento de Serviços
Heurísticas para determinar o tamanho correto de um microsserviço, evitando serviços muito grandes ou muito pequenos.
Objetivos
- Aplicar heurísticas de granularidade para decidir se dois serviços devem ser combinados ou separados
- Identificar antipadrões de nanoserviço e propor consolidação
Conceitos-chave
- granularidade de serviço
- antipadrão nanoserviço
- serviços tagarelas
- fan-out de serviço
- responsabilidade única em nível de serviço
- desintegradores de granularidade
- integradores de granularidade
Design de Contrato de API (REST + gRPC)
Princípios de design de contratos de API para microsserviços, cobrindo REST e gRPC com foco em estabilidade e evolução.
Objetivos
- Projetar um contrato de API contract-first para um serviço de pedidos
- Implementar testes de contrato dirigidos pelo consumidor com Pact
Conceitos-chave
- design de API REST
- vantagens do gRPC
- design contract-first
- especificação OpenAPI
- contratos dirigidos pelo consumidor
- testes Pact
- estabilidade de interface
Propriedade de Serviço e Alinhamento de Time
Modelo de propriedade de serviços onde times são responsáveis por construir, operar e evoluir seus serviços em produção.
Objetivos
- Definir um modelo de propriedade de serviços para uma organização de engenharia em crescimento
- Estruturar um catálogo de serviços com responsabilidades e SLOs claros
Conceitos-chave
- você-constrói-você-opera
- propriedade de serviço
- time de duas pizzas
- CODEOWNERS
- catálogo de serviços
- rotação de plantão
- inner source
Versionamento de API e Compatibilidade
Estratégias para versionar APIs de microsserviços mantendo compatibilidade com consumidores existentes.
Objetivos
- Projetar uma estratégia de versionamento de API com plano de migração e depreciação
- Distinguir mudanças quebradoras de não-quebradoras em uma API REST
Conceitos-chave
- versionamento semântico
- versionamento por URL
- versionamento por cabeçalho
- compatibilidade retroativa
- mudança quebradora vs não-quebradora
- Lei de Postel
- cabeçalhos Sunset
Arquitetura de Service Mesh
Camada de infraestrutura dedicada ao gerenciamento de comunicação serviço-a-serviço em ambientes de microsserviços.
Objetivos
- Projetar uma estratégia de service mesh para um ambiente com 50+ microsserviços
- Comparar service mesh com API gateway para diferentes casos de uso
Conceitos-chave
- proxy sidecar
- plano de controle
- plano de dados
- TLS mútuo
- modelagem de tráfego
- descoberta de serviços
- observabilidade via mesh
3 · Padrões de Comunicação5 tópicos
Comunicação Síncrona (REST, gRPC)
Padrões de comunicação síncrona entre microsserviços, incluindo trade-offs e antipadrões comuns.
Objetivos
- Avaliar quando usar REST vs gRPC para comunicação entre serviços
- Identificar e mitigar cadeias de latência em um grafo de chamadas de serviço
Conceitos-chave
- trade-offs REST vs gRPC
- acoplamento síncrono
- cadeia de latência
- amplificação de fan-out
- propagação de timeout
- pooling de conexões
- balanceamento de carga
Mensageria Assíncrona e Arquitetura Orientada a Eventos
Padrões de comunicação assíncrona usando brokers de mensagens para desacoplar microsserviços.
Objetivos
- Implementar o padrão outbox para garantir publicação confiável de eventos
- Projetar um consumidor idempotente que processe mensagens duplicadas com segurança
Conceitos-chave
- broker de mensagens
- publicar-assinar
- entrega pelo menos uma vez
- consumidor idempotente
- padrão outbox
- evolução de schema de evento
- desacoplamento via eventos
Padrão Saga (Coreografia e Orquestração)
Gerenciamento de transações distribuídas em microsserviços usando sagas com compensação.
Objetivos
- Projetar uma saga de orquestração para um fluxo de checkout com pagamento e inventário
- Comparar coreografia vs orquestração para uma saga com 5 serviços participantes
Conceitos-chave
- padrão saga
- saga baseada em coreografia
- saga baseada em orquestração
- transação compensatória
- máquina de estados da saga
- rollback semântico
- alternativa à transação distribuída
Request-Reply e IDs de Correlação
Padrão de comunicação assíncrona que simula request-reply usando mensageria com IDs de correlação.
Objetivos
- Implementar o padrão request-reply assíncrono com correlação de mensagens
- Projetar uma estratégia de timeout para operações assíncronas de longa duração
Conceitos-chave
- ID de correlação
- request-reply via mensageria
- fila reply-to
- rastreamento de mensagens
- request-response assíncrono
- polling vs callback
- timeout em assíncrono
Seleção de Message Broker
Critérios para selecionar o broker de mensagens mais adequado com base em requisitos de throughput, ordenação e retenção.
Objetivos
- Selecionar entre Kafka, RabbitMQ e SQS para um caso de uso específico com justificativa
- Explicar por que Kafka é preferido para event sourcing e auditoria em relação a RabbitMQ
Conceitos-chave
- Kafka broker baseado em log
- RabbitMQ broker baseado em fila
- SQS fila gerenciada
- grupo de consumidores
- garantias de ordenação de mensagens
- política de retenção
- comparação de throughput
4 · Gerenciamento de Dados4 tópicos
Padrão Banco de Dados por Serviço
Cada microsserviço possui e gerencia seu próprio armazenamento de dados, eliminando dependências de schema.
Objetivos
- Projetar uma estratégia banco de dados por serviço para um sistema de e-commerce com 8 serviços
- Propor alternativas ao JOIN entre serviços usando eventos e projeções
Conceitos-chave
- banco de dados por serviço
- antipadrão banco de dados compartilhado
- persistência poliglota
- estratégias alternativas ao JOIN
- propriedade de dados
- independência de schema
- independência de migração
Transações Distribuídas e Sagas
Gerenciamento de consistência de dados em operações que abrangem múltiplos microsserviços sem two-phase commit.
Objetivos
- Projetar uma saga para um processo de pedido que modifica 4 serviços
- Justificar por que sagas são preferidas a 2PC em sistemas de microsserviços
Conceitos-chave
- problemas do two-phase commit
- saga vs 2PC
- consistência eventual
- transação compensatória
- chave de idempotência
- outbox transacional
- estado do orquestrador de saga
CQRS em Microsserviços
Separação de responsabilidades de comando e consulta para otimizar independentemente leitura e escrita em microsserviços.
Objetivos
- Projetar um sistema CQRS para um serviço de catálogo com alta carga de leitura
- Explicar quando CQRS adiciona valor vs quando é over-engineering
Conceitos-chave
- padrão CQRS
- lado de comando
- lado de consulta
- modelo de leitura
- projeção orientada a eventos
- bancos separados leitura/escrita
- consistência eventual entre lados
Sincronização de Dados e Consistência Eventual
Estratégias para gerenciar a janela de inconsistência quando dados são replicados entre serviços.
Objetivos
- Projetar uma estratégia UX para janelas de consistência eventual em um sistema de pedidos
- Implementar leitura de seus próprios writes para um perfil de usuário replicado
Conceitos-chave
- consistência eventual
- estratégias de resolução de conflitos
- last-write-wins
- vector clocks
- anti-entropia
- leitura de seus próprios writes
- consistência causal
5 · Resiliência e Confiabilidade4 tópicos
Padrão Circuit Breaker
Padrão de resiliência que previne falhas em cascata interrompendo chamadas para serviços com falha.
Objetivos
- Implementar um circuit breaker com fallback para um serviço externo de pagamento
- Configurar limiares de circuit breaker para diferentes níveis de criticidade de serviço
Conceitos-chave
- estados do circuit breaker
- limiar de falha
- timeout de recuperação
- estratégia de fallback
- Resilience4j
- prevenção de falha em cascata
- combinação com bulkhead
Padrões de Retry, Timeout e Bulkhead
Padrões complementares ao circuit breaker para construir serviços resilientes contra falhas transitórias.
Objetivos
- Projetar uma estratégia de retry com backoff exponencial e jitter para chamadas a serviços externos
- Dimensionar um bulkhead de pool de threads para isolar chamadas críticas de não-críticas
Conceitos-chave
- backoff exponencial
- jitter
- risco de amplificação de retry
- orçamento de timeout
- isolamento bulkhead
- isolamento por pool de threads
- isolamento por semáforo
Health Checks e Probes de Readiness
Mecanismos para verificar a saúde e prontidão de microsserviços em produção.
Objetivos
- Projetar health checks que distinguam falhas de liveness de falhas de readiness
- Implementar um health endpoint que agregue saúde de dependências downstream
Conceitos-chave
- probe de liveness
- probe de readiness
- probe de startup
- padrão de health endpoint
- verificação de saúde de dependências
- reinício contínuo
- configuração de probes no Kubernetes
Engenharia do Caos
Prática de injetar falhas controladas em sistemas de microsserviços para descobrir fraquezas antes que ocorram em produção.
Objetivos
- Projetar um experimento de engenharia do caos para testar o circuit breaker de pagamento
- Definir uma hipótese de estado estacionário e métricas de saída para um game day
Conceitos-chave
- hipótese de estado estacionário
- injeção de falhas
- injeção de latência
- raio de explosão
- exercício de game day
- Chaos Monkey
- Chaos Toolkit
6 · Operações de Microsserviços3 tópicos
Rastreamento Distribuído e Observabilidade
Técnicas para rastrear requisições através de múltiplos microsserviços e construir observabilidade completa.
Objetivos
- Instrumentar um conjunto de microsserviços com OpenTelemetry para rastreamento distribuído
- Projetar uma estratégia de observabilidade cobrindo logs, métricas e traces
Conceitos-chave
- trace distribuído
- trace ID
- span
- propagação de contexto
- OpenTelemetry
- Jaeger
- três pilares da observabilidade
Estratégias de Implantação
Estratégias de implantação progressiva para microsserviços que minimizam risco e permitem rollback rápido.
Objetivos
- Projetar uma estratégia de implantação canary com critérios de promoção automática
- Comparar blue-green vs canary para um serviço crítico de pagamento
Conceitos-chave
- implantação canary
- implantação blue-green
- atualização rolling
- feature flag
- deslocamento de tráfego
- smoke test
- gatilho de rollback
Descoberta de Serviços e Gerenciamento de Configuração
Mecanismos para localizar instâncias de serviço dinamicamente e gerenciar configuração em ambientes de microsserviços.
Objetivos
- Comparar descoberta do lado do cliente vs servidor para um ambiente Kubernetes
- Projetar uma estratégia de gerenciamento de configuração para microsserviços com múltiplos ambientes
Conceitos-chave
- registro de serviços
- descoberta do lado do cliente
- descoberta do lado do servidor
- descoberta baseada em DNS
- configuração dinâmica
- gerenciamento de segredos
- Consul/etcd
Níveis: Júnior, Pleno e Sênior
Explique com suas palavras
Corrigido por IA · sem cadastro · 1 perguntaSem alternativas para chutar: você escreve, a IA corrige com a rubrica do tópico e diz em que nível sua resposta está.
Já estuda Arquitetura de Microsserviços?
A avaliação mede tópico por tópico, e o plano pula o que você já sabe.
Aberto para ler. A conta só é necessária para ser medido.
Perguntas frequentes
Por onde começar a estudar Arquitetura de Microsserviços?
Comece por Fundamentos de Microsserviços: Trade-offs Monólito vs Microsserviços, Decomposição por Capacidade de Negócio e Decomposição por Subdomínio (Alinhada ao DDD). O mapa ordena os tópicos pelo que depende de quê, então cada um prepara o seguinte.
Quanto tempo leva uma avaliação completa de Arquitetura de Microsserviços?
Uma avaliação completa desta trilha leva cerca de 60 minutos. O tempo de estudo depende de onde você começa; o diagnóstico mostra quais tópicos você pode pular.
Preciso de conta para usar esta página?
Não. O mapa, os objetivos e os conceitos-chave são abertos. A conta só é necessária para ser medido, ver seu gap por tópico e receber um plano.