Riprova il pattern Vs ripiega il pattern nel client di riposo

Question

Abbiamo diverse risorse esposte come servizio REST e in esecuzione per argomento di progettazione se il client deve implementare la logica di re-try se il servizio non è disponibile a causa di errori di livello di rete e/o di applicazione. Ne vale la pena? Un gruppo sostiene che se il servizio non è disponibile, non c'è motivo di riprovarci, ma altri gruppi sostengono che potrebbero esserci problemi di rete occupati e la re-try potrebbe aiutare. Non ci sono statistiche per difendere entrambi gli argomenti in questo momento. Che ne dici di implementare un URL di fallback (una replica della risorsa http originale) e utilizzare il servizio di fallback durante gli errori.

Qualche suggerimento basato sulla tua esperienza precedente?

Answer 1

Una cosa da tenere a mente è che se una richiesta di servizio non riesce, può essere causa di un sovraccarico di rete. In tal caso, l'opzione migliore è fallire immediatamente. Per quanto riguarda l'utilizzo di un URL di fallback, probabilmente non risolverà il problema, poiché potrebbe mantenere la rete sotto carico elevato.

suggerimento è quello di dare uno sguardo a modelli come:

• contropressione: http://mechanical-sympathy.blogspot.com.br/2012/05/apply-back-pressure-when-overloaded.html, interruttore http://engineering.voxer.com/2013/09/16/backpressure-in-nodejs/
• Circuito, eliminazione del carico: http://martinfowler.com/bliki/CircuitBreaker.html, http://techblog.netflix.com/2012/02/fault-tolerance-in-high-volume.html
• paratia modello: http://skife.org/architecture/fault-tolerance/2009/12/31/bulkheads.html

Answer 2

In generale, è consigliabile riprovare le richieste non riuscite. Imposta sempre un ragionevole limite di tentativi. È anche comune avere alcune risposte del server che segnalano al client di non riprovare, da utilizzare quando il server presenta problemi che non verranno risolti riprovando più tardi, come un errore del DB. Un ottimo modo per evitare di martellare un server con alto carico con richieste di nuovo tentativo è di utilizzare un backoff esponenziale, ad esempio il primo tentativo dopo 30 secondi, il successivo dopo 300 secondi, ecc.

Un URL di fallback sembra inarrestabile- dovrebbe essere un singolo endpoint per una risorsa. Non dovrebbe importare per il cliente se tale endpoint è supportato dallo stack primario o da un backup. In genere un dispatcher viene utilizzato per distribuire le richieste tra i server delle applicazioni in modo tale che se uno fallisce, può deviare il traffico verso gli altri fino a quando il problema non viene risolto.