Resilienza e disponibilità elevata nei microservizi

  • Articolo

Suggerimento

Questo contenuto è un estratto dell'eBook "Microservizi .NET: Architettura per le applicazioni .NET incluse in contenitori", disponibile in .NET Docs o come PDF scaricabile gratuitamente e da poter leggere offline.

Scarica PDF

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

Affrontare gli errori imprevisti è uno dei problemi più difficili da risolvere, specialmente in un sistema distribuito. Gran parte del codice scritto dagli sviluppatori comporta la gestione delle eccezioni, che è anche l'area che richiede più tempo per i test. Il problema è più complesso della scrittura di codice per gestire gli errori. Cosa accade infatti in caso di errore del computer in cui è in esecuzione il microservizio? Non è solo necessario rilevare l'errore del microservizio, un problema di per sé difficile, ma serve anche una soluzione per riavviarlo.

Un microservizio deve essere resiliente agli errori e capace di riavviarsi spesso in un altro computer per la disponibilità. Questo tipo di resilienza dipende anche dallo stato salvato per conto del microservizio, dalla posizione in cui il microservizio può recuperare questo stato e se il microservizio può essere riavviato senza problemi. In altre parole, deve esserci resilienza nella capacità di calcolo (il processo può essere riavviato in qualsiasi momento) e resilienza nello stato o nei dati (nessuna perdita di dati, che restano coerenti).

I problemi di resilienza si accumulano durante altri scenari, ad esempio quando si verificano errori durante l'aggiornamento dell'applicazione. Il microservizio, che collabora con il sistema di distribuzione, deve determinare se è possibile continuare a passare alla versione più recente oppure eseguire il rollback a una versione precedente per mantenere uno stato coerente. Occorre considerare alcune domande, ad esempio se sono disponibili computer sufficienti per continuare e come recuperare le versioni precedenti del microservizio. Questo approccio richiede che il microservizio debba generare informazioni sull'integrità, in modo che l'applicazione globale e l'agente di orchestrazione possano prendere queste decisioni.

In più, la resilienza dipende dal comportamento previsto per i sistemi basati sul cloud. Come accennato, un sistema basato sul cloud deve cogliere gli errori e provare a eseguire il recupero automatico. Ad esempio, in caso di errori di rete o di un contenitore, le applicazioni client o i servizi client devono prevedere una strategia per ritentare l'invio di messaggi o le richieste, perché in molti casi gli errori nel cloud sono parziali. La sezione Implementazione di applicazioni resilienti in questa guida affronta la gestione degli errori parziali, Descrive tecniche come i tentativi di chiamata con backoff esponenziale o lo schema Circuit Breaker in .NET usando raccolte come Polly, che offre una vasta gamma di criteri per la gestione di questo argomento.

Gestione di integrità e diagnostica nei microservizi

Potrebbe sembrare ovvio, ed è spesso trascurato, ma un microservizio deve segnalare la propria integrità e la diagnostica. In caso contrario, si avrà una quantità limitata di informazioni da un punto di vista operativo. Correlare gli eventi di diagnostica in un set di servizi indipendenti e gestire le differenze di orario dei computer per comprendere l'ordine degli eventi è difficile. Analogamente alla modalità di interazione con un microservizio su protocolli e formati di dati concordati, esiste la necessità di standardizzare la procedura di registrazione dell'integrità e degli eventi di diagnostica che alla fine terminano in un archivio eventi per l'esecuzione di query e la visualizzazione. In un approccio basato su microservizi, è fondamentale che i diversi team siano concordi sull'uso di un unico formato di registrazione. Deve esserci un approccio coerente alla visualizzazione di eventi di diagnostica nell'applicazione.

Controlli di integrità

L'integrità è diversa dalla diagnostica. Per integrità si intende la segnalazione dello stato corrente da parte del microservizio per consentire l'esecuzione di azioni appropriate. Un esempio efficace riguarda l'interazione con i meccanismi di aggiornamento e distribuzione per assicurare la disponibilità. Anche se, a causa di un arresto anomalo del processo o del riavvio del computer, un servizio potrebbe essere attualmente non integro, potrebbe comunque essere operativo. L'ultima cosa da fare è peggiorare la situazione eseguendo un aggiornamento. L'approccio migliore è procedere prima di tutto a un'indagine o attendere il ripristino del microservizio. Gli eventi di integrità di un microservizio consentono di prendere decisioni informate e favoriscono in effetti la creazione di servizi con funzionalità di riparazione automatica.

