API Gateway
Un API gateway è un punto di ingresso unico posto davanti a un insieme di microservizi che instrada le richieste dei client verso il servizio appropriato. Gestisce tipicamente preoccupazioni trasversali come autenticazione, rate limiting, terminazione TLS, aggregazione delle richieste e traduzione di protocollo. Centralizzando questi aspetti mantiene i singoli servizi concentrati sulla logica di business, al prezzo di essere un componente che deve essere reso a sua volta altamente disponibile.
Aggregator Pattern
Il pattern aggregator compone una singola risposta a partire da più servizi a valle, all'interno di un API gateway (gateway-aggregation) oppure in un servizio di composizione dedicato. Riduce il traffico chiacchierone tra client e servizi e consente al chiamante di fare una richiesta sola invece di molte. Il compromesso è l'accoppiamento sulla latenza e la necessità di gestire i fallimenti parziali delle chiamate a valle.
Backend for Frontend (BFF)
Un Backend for Frontend è un componente lato server modellato sui bisogni di una specifica esperienza client, come un'app mobile o una SPA web. Invece di una singola API generica, ogni frontend ha il proprio backend che aggrega e adatta i dati per quel client. Questo evita l'over-fetching e permette ai team client di evolvere il loro BFF in modo indipendente dai servizi sottostanti.
Bounded Context
Nel Domain-Driven Design un bounded context è un confine esplicito all'interno del quale un particolare modello di dominio e il suo linguaggio ubiquo sono coerenti. I bounded context sono le cuciture naturali lungo cui suddividere un sistema in servizi, perché ciascun contesto possiede una fetta coesa del dominio con sovrapposizione minima. Allineare i confini dei servizi ai bounded context riduce l'accoppiamento tra servizi.
Bulkhead
Il pattern bulkhead isola risorse come pool di thread o pool di connessioni in modo che un fallimento o una saturazione in una parte del sistema non possa esaurire le risorse necessarie al resto. Prende il nome dalle paratie stagne dello scafo di una nave. Nei microservizi impedisce che una dipendenza lenta consumi tutti i thread e faccia cadere un intero servizio.
Choreography
La choreography è un modo di coordinare un flusso distribuito in cui ogni servizio reagisce a eventi ed emette i propri eventi, senza un coordinatore centrale. Produce accoppiamento lasco e buona autonomia, ma rende il flusso end-to-end più difficile da osservare e da comprendere. Si contrappone all'orchestration, dove un componente centrale guida i passi.
Circuit Breaker
Un circuit breaker è un pattern di resilienza che monitora le chiamate verso una dipendenza remota e, superata una soglia di fallimenti, scatta in stato aperto per fallire rapidamente invece di attendere un servizio in difficoltà. Dopo un periodo di raffreddamento consente alcune chiamate di prova (half-open) per verificare il recupero prima di richiudersi. Previene i fallimenti a cascata e dà respiro alla dipendenza in difficoltà.
Consumer-Driven Contract
Un consumer-driven contract è un artefatto di test in cui il consumatore di un'API dichiara le richieste esatte che effettua e le risposte che si aspetta, e il provider verifica di poter soddisfare il contratto di ogni consumatore. Intercetta in CI le modifiche di API che rompono la compatibilità, prima del deploy, senza la fragilità dei test end-to-end completi. Strumenti come Pact implementano questo pattern.
Container
Un container impacchetta un'applicazione insieme al suo runtime, alle librerie e alla configurazione in un'unità isolata e portabile che gira in modo coerente tra ambienti diversi. I container condividono il kernel dell'host, il che li rende più leggeri delle macchine virtuali. Nei microservizi ogni servizio è tipicamente costruito come immagine container e distribuito in modo indipendente.
Container Orchestration
L'orchestrazione di container automatizza il deployment, lo scaling, il networking e la gestione del ciclo di vita dei container su un cluster di macchine. Si occupa di scheduling, health check, self-healing e aggiornamenti progressivi. Kubernetes è l'orchestratore di fatto standard per i microservizi.
Dead Letter Queue (DLQ)
Una dead letter queue è una coda dove vengono inviati i messaggi che non possono essere elaborati con successo dopo un numero configurato di tentativi. Impedisce a un messaggio velenoso di bloccare un consumatore a tempo indeterminato e conserva il messaggio fallito per ispezione e riesecuzione. Le DLQ sono essenziali per gestire sistemi event-driven affidabili.
Distributed Tracing
Il tracing distribuito segue una singola richiesta mentre si propaga tra più servizi, allegando e propagando un contesto di correlazione fatto di identificatori di trace e span. Ricostruisce il percorso e i tempi end-to-end di una richiesta, cosa essenziale per diagnosticare latenze e fallimenti in un sistema a microservizi. OpenTelemetry è lo standard dominante per strumentare le tracce.
Domain-Driven Design (DDD)
Il Domain-Driven Design è un approccio che pone al centro della progettazione del software un modello ricco del dominio di business, espresso in un linguaggio ubiquo condiviso. I suoi pattern strategici, bounded context e context mapping, sono ampiamente usati per individuare dove tracciare i confini dei microservizi. I suoi pattern tattici, aggregati, entità e value object, plasmano il modello interno di un servizio.
Eventual Consistency
La consistenza eventuale è un modello di consistenza in cui, in assenza di nuovi aggiornamenti, tutte le repliche di un dato convergeranno nel tempo allo stesso valore, pur potendo essere temporaneamente incoerenti. I sistemi distribuiti spesso accettano la consistenza eventuale per guadagnare disponibilità e tolleranza alle partizioni. Richiede che applicazione e utenti tollerino la lettura di dati leggermente obsoleti.
Event Sourcing
L'event sourcing persiste lo stato di un'entità come una sequenza append-only di eventi immutabili invece che come stato corrente. Lo stato attuale si deriva rieseguendo gli eventi, il che produce un log di audit completo e abilita query temporali e la ricostruzione dei read model. È più complesso dello storage CRUD ed è di norma giustificato solo quando la storia degli eventi ha di per sé valore di business.
Event-Driven Architecture
L'architettura event-driven è uno stile in cui i servizi comunicano producendo e consumando eventi, tipicamente attraverso un message broker, invece che con chiamate sincrone dirette. Promuove l'accoppiamento lasco e la resilienza perché i produttori non devono sapere chi consuma i loro eventi. Il compromesso è un ragionamento end-to-end più difficile e la necessità di una gestione idempotente ed eventualmente consistente.
Fault Tolerance
La tolleranza ai guasti è la capacità di un sistema di continuare a operare, eventualmente in modalità degradata, nonostante il fallimento di alcuni dei suoi componenti. Nei microservizi si ottiene con pattern come timeout, retry, circuit breaker, bulkhead e fallback. L'obiettivo è contenere i guasti affinché un servizio in errore non faccia cadere l'intero sistema.
Idempotency
Un'operazione è idempotente se eseguirla più volte ha lo stesso effetto che eseguirla una volta sola. L'idempotenza è cruciale nei sistemi distribuiti perché i retry e la consegna at-least-once possono generare richieste duplicate. Si implementa comunemente con una chiave di idempotenza su cui il server deduplica, oppure progettando l'operazione in modo che sia naturalmente ripetibile.
Kubernetes
Kubernetes è una piattaforma open-source di orchestrazione di container che automatizza deployment, scaling e gestione delle applicazioni containerizzate su cluster. Espone API dichiarative per lo stato desiderato, come Deployment, Service e ConfigMap, e riconcilia di continuo lo stato reale verso quello desiderato. È la piattaforma più usata per eseguire microservizi in produzione.
Loose Coupling
L'accoppiamento lasco significa che i servizi hanno conoscenza e dipendenza minime degli interni l'uno dell'altro, interagendo solo attraverso contratti stabili. Permette di modificare, distribuire e scalare un servizio in modo indipendente senza forzare cambiamenti negli altri. Ottenere l'accoppiamento lasco è un obiettivo primario del design a microservizi ed è minato da database condivisi o da catene sincrone chiacchierone.
Message Broker
Un message broker è un middleware che riceve messaggi dai produttori e li consegna ai consumatori, disaccoppiando i due nel tempo e nello spazio. Supporta pattern come le code per la consegna point-to-point e i topic per il publish-subscribe, e spesso fornisce durabilità, garanzie di ordinamento e retry di consegna. Apache Kafka e RabbitMQ sono broker comuni nei sistemi a microservizi.
Microservice
Un microservizio è un servizio piccolo e distribuibile in modo indipendente, costruito attorno a una singola capacità di business e proprietario dei propri dati. I microservizi comunicano in rete tramite API o eventi ben definiti e possono essere sviluppati, distribuiti e scalati indipendentemente l'uno dall'altro. Lo stile baratta la semplicità di un monolite con autonomia e scalabilità, al prezzo della complessità dei sistemi distribuiti.
Modular Monolith
Un monolite modulare è una singola applicazione distribuibile organizzata in moduli ben definiti e debolmente accoppiati, con confini interni espliciti. Cattura buona parte del beneficio di manutenibilità dei microservizi senza il costo operativo di un sistema distribuito. È spesso il punto di partenza raccomandato e l'unità più sicura da cui estrarre servizi in seguito.
Observability
L'osservabilità è il grado in cui lo stato interno di un sistema può essere inferito dai suoi output esterni, tipicamente log, metriche e tracce, i tre pilastri. In un sistema a microservizi, dove una richiesta attraversa molti servizi, una forte osservabilità è essenziale per comprenderne il comportamento e diagnosticare i problemi. Va oltre il monitoring perché abilita l'esplorazione di domande non previste.
Orchestration
L'orchestration coordina un flusso distribuito tramite un componente centrale che invoca esplicitamente ogni passo e ne gestisce l'esito. Rende il processo complessivo facile da vedere e da modificare in un solo punto, al prezzo che l'orchestratore diventi un punto di accoppiamento e un potenziale collo di bottiglia. Si contrappone alla choreography, dove il coordinamento emerge dai servizi che reagiscono agli eventi.
Outbox Pattern
Il pattern transactional outbox pubblica eventi in modo affidabile scrivendoli, nella stessa transazione locale del cambiamento di stato di business, in una tabella outbox. Un processo separato legge poi l'outbox e pubblica gli eventi sul broker, garantendo che un evento sia pubblicato se e solo se il cambiamento di stato è stato committato. Risolve il problema della doppia scrittura tra database e message broker.
Polyglot Persistence
La persistenza poliglotta è la pratica di usare tecnologie di storage diverse per servizi o carichi diversi, scegliendo ciascuno store in base ai suoi dati e pattern di accesso. Un servizio può usare un database relazionale, un altro un document store e un altro ancora un indice di ricerca. È abilitata dal principio database-per-service e aumenta la diversità operativa.
Resilience
La resilienza è la capacità di un sistema di assorbire i guasti e riprendersi dalle interruzioni continuando a fornire un servizio accettabile. Nei microservizi viene progettata deliberatamente con timeout, retry con backoff, circuit breaker, bulkhead, rate limiting e degradazione controllata. Accetta che i fallimenti siano inevitabili nei sistemi distribuiti e li prevede.
Saga
Una saga è un pattern per gestire una transazione di business che attraversa più servizi, scomponendola in una sequenza di transazioni locali, ciascuna con un'azione compensativa per annullarla in caso di fallimento. Sostituisce l'impossibile transazione ACID distribuita con consistenza eventuale e compensazione esplicita. Le saga possono essere coordinate per choreography tramite eventi o per orchestration tramite un coordinatore centrale.
Service Discovery
La service discovery è il meccanismo con cui i servizi trovano le posizioni di rete delle istanze che devono chiamare, senza che tali posizioni siano hardcoded. Usa un registro presso cui le istanze si registrano e che i client interrogano, supportando scaling dinamico e turnover delle istanze. Può essere client-side, dove il client sceglie un'istanza, o server-side, dove lo fa un load balancer o la piattaforma.
Service Mesh
Un service mesh è uno strato infrastrutturale dedicato che gestisce la comunicazione servizio-servizio, tipicamente iniettando un proxy sidecar accanto a ciascuna istanza di servizio. Fornisce gestione del traffico, mutual TLS, retry, timeout e telemetria in modo trasparente, senza modificare il codice applicativo. Istio e Linkerd sono implementazioni note.
Service Registry
Un service registry è un database delle istanze di servizio disponibili e delle loro posizioni di rete, tenuto aggiornato man mano che le istanze partono, si fermano e falliscono gli health check. I client o i load balancer lo interrogano per effettuare la service discovery. Esempi includono Consul, etcd e il registro integrato in Kubernetes.
Sidecar
Un sidecar è un container di supporto distribuito accanto a un container applicativo principale nella stessa unità, come un pod Kubernetes, con cui condivide ciclo di vita e namespace di rete. Aggiunge capacità come proxy, logging o configurazione senza modificare l'applicazione. Il data plane del service mesh è l'uso più rilevante del pattern sidecar.
Strangler Fig Pattern
Il pattern strangler fig migra in modo incrementale un sistema legacy instradando funzionalità specifiche verso nuovi servizi mentre il vecchio sistema continua a girare, sostituendolo gradualmente finché non può essere dismesso. Evita un rischioso riscritto big-bang fornendo e validando valore in piccoli passi. Il nome deriva da una pianta che cresce attorno a un albero fino a soppiantarlo.
Synchronous Communication
La comunicazione sincrona è un'interazione richiesta-risposta in cui il chiamante si blocca e attende la risposta del chiamato, come in una tipica chiamata REST o gRPC. È semplice da comprendere ma accoppia disponibilità e latenza del chiamante a quelle del chiamato. Abusare di catene sincrone tra molti servizi crea grafi di chiamate fragili e soggetti alla latenza.
Asynchronous Communication
La comunicazione asincrona è un'interazione in cui il mittente non si blocca in attesa di una risposta immediata, di solito mediata da messaggi o eventi attraverso un broker. Disaccoppia i servizi nel tempo, migliora la resilienza e attenua i picchi di carico, al prezzo della consistenza eventuale e di un debug più difficile. È lo stile preferito per flussi tra servizi che non richiedono una risposta immediata.
Twelve-Factor App
La Twelve-Factor App è una metodologia di dodici principi per costruire servizi cloud-native e distribuibili, che coprono configurazione, dipendenze, statelessness, port binding, concorrenza e disposability. I microservizi la seguono comunemente, in particolare conservando la configurazione nell'ambiente e trattando i processi come stateless e usa-e-getta. Precede ma informa fortemente il design container-native.
Ubiquitous Language
Il linguaggio ubiquo è il vocabolario condiviso, usato in modo coerente da sviluppatori ed esperti di dominio, che nomina i concetti di un bounded context. Elimina la traduzione tra business e codice facendo coincidere il modello e la sua terminologia. Ogni bounded context, e quindi spesso ogni microservizio, ha il proprio linguaggio ubiquo.
Service-Level Objective (SLO)
Un service-level objective è un valore o intervallo obiettivo per un indicatore di livello di servizio, come il 99,9% di richieste con successo o una latenza p99 sotto i 300 ms su una finestra mobile. Gli SLO rendono l'affidabilità misurabile e guidano le decisioni se rilasciare funzionalità o investire in stabilità. Sono alla base degli error budget nella site reliability engineering.
Sticky Session
Una sticky session, o affinità di sessione, instrada tutte le richieste di un dato client verso la stessa istanza di servizio, di solito perché lì si trova lo stato di sessione in memoria. Confligge con la preferenza dei microservizi per istanze stateless scalabili orizzontalmente e complica scaling e failover. L'alternativa raccomandata è esternalizzare lo stato di sessione in uno store condiviso.
Database per Service
Il database-per-service è il principio per cui ogni microservizio possiede i propri dati in modo esclusivo e gli altri servizi non possono accedervi direttamente, ma solo tramite l'API del servizio proprietario. Impone l'accoppiamento lasco e permette a ciascun servizio di scegliere lo storage più adatto. Esclude l'integrazione tramite database condiviso e obbliga a soddisfare i bisogni di dati tra servizi con API, eventi o replica.
CQRS
Il Command Query Responsibility Segregation separa il modello usato per modificare lo stato (comandi) da quello usato per leggerlo (query), permettendo di ottimizzare e scalare ciascuno in modo indipendente. Nei microservizi si abbina spesso ad aggiornamenti event-driven che costruiscono read model denormalizzati. Aggiunge complessità ed è giustificato solo quando carichi di lettura e scrittura divergono in modo significativo.
Two-Phase Commit (2PC)
Il two-phase commit è un protocollo di commit atomico distribuito in cui un coordinatore chiede a tutti i partecipanti di prepararsi, poi ordina loro di committare o annullare. Fornisce consistenza forte ma si blocca se il coordinatore fallisce e scala male, perciò viene generalmente evitato tra microservizi a favore di saga e consistenza eventuale. Resta rilevante all'interno di una singola risorsa transazionale.
Health Check
Un health check è un endpoint o una probe che un servizio espone affinché orchestratori e load balancer possano determinare se è vivo e pronto a servire traffico. Un controllo di liveness rileva un processo bloccato che va riavviato, mentre un controllo di readiness rileva se l'istanza può accettare richieste in quel momento. Kubernetes usa queste probe per gestire instradamento e riavvii.
Blue-Green Deployment
Un blue-green deployment mantiene due ambienti di produzione identici, uno attivo e uno inattivo, distribuendo la nuova versione su quello inattivo e commutando il traffico una volta verificata. Abilita un rollback quasi istantaneo ricommutando il traffico. Richiede capacità doppia durante la commutazione e una gestione attenta delle modifiche di schema del database.
Canary Release
Una canary release rilascia una nuova versione a un piccolo sottoinsieme di traffico o utenti per prima, la monitora e aumenta gradualmente l'esposizione solo se le metriche restano sane. Limita il raggio d'azione di un rilascio difettoso e supporta il rollback automatico in caso di regressione. Dipende da una solida osservabilità e dalla capacità di instradare il traffico per percentuale.
gRPC
gRPC è un framework di chiamata a procedura remota ad alte prestazioni che usa HTTP/2 per il trasporto e Protocol Buffers per la definizione dell'interfaccia e la serializzazione binaria. Supporta chiamate unary e streaming e genera stub client e server fortemente tipizzati da uno schema condiviso. È una scelta comune per una comunicazione interna efficiente tra servizi quando entrambi i lati sono controllati.
Correlation ID
Un correlation ID è un identificatore univoco allegato a una richiesta quando entra nel sistema e propagato attraverso ogni chiamata a valle e ogni riga di log che essa produce. Permette agli operatori di ricucire tutta l'attività appartenente a una richiesta logica tra molti servizi. È il fondamento del tracing distribuito e del debug in un ambiente a microservizi.