Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Suggerimento
Questo contenuto è un estratto dell'eBook, Architettura di microservizi .NET per applicazioni .NET containerizzati, disponibile in documentazione .NET o come PDF scaricabile gratuitamente leggibile offline.
I microservizi e le applicazioni basate sul cloud devono far fronte agli errori parziali che si verificheranno sicuramente. È necessario progettare l'applicazione in modo che sia resiliente a tali errori parziali.
La resilienza è la capacità di recupero da errori che consente un funzionamento continuativo. Non si tratta di evitare errori, ma accettare il fatto che si verificheranno errori e rispondervi in modo da evitare tempi di inattività o perdita di dati. L'obiettivo della resilienza è restituire l'applicazione a uno stato completamente funzionante dopo un errore.
È abbastanza difficile progettare e distribuire un'applicazione basata su microservizi. Ma è anche necessario far funzionare l'applicazione in un ambiente in cui un qualche tipo di errore è certo. Pertanto, l'applicazione deve essere resiliente. Deve essere progettato per gestire errori parziali, ad esempio interruzioni di rete o nodi o macchine virtuali che si arrestino in modo anomalo nel cloud. Anche i microservizi (contenitori) spostati in un nodo diverso all'interno di un cluster possono causare errori brevi intermittenti all'interno dell'applicazione.
I numerosi singoli componenti della tua applicazione dovrebbero anche incorporare funzionalità di monitoraggio dello stato di salute. Seguendo le linee guida di questo capitolo, è possibile creare un'applicazione in grado di funzionare senza problemi nonostante tempi di inattività temporanei o i normali interruzioni che si verificano in distribuzioni complesse e basate sul cloud.
Importante
eShopOnContainer usava la libreria Polly per implementare la resilienza usando client tipizzato fino alla versione 3.0.0. A partire dalla versione 3.0.0, la resilienza delle chiamate HTTP viene implementata usando una mesh Linkerd, che gestisce i tentativi in modo trasparente e configurabile all'interno di un cluster Kubernetes, senza dover gestire tali problemi nel codice.
La libreria Polly viene ancora usata per aggiungere resilienza alle connessioni di database, specialmente durante l'avvio dei servizi.
Avvertimento
Tutti gli esempi di codice e le immagini in questa sezione sono validi prima di usare Linkerd e non vengono aggiornati per riflettere il codice effettivo corrente. Quindi hanno senso nel contesto di questa sezione.