Cache utente locale nei post microservizio

Question

Cache utente locale nei post microservizio

#1 da (1 voti)

4

Data la seguente architettura dei microservizi:

Ogni post ha un utente, per il quale vogliamo avere tutte le informazioni disponibili.
È più personalizzato per:

avere una cache utente locale nei post microservizio
Effettua chiamate api al servizio utente ad ogni richiesta
Memorizza le informazioni dell'utente insieme a ogni post

Non mi piace particolarmente l'ultima opzione quando si memorizza nel database; a causa della duplicazione, ma anche perché non aggiorna i dati dell'utente quando qualcosa cambia.

Che cosa ne pensi?

microservices

posta Trace 23.08.2018 - 01:31

fonte

1 risposta

Leggi altre domande sui tag microservices

Buoni esempi per l'insegnamento della stima del software (dimensioni, programma, sforzo)? [chiuso] Come impostare un job server ricorrente in un cluster Kubernetes

score 1 · Accepted Answer

Ci sono più opzioni

Invece di memorizzare tutti i dati relativi a un utente nell'oggetto post, memorizza solo le informazioni minime che puoi mostrare quando qualcuno passa sopra il nome utente. Se un utente fa clic sul nome utente, puoi fare una richiesta separata al servizio micro dell'utente per ottenere un oggetto utente dettagliato.
Se vuoi davvero tutte le informazioni dell'utente (e non ti piace l'opzione 1), mentre stai inviando n numero di post all'interfaccia utente (fai una query batch a Cassandra per ottenere tutti gli oggetti di n utenti) . Non sono sicuro che Cache abbia la capacità di trovare tutti gli oggetti per tutte le chiavi. (idealmente la cache dovrebbe avere questa capacità).
Simile a 2 ... Invece di chiamare microservice utente per ogni utente, è possibile sviluppare un endpoint api che può recuperare la risposta in blocco compresi i dati di più utenti

Non è ideale avere una cache utente nel post microservice, in futuro renderà la vita difficile assicurarsi che la cache utente nel servizio post micro sia sincronizzata con i dati del servizio micro dell'utente. La dipendenza incrociata non è una buona opzione. Se due squadre indipendenti ci stanno lavorando, non è l'ideale.