Dati sui microservizi - coerenza finale - stato iniziale?

Question

Dati sui microservizi - coerenza finale - stato iniziale?

#1 da (0 voti)
#2 da (0 voti)

2

Supponiamo che tu abbia due microservizi (esempio forzato):

Servizio clienti
Servizio dashboard

Nel servizio clienti, gestisci tutti gli aspetti relativi ai clienti (indirizzo, preferenze, qualsiasi cosa). Nell'applicazione dashboard, c'è una mappa che vuoi mostrare mostrando tutti i nomi dei clienti e le loro posizioni. In altre parole, il servizio dashboard si prende cura di un sottoinsieme delle informazioni del cliente (vale a dire il nome del cliente e la posizione del cliente).

La mia comprensione è che si tratta di un anti-pattern per il servizio dashboard per comunicare in modo sincrono con il servizio clienti ogni volta che è necessario che i dati dei clienti mostrino la mappa. Quindi, invece, hai un archivio dati nel database del servizio dashboard con i clienti e la loro posizione. Quando un cliente viene aggiornato, viene attivato un evento di integrazione dal servizio clienti e tutti i sistemi downstream (ovvero il servizio dashboard) vengono aggiornati.

Sono per lo più corretto nella mia analisi qui o c'è un modo migliore per fare questo?
In che modo il servizio dashboard recupera i dati iniziali di tutte le località del cliente?

microservices

posta thebfactor 09.08.2018 - 17:39

fonte

2 risposte

Leggi altre domande sui tag microservices

ORM Strumenti e vantaggi dei riferimenti circolari nelle entità Visualizzazione delle chiamate del framework di entità in Sequence Diagram

score 0 · Answer 1

Quindi l'approccio asincrono sarebbe che il servizio clienti sollevasse un evento quando un cliente cambiava e che il servizio DashBoard ascoltasse quell'evento e aggiornasse la mappa di conseguenza al momento della ricezione.

Tuttavia. Si dovrebbe fare attenzione a non duplicare il database dei clienti. Nel tuo esempio hai effettivamente bisogno di tutti i clienti. Se si utilizza l'evento CustomerUpdated per creare una copia del db del cliente su ogni servizio che utilizza i dati del cliente, non è una buona cosa.

Interrogare il servizio clienti per queste informazioni (con memorizzazione nella cache appropriata) sarebbe probabilmente preferibile per replicare efficacemente il database del cliente tramite eventi.

Dire che la nostra mappa mostra la densità del cliente per codice postale. Quindi ha più senso usare l'approccio asincrono, poiché le informazioni aggregate derivano dalle informazioni del cliente ma non sono disponibili direttamente attraverso il servizio.

In entrambi i casi con un nuovo servizio avrete bisogno di una popolazione iniziale dei dati.

Le persone si preoccupano molto dei messaggi persi e rimangono sincronizzati, ma se hai un buon messaggio in coda puoi fare affidamento sul fatto che funziona.

score 0 · Answer 2

Hai ragione che i tuoi servizi non dovrebbero fare richieste sincrone per ottenere dati da altri servizi, ma non dovresti cercare di trovare un modo alternativo per ottenere i dati. Quello che dovresti fare è trovare un modo per evitare del tutto la query. Ciò significa che devi riconsiderare cosa fanno i tuoi servizi e quali dati possiedono.

Normalmente, quando hai servizi come CustomerService e, come dici tu, gestisce tutti gli aspetti di un cliente, puoi immediatamente dire che tutti gli altri servizi dovranno interrogare CustomerService ogni volta che hanno bisogno di qualcosa relativo a un cliente, quindi tu "Vieterò la regola" non fare richieste sincrone ad altri servizi "tutto il tempo.

Crea invece servizi basati su "Funzionalità aziendali", in modo che ogni servizio possieda tutti i dati e la logica necessari per adempiere al suo scopo. Ad esempio, è improbabile che tu abbia una funzione che richiede il nome del cliente e la posizione del cliente. Pertanto, si memorizzerà la posizione del cliente nel servizio che richiede la posizione e il nome nel servizio che richiede il nome. Questo dovrebbe rimuovere la maggior parte delle esigenze di interrogazione dei dati da un servizio all'altro.

Essere più specifici per il tuo scenario: Avrai un servizio che memorizzerà UserId e UserName e un altro che memorizzerà UserId e UserLoation. Quando si visualizza la dashboard, è possibile chiamare il servizio che possiede la posizione dell'utente e ottenere tutti gli ID utente che si trovano all'interno del poligono geografico che si desidera visualizzare. Una volta che hai questi Id, puoi chiamare l'altro servizio per ottenere i Nomi Utente. Questa seconda chiamata per ottenere i nomi può essere effettuata dal client o da un livello API, che non conterrà alcuna logica aziendale, saprà solo come chiamare i servizi per ottenere i dati da restituire al client. Pertanto, è possibile ottenere dati da più servizi, ma i servizi non si chiameranno a vicenda.