Resilienza dei microservizi significa che un’applicazione assicura la capacità di recupero in caso di errore. Quando si parla di microservices architecture, è fondamentale considerare la capacità di resistenza ai guasti di ogni servizio distribuito.
Le categorie di interruzione dei servizi
Le applicazioni basate su microservizi hanno spesso diverse dipendenze, per esempio ai database, ai componenti di back-end o alle API, che possono potenzialmente causare guasti alle chiamate di servizio. Si parla allora di fault tolerance, suddivisi in due categorie:
- Guasti temporanei: in genere sono intermittenti e potrebbero far decadere l’applicazione per un breve periodo di tempo (in genere solo pochi secondi). Includono interruzioni temporanee della rete e richieste perse.
- Guasti permanenti: possono far cadere l’applicazione per lunghi periodi di tempo e derivano da servizi interrotti in modo critico e interruzioni permanenti.
Resilienza dei microservizi: tecniche e strategie
La premessa è che nella programmazione ideale è meglio evitare il più possibile le transazioni distribuite al fine di evitare problemi derivanti dalla loro complessità intrinseca.
Detto questo, esistono tre modelli comprovati di resilienza dei microservizi che aumentano la tolleranza agli errori e consentono alle applicazioni di gestire i guasti senza troppi problemi.
#1 Modello Riprova (retray)
I microservizi presuppongono molte interdipendenze. Una qualsiasi di queste può fallire in modo intermittente e, di conseguenza, creare a cascata numerosi guasti alle chiamate di servizio. Il modello Riprova fornisce una soluzione a questi errori temporanei.
In caso di guasti intermittenti e istantanei, questo tipo di approccio crea un meccanismo che esegue nuovamente un’operazione non riuscita per un determinato numero di volte. Gli amministratori IT configurano un numero specifico di tentativi, stabilendo determinati intervalli di tempo. Questa pratica fornisce ai servizi falliti la possibilità di richiamare i servizi una o più volte fino a quando non viene ricevuta la risposta prevista dal servizio, piuttosto che semplicemente arrestarsi in caso di errore iniziale.
L’importante è evitare di concatenare i tentativi, utilizzando il modello solo per i guasti temporanei. Ricordarsi anche di assegnare a ciascun servizio il tempo necessario per il ripristino, in modo da evitare l’effetto domino degli errori e preservare le risorse di rete mentre il servizio non ripristinato viene riattivato. Il tutto mantenendo aggiornati i registri per determinare in seguito la causa principale di questi errori.
#2 Modello interruttore (circuit breaker)
Mentre il modello per tentativi funziona per guasti transitori, i team adetti allo sviluppo hanno bisogno anche di un modello di resilienza dei microservizi affidabile che gestisca guasti permanenti o a lungo termine. Se un meccanismo di tentativi invoca accidentalmente un servizio gravemente danneggiato più volte fino a quando non ottiene il risultato desiderato, potrebbe causare errori di servizio a cascata che diventano sempre più difficili da identificare e correggere.
Il modello dell’interruttore automatico crea un componente concettualmente analogo a un interruttore elettrico tradizionale. Questo componente si trova tra i servizi richiedenti e gli endpoint dei servizi, deve essere asincrono e securitizzato rispetto ai thread. Finché i microservizi comunicano normalmente, l’interruttore delega i messaggi tra loro in uno stato chiuso.
Quando una richiesta di servizio non va a buon fine per un numero predeterminato di volte, entra in un circuito chiuso. La funzione dell’interruttore è di aprire il circuito del messaggio per interrompere l’esecuzione del servizio, restituendo un messaggio di errore per ogni transazione non riuscita.
Dopo un certo intervallo di tempo (noto come timeout di ripristino del circuito), l’interruttore entra in uno stato semiaperto. Durante questo periodo, le chiamate dell’interruttore chiudono il ciclo per verificare se la connettività tra i due servizi è stata ripristinata. Se l’interruttore rileva ancora un singolo errore, tornerà nuovamente allo stato aperto. Una volta risolto l’errore, richiude il ciclo normalmente.
Come sottolineano gli esperti, l’importante è progettare l’interruttore in modo tale da poter esaminare i guasti del servizio e quindi modificare le strategie di chiamata nel modo appropriato.
#3 Modello Identificatore di correlazione (correlation ID)
In una tipica applicazione basata su microservizi, l’ecosistema dei servizi si estende su sistemi diversi che possono essere separati tra loro anche da grandi distanze geografiche. Ciò significa che ogni servizio deve registrare dati utili e significativi che specificano cosa sta facendo e descrivono in dettaglio eventuali guasti. Ciò richiede un terzo modello di resilienza dei microservizi orientato al monitoraggio.
Un modello ID di correlazione crea un identificatore per ogni singola richiesta. Questo aiuta a tenere traccia del flusso completo di ogni richiesta HTTP attraverso tutti i canali di comunicazione. È possibile impostare l’ID di correlazione come parte dell’intestazione della richiesta HTTP e includerlo in ogni messaggio di registro, che consente di trovare rapidamente errori, avvisi e messaggi di debug pertinenti.
Mentre un ID di correlazione illustrerà il flusso di una richiesta dall’origine alla destinazione, un aggregatore di registri riunirà i registri da tutti i microservizi per facilitare la ricerca e l’analisi. I più diffusi strumenti di gestione dei registri includono:
- SolarWinds Security Event Manager
- Loggly
- Splunk
- Logstash
