Miroservices valore predefinito per scenari di fallback

Question

Miroservices valore predefinito per scenari di fallback

#1 da (3 voti)

3

I valori predefiniti sono spesso suggeriti come parte del meccanismo di failover per i microservizi. A un livello elevato, per qualsiasi servizio (ad esempio microservizi qui) la natura dell'operazione può essere classificata in termini di lettura o scrittura.

Avere valori predefiniti per le operazioni di scrittura non sembra affidabile.
I valori di ritorno per le operazioni di lettura in termini di dimensioni dei dati possono (??) essere classificati come segue:
- Leggi i dati di ritorno di piccole / medie dimensioni
- Leggi restituendo una grande quantità di dati

Supponiamo che la fonte dei dati sia una cache altamente disponibile [utilizzata per prestazioni, evitamento round trip ecc. e che abbia il proprio ciclo di aggiornamento].

Ora, quando la cache è inattivo, il piano di failover può essere:

Quando la dimensione dei dati è piccola - Tornando al sistema attuale per recuperare i dati, (supponendo che il tempo impiegato sia compreso nell'intervallo milli sec) su un'invocazione in tempo reale, sembra ok.
Quando la dimensione dei dati è enorme e una chiamata in tempo reale richiede diversi minuti, eseguendo una chiamata sincrona, non sembra essere corretta.

Le soluzioni a cui posso pensare sono le seguenti:

Conserva i dati reali in una memoria persistente che è supportata dalla disponibilità elevata e la usa come riserva. Pertanto, la disponibilità dei dati sarà ora controllata dal criterio HA dello spazio di archiviazione persistente
Utilizza un tipo di memorizzazione nella cache per richiesta . La cache può avere un limite superiore fisso per dimensione e può essere utilizzata solo per mantenere la ultima richiesta. La cache può essere ripristinata periodicamente (con la stessa frequenza dell'aggiornamento della cache HA) dopo aver controllato lo stato della cache HA. Se la cache HA è disponibile, la cache di richiesta può essere ripristinata, altrimenti può conservare il suo ultimo stato. Ciò sostanzialmente sposta la sicurezza della disponibilità dei dati sulla piattaforma che ospita i microservizi (i)

Sarebbe davvero utile sapere dalla community, che tra i precedenti è meglio adattarsi OPPURE esiste un altro modo migliore per gestire il problema descritto in (2)?

microservices default-values

posta Divs 28.12.2017 - 07:37

fonte

1 risposta

Leggi altre domande sui tag microservices default-values

OOP in Java - A cosa servono i getters? Sostituzione di Liskov per vuoti e precondizioni indebolite

score 3 · Accepted Answer

Lo stai pensando troppo.

L'obiettivo di una cache distribuita è ottimizzare le prestazioni, nient'altro. Se ti aspetti che i dati sempre vengano memorizzati nella cache, il tuo design è difettoso. Potresti non avere i dati per una serie di motivi diversi (e molto più attuali) rispetto alla non disponibilità del servizio cache:

I dati non sono ancora stati memorizzati nella cache,
I dati sono diventati obsoleti e dovrebbero essere rigenerati,
Il servizio cache aveva poca memoria e rimosso l'elemento dalla cache.

Per questo motivo, devi considerare lo scenario dei dati che non si trovano nella cache comunque. Nel tuo caso, ciò significa che devi gestire esplicitamente il caso in cui una richiesta richiede minuti (eseguendola in modo asincrono).

L'unico problema aggiuntivo che si verifica quando il servizio cache è potenzialmente inattivo non vale più le lunghe richieste, ma molte brevi. Se si prevede di eseguire alcune centinaia di richieste (1 ms ciascuna) al secondo nella cache e la cache smette di rispondere, il che significa che ogni richiesta ora richiede 500 ms. (timeout), probabilmente esaurirai il pool di connessioni HTTP, senza contare le conseguenze sull'esperienza dei tuoi utenti. Per proteggersi da questo scenario, utilizzare il pattern circuit breaker dei microservizi.

Seguendo il tuo commento, sembra che siano necessarie ulteriori spiegazioni. Penso che una difficoltà con la tua domanda sia che stai parlando di quantità enormi di dati , supponendo che occorreranno pochi secondi o millisecondi per ottenere questi dati dalla cache, ma una questione di minuti per prendilo senza cache Se si tratta solo della dimensione dei dati, ci vorranno ancora minuti per ottenere i dati dalla cache.

Immaginiamo un altro scenario. La risposta è relativamente piccola e può essere scaricata in pochi millisecondi, ma impiega minuti a generare la risposta in primo luogo. Qui, la cache rappresenta un enorme miglioramento delle prestazioni.

In questo caso, il servizio potrebbe rispondere con un HTTP 202 accettato che indica che ha iniziato a generare la risposta, la risposta sarà disponibile più tardi. Significa in effetti che il client dovrà gestire due casi: quello in cui la risposta è pronta (HTTP 200) e quello in cui la risposta dovrebbe essere rigenerata (HTTP 202) e agire di conseguenza.

Lo storage persistente funziona come meccanismo di fallback? Sicuro. Personalmente preferirei non usarne uno, poiché rende l'intero sistema abbastanza complesso. Non appena si memorizzano i dati in due sistemi diversi (cache primaria e memorizzazione fallback), la manutenzione tende a diventare troppo costosa e si dovrà gestire correttamente l'invalidazione (ad esempio, cosa succede se la cache primaria viene invalidata, ma quando tentare di invalidare i dati nella memoria persistente, fallisce?) Inoltre, fino a che punto si potrebbe ottenere con quello? Non hai bisogno di gestire il caso in cui sia la cache che la memoria persistente sono vuote?

Secondo me, l'obiettivo dovrebbe essere:

Assicurati che il servizio cache sia affidabile. Se è giù una volta al giorno per un'ora, hai cose più importanti da fare che pensare alle strategie di fallback.
Garantisci che il caso in cui il servizio cache è inattivo (o vuoto) viene gestito, ovvero che l'utente vede qualcosa di diverso da "Errore server". A seconda del caso specifico, può essere semplice come un messaggio di errore esplicito e utile che spiega cosa è successo e cosa l'utente può fare dopo. Oppure potrebbe essere un meccanismo in cui l'utente dovrà attendere qualche minuto per ottenere la rigenerazione del contenuto. Oppure può essere un meccanismo di fallback molto complesso che garantisce un'affidabilità del 99,9999%. Spetta a te determinare se ne vale la pena.