La sezione Implementazione dei controlli di integrità nei servizi ASP.NET Core di questa guida illustra come usare una nuova libreria HealthChecks di ASP.NET nei microservizi in modo da segnalarne lo stato a un servizio di monitoraggio e adottare le opportune misure.

È anche possibile usare AspNetCore.Diagnostics.HealthChecks, un'utilissima libreria open-source disponibile su GitHub e come pacchetto NuGet. Questa libreria esegue anche i controlli di integrità e gestisce due tipi di controlli:

  • Attività: controlla se il microservizio è attivo, vale a dire, se può accettare le richieste e rispondere.
  • Idoneità: controlla se anche le dipendenze del microservizio (database, servizi coda e così via) sono idonee, in modo che il microservizio possa eseguire le operazioni previste.

Uso della diagnostica e log dei flussi di eventi

I log contengono informazioni sulla modalità di esecuzione di un'applicazione o un servizio, tra cui eccezioni, avvisi e semplici messaggi informativi. In genere, ogni log è in un formato di testo con una riga per ogni evento, anche se le eccezioni spesso mostrano l'analisi dello stack su più righe.

Nelle applicazioni basate su server monolitiche, è possibile scrivere log in un file su disco (un file di registro) e quindi analizzarlo con qualsiasi strumento. Visto che l'esecuzione dell'applicazione è limitata a un server fisso o a una macchina virtuale, in genere non è troppo complesso analizzare il flusso di eventi. Tuttavia, in un'applicazione distribuita in cui più servizi vengono eseguiti tra molti nodi nel cluster di un agente di orchestrazione, riuscire a correlare gli eventi distribuiti è una vera e propria sfida.

Un'applicazione basata su microservizio non deve provare ad archiviare autonomamente il flusso di eventi di output o i file di registro né provare assolutamente a gestire il routing degli eventi in una posizione centrale. Dovrebbe essere trasparente, vale a dire che ogni processo deve solo scrivere il rispettivo flusso di eventi in un output standard che verrà raccolto dall'infrastruttura di ambiente di esecuzione sottostante in cui è in esecuzione. Un esempio di questi router del flusso di eventi è Microsoft.Diagnostic.EventFlow, che raccoglie i flussi di eventi da più origini e li pubblica nei sistemi di output. Questi possono includere semplice output standard per un ambiente di sviluppo o per sistemi cloud come Monitoraggio di Azure e Diagnostica di Azure. Ci sono anche ottimi strumenti e piattaforme di analisi dei log di terzi che possono cercare, avvisare, segnalare e monitorare i log, anche in tempo reale, come Splunk.

Agenti di orchestrazione che gestiscono le informazioni di integrità e diagnostica

Quando si crea un'applicazione basata su microservizio, è necessario risolvere la complessità. Naturalmente, un singolo microservizio è semplice da gestire, ma decine o centinaia di tipi e migliaia di istanze di microservizi rappresentano un problema complesso. Non si tratta solo di creare la propria architettura di microservizi: occorrono anche disponibilità elevata, indirizzabilità, resilienza, integrità e diagnostica se si vuole avere un sistema stabile e coesivo.

Diagram of clusters supplying a support platform for microservices.

Figura 4-22. Una piattaforma di microservizi è fondamentale per la gestione dell'integrità di un'applicazione

I problemi complessi illustrati nella figura 4-22 sono molto difficili da risolvere in autonomia. I team di sviluppo devono concentrarsi sulla risoluzione dei problemi aziendali e sulla creazione di applicazioni personalizzate con approcci basati sui microservizi, e non sulla risoluzione di complessi problemi dell'infrastruttura: se lo facessero, il costo di qualsiasi applicazione basata sui microservizi sarebbe enorme. Di conseguenza, esistono piattaforme orientate ai microservizi, definite agenti di orchestrazione o cluster di microservizi, che provano a risolvere i problemi insiti nella creazione e nell'esecuzione di un servizio, oltre che nell'uso efficiente delle risorse dell'infrastruttura. Questo approccio riduce le complessità correlate alle creazione di applicazioni che usano un approccio ai microservizi.

Diversi agenti di orchestrazione potrebbero sembrare simili, ma la diagnostica e i controlli di integrità offerti da ciascuno di essi differisce nelle funzionalità e nello stato di maturità, talvolta a seconda della piattaforma del sistema operativo, come illustrato nella prossima sezione.

Risorse aggiuntive

PrecedenteSuccessivo