Microservizi — Cheat Sheet

Tag: microservices, architecture, distributed-systems, docker, api-gateway, event-driven

Livello: intermedio

TL;DR: Pattern architetturali per scomporre domini complessi in servizi autonomi, comunicanti via API o eventi, con database separati e deploy indipendente.

Concetti chiave

Servizi autonomi focalizzati su un singolo bounded context di dominio.

Database per service: ogni microservizio possiede esclusivamente i propri dati.

Comunicazione sincrona via REST o gRPC per query immediate e dirette.

Comunicazione asincrona via message broker (RabbitMQ, Kafka) per disaccoppiamento temporale.

API Gateway come punto di ingresso unico per autenticazione, routing e rate limiting.

Service Discovery per localizzare dinamicamente le istanze attive dei servizi.

Eventual consistency gestita tramite pattern distribuiti come Saga (orchestrata o coreografata).

Resilienza con Circuit Breaker, retry con backoff esponenziale e fallback.

Tracing distribuito con correlazione degli identificatori (correlation ID) attraverso i confini di rete.

Deploy indipendente garantito da pipeline CI/CD dedicate e containerizzazione.

Domande tipiche e risposte pronte

Q: Quando ha senso passare da un monolito ai microservizi?R: Quando il dominio è chiaro, i team crescono e necessitano di scalare lo sviluppo e i deploy in modo indipendente senza blocchi reciproci.

Q: Come gestisci le transazioni distribuite tra più servizi?R: Evito il Two-Phase Commit e uso il pattern Saga, compensando le transazioni fallite tramite eventi asincroni o un orchestratore dedicato.

Q: Come garantisci la retrocompatibilità delle API?R: Applico il semantic versioning negli endpoint, introduco campi opzionali senza breaking changes e mantengo deprecate le versioni precedenti prima del ritiro.

Q: Qual è la differenza tra coreografia e orchestrazione nelle Saghe?R: Nella coreografia i servizi reagiscono direttamente agli eventi altrui; nell'orchestrazione un coordinatore centrale comanda esplicitamente i passi da eseguire.

Insidie e errori comuni

Creare un monolito distribuito condividendo lo stesso database tra più servizi.

Trascurare l'overhead operativo di rete, latenza e complessità di debugging distribuito.

Suddividere i servizi per layer tecnologico invece che per bounded context di business.

Mancanza di tracing distribuito centralizzato, rendendo impossibile isolare colli di bottiglia o errori.

Chiamate sincrone a cascata che propagano blocchi e failure a catena.

Snippet e comandi

# Esempio orchestrazione multi-servizio minimale in docker-compose
version: '3.8'
services:
  gateway:
    image: traefik:v2.10
    ports:
      - "80:80"
  orders-service:
    build: ./orders
    environment:
      - DATABASE_URL=postgres://user:pass@orders-db:5432/orders
      - BROKER_URL=amqp://rabbitmq:5672
    depends_on:
      - orders-db
      - rabbitmq
  orders-db:
    image: postgres:15-alpine
  rabbitmq:
    image: rabbitmq:3-management-alpine

Da ripassare

[ ] Pattern Saga orchestrata vs coreografata

[ ] Implementazione pratica di un Circuit Breaker con timeout e fallback

[ ] Strategie di schema migration per microservizi con zero-downtime

[x] Principi di Domain-Driven Design (DDD) e definizione dei Bounded Context

[x] Configurazione base di un API Gateway e Service Mesh