Como construir microsserviços com Spring Boot: config, discovery, resiliência?

Question

IT Interview Practice · Accepted Answer

Spring Boot mais Spring Cloud te dão os blocos de construção para microsserviços. Os três problemas que todo sistema distribuído precisa resolver são **configuração centralizada**, **service discovery** e **resiliência** contra falhas parciais. ## As peças móveis ```text ┌── Config Server (git-backed properties) │ Client ──▶ API Gateway ──▶ Service A ──▶ Service B │ │ │ └──▶ Discovery (Eureka / K8s DNS) ◀── register + look up ``` - **Config Server** serve as propriedades de cada serviço a partir de um repositório git central, então você muda a config sem reimplantar. Os serviços a puxam na inicialização (e recarregam via `/actuator/refresh`). - **Service discovery** (Eureka, Consul ou Kubernetes DNS) permite que o Serviço A encontre o Serviço B pelo *nome* em vez de um host hard-coded, para que as instâncias possam escalar e mudar livremente. - **API Gateway** (Spring Cloud Gateway) é o ponto de entrada único para roteamento, auth e rate limiting. ## Resiliência — a parte que os juniores pulam Em um sistema distribuído, toda chamada de rede *vai* falhar em algum momento. Use o Resilience4j para impedir que um serviço lento provoque uma cascata que vira uma indisponibilidade: ```java @CircuitBreaker(name = "inventory", fallbackMethod = "cachedStock") @Retry(name = "inventory") // retry transient blips @TimeLimiter(name = "inventory") // cap the wait public CompletableFuture stock(String sku) { return inventoryClient.get(sku); // remote call } // Called when the circuit is open or the call fails — degrade gracefully. public CompletableFuture cachedStock(String sku, Throwable ex) { return CompletableFuture.completedFuture(Stock.unknown(sku)); } ``` O **circuit breaker** abre depois de falhas repetidas, então as chamadas falham rápido em vez de se acumularem em threads esperando por uma dependência morta. ## Por que isso importa Entrevistas sênior investigam a maturidade em sistemas distribuídos. Nomear discovery e config é o básico; o diferencial é falar sobre **falha**: circuit breakers, timeouts, idempotência e observabilidade (distributed tracing com Micrometer/Zipkin). Candidatos fortes também questionam — apontando que microsserviços adicionam custo operacional e que um monolito é frequentemente a escolha certa até que a escala exija outra coisa.

As peças móveis

Resiliência — a parte que os juniores pulam

Por que isso importa

Perguntas relacionadas