web-services - esempi - microservizi pdf



Architettura dei microservizi: condivisione dei dati cross-service (2)

Considera i seguenti micro servizi per un progetto di negozio online:
Il servizio utenti conserva i dati dell'account relativi agli utenti del negozio (tra cui nome, cognome, indirizzo email, ecc.)

Il servizio acquisti tiene traccia dei dettagli sugli acquisti dell'utente.

Ogni servizio fornisce un'interfaccia per la visualizzazione e la gestione delle relative entità. La pagina di indice del servizio acquisti elenca gli acquisti. Ogni articolo di acquisto dovrebbe avere i seguenti campi:
id, nome completo dell'acquirente, titolo dell'oggetto acquistato e prezzo.
Inoltre, come parte della pagina indice, mi piacerebbe avere una casella di ricerca per consentire al gestore del negozio di cercare acquisti acquistando il nome utente.

Non mi è chiaro come recuperare i dati che il Servizio acquisti non contiene, ad esempio: il nome completo dell'utente. Il problema peggiora quando si tenta di fare cose più complicate come acquisti di ricerca acquistando il nome utente.

Ho capito che posso ovviarmente ovviare a questo problema sincronizzando gli utenti tra i due servizi trasmettendo una sorta di evento sulla creazione dell'utente (e salvando solo le proprietà utente rilevanti sul Servizio acquisti). Questo è lontano dall'ideale nella mia prospettiva. Come gestisci questo quando hai milioni di utenti? creeresti milioni di record in ogni servizio che consuma i dati degli utenti?

Un'altra opzione ovvia è l'esposizione di un'API al servizio utenti che riporta i dettagli dell'utente in base a determinati ID. Ciò significa che ogni pagina caricata nel Servizio acquisti, dovrò effettuare una chiamata al Servizio utenti per ottenere i nomi utente corretti. Non ideale, ma posso conviverci.

Che ne pensi di implementare una ricerca di acquisto in base al nome utente? Bene, posso sempre esporre un altro endpoint dell'API al termine del servizio utenti che riceve il termine della query, eseguire una ricerca di testo su nomi utente nel servizio utenti e quindi restituire tutti i dettagli dell'utente che corrispondono ai criteri. Nel Servizio acquisti, associare gli ID pertinenti ai nomi corretti e mostrarli nella pagina. Anche questo approccio non è l'ideale.

Mi sto perdendo qualcosa? C'è un altro approccio per implementare quanto sopra? Forse il fatto che sto affrontando questo problema è una sorta di odore di codice? mi piacerebbe sentire altre soluzioni.


Answer #1

È assolutamente bene conservare i dati appropriati in diversi database, si chiama Polyglot Persistence . Sì, desideri conservare separatamente i dati degli utenti e i dati sugli acquisti e utilizzare la coda dei messaggi per la sincronizzazione. Milioni di utenti mi sembrano a posto, scalabilità, non problemi di progettazione ;-)

In caso di ricerca, probabilmente vuoi cercare più del solo nome utente, giusto? Pertanto, se si utilizza la coda messaggi per aggiornare i dati tra servizi, è anche possibile instradare facilmente questi dati su ElasticSearch, ad esempio. E dal punto di vista di ElasticSearch non importa quale campo indicizzare - nome utente o titolo del prodotto.


Answer #2

Di solito uso entrambi gli approcci. A volte ho un altro servizio che si trova in cima su x altri servizi e combina i dati. Non mi piace molto questo approccio perché causa dipendenza e accoppiamento tra i servizi. Quindi, in generale, nei miei ultimi progetti abbiamo cercato di attenerci alla persistenza poliglotta.

Inoltre, se hai bisogno di avere x richieste http per combinare i dati in una sorta di servizio middleware, questo ti porterà a una maggiore latenza. Cerchiamo sempre di ridurre la quantità di richieste per un'attività e gestire tutto ciò che è possibile attraverso le code asincrone. (in particolare sincronizzazione dei dati)