Strategie per gestire un errore parziale

Per gestire gli errori parziali, usare una delle strategie descritte qui.

Usare la comunicazione asincrona, ad esempio la comunicazione basata su messaggi, tra microservizi interni. È consigliabile non creare lunghe catene di chiamate HTTP sincrone tra i microservizi interni perché tale progettazione non corretta diventerà alla fine la causa principale di interruzioni non corrette. Al contrario, ad eccezione delle comunicazioni front-end tra le applicazioni client e il primo livello di microservizi o gateway API con granularità fine, è consigliabile usare solo la comunicazione asincrona (basata su messaggi) dopo il ciclo di richiesta/risposta iniziale, nei microservizi interni. La coerenza finale e le architetture guidate dagli eventi contribuiranno a ridurre al minimo gli effetti di increspatura. Questi approcci applicano un livello più elevato di autonomia del microservizio e pertanto impediscono il problema indicato qui.

Utilizzare ritenti con backoff esponenziale. Questa tecnica consente di evitare errori brevi e intermittenti eseguendo tentativi di chiamata un determinato numero di volte, nel caso in cui il servizio non fosse disponibile solo per un breve periodo di tempo. Ciò può verificarsi a causa di problemi di rete intermittenti o quando un microservizio/contenitore viene spostato in un nodo diverso in un cluster. Tuttavia, se questi tentativi non sono progettati correttamente con interruttori automatici, possono aggravare gli effetti a catena, causando anche un Blocco del servizio (DoS).

Risolvere i timeout di rete. In generale, i client devono essere progettati per non bloccare indefinitamente e per utilizzare sempre i timeout quando sono in attesa di una risposta. L'uso dei timeout garantisce che le risorse non siano mai impegnate indefinitamente.

Usare il pattern Circuit Breaker. In questo approccio, il processo client tiene traccia del numero di richieste non riuscite. Se il tasso di errore supera un limite configurato, scatta un "interruttore" in modo che ulteriori tentativi non riescano immediatamente. Se un numero elevato di richieste ha esito negativo, segnala che il servizio non è disponibile e che l'invio di richieste è inutile. Dopo un periodo di timeout, il client deve riprovare e, se le nuove richieste hanno esito positivo, chiudere l'interruttore automatico.

Fornire fallback. In questo approccio, il processo client esegue la logica di fallback quando una richiesta ha esito negativo, ad esempio la restituzione di dati memorizzati nella cache o un valore predefinito. Si tratta di un approccio adatto per le query ed è più complesso per gli aggiornamenti o i comandi.

Limitare il numero di richieste in coda. I client devono inoltre imporre un limite superiore al numero di richieste in sospeso che un microservizio client può inviare a un determinato servizio. Se il limite è stato raggiunto, è probabilmente inutile effettuare richieste aggiuntive e questi tentativi dovrebbero avere esito negativo immediatamente. In termini di implementazione, è possibile usare la politica Polly Bulkhead Isolation per soddisfare questo requisito. Questo approccio è essenzialmente un controllo della parallelizzazione con SemaphoreSlim come realizzazione. Consente anche una "coda" al di fuori della paratia. È possibile liberare in modo proattivo il carico in eccesso anche prima dell'esecuzione, ad esempio perché la capacità viene considerata piena. Ciò rende più veloce la risposta a determinati scenari di errore rispetto a un interruttore, poiché l'interruttore attende gli errori. L'oggetto BulkheadPolicy in Polly espone quanto sono pieni la paratia e la coda, e offre eventi sull'overflow, quindi può essere utilizzato anche per pilotare la scalabilità orizzontale automatizzata.

Risorse aggiuntive

• Modelli di resilienza
  https://learn.microsoft.com/azure/architecture/framework/resiliency/reliability-patterns

• Aggiungere resilienza e ottimizzare le prestazioni
  https://learn.microsoft.com/previous-versions/msp-n-p/jj591574(v=pandp.10)

• Paratia. Repository GitHub. Implementazione con i criteri polly.
  https://github.com/App-vNext/Polly/wiki/Bulkhead

• Progettazione di applicazioni resilienti per Azure
  https://learn.microsoft.com/azure/architecture/framework/resiliency/app-design

• Gestione degli errori temporanei
  https://learn.microsoft.com/azure/architecture/best-practices/transient-faults