Microservizi senza duplicazione dei dati

Mi sono completamente perso dove ti viene richiesto di duplicare.

Un principio centrale dei micro servizi è che il servizio sia l'unica autorità. Ciò significa che l'inventario e la gestione degli utenti possono essere completamente separati. Disegnerei la gestione degli utenti in modo che non sappia nemmeno che esiste il sistema di inventario.

Ma progetterei il sistema di inventario in modo che non memorizzasse mai nulla sugli utenti diversi da un ID utente. Questo si prende cura del tuo problema di propagare le modifiche alle informazioni dell'utente.

Per quanto riguarda le cose che hanno bisogno sia di informazioni di inventario che di informazioni sugli utenti come registri, controlli e stampe, non vengono aggiornate come modifiche alle informazioni. Sono un record di ciò che era. Ancora una volta, non propagare il cambiamento.

Quindi in ogni caso, quando vuoi le ultime informazioni sull'utente, chiedi al servizio informazioni dell'utente.

a request would be made to the inventory service to retrieve the item details of all items where the quantity is less than 5. This would return a list including the user IDs. Then a separate request would be made to the users service to get the user name and contact details for the list of user IDs obtained from the inventory service.

Sì, sì.

È garantito che in un monolite si potrebbe avere un modello di inventario per cui si esegue una query per gli elementi pertinenti, che lo inseriscono in un modello utente e ottengano gli stessi dati.

Oppure potresti andare oltre, se li hai nello stesso database relazionale e scrivi SQL e il database prenderà la tabella delle scorte e la tabella degli utenti, fa un po 'di magia, e ottieni i dati che cerchi .

Indipendentemente da come lo fai, da qualche parte sarà un codice che essenzialmente recupera un elenco di ID utente dal sistema di inventario, li alimenta nel sistema dell'utente e compila un elenco di dati.

La domanda a cui devi rispondere riguarda le prestazioni e la manutenzione e altre qualità "morbide".

Il vantaggio principale dei microservizi è il ridimensionamento. se hai un diecimila utenti su una macchina ed è un po 'lento, puoi aggiungere un'altra macchina e il sistema diventa due volte più veloce. Aggiungi altri otto ed è dieci volte più veloce. (Il ridimensionamento lineare è probabilmente ottimistico, ma è l'ideale e non quello irragionevole da sperare.)

E questo è per servizio . Se il collo di bottiglia è il sistema di inventario, viene utilizzato per più di report sugli utenti, è possibile aggiungere più macchine a solo quel servizio . Le macchine possono anche essere specializzate; questo servizio ha bisogno di molta memoria, quel servizio fa calcoli pesanti e ha bisogno di più CPU

Se non hai bisogno del ridimensionamento, c'è un altro vantaggio dei microservizi: sono modulari . Ovviamente, le app monolitiche possono anche essere modulari, e hai un database normalizzato e ... ma in pratica i muri tra i moduli sono come le pareti di vetro nel migliore dei casi, e le linee nella sabbia nel peggiore dei casi. I microservizi sono separati da acciaio solido.

Se il tuo sistema utente prende letteralmente fuoco, questo non influirà minimamente sul tuo sistema di inventario. Non sarai in grado di stampare bei resoconti su chi ha rifornito cosa, ma i clienti saranno in grado di piazzare gli ordini sicuri sapendo che ci sono gli articoli disponibili.

E tu non duplichi i dati nei microservizi , più di quanto fai in un database relazionale. In un database relazionale puoi fare un join e l'equivalente è unire gli elenchi nel codice come descritto.

Potresti anche aggiungere una vista , l'equivalente è aggiungere un nuovo servizio che si fonda per te; ciò comporterebbe tre richieste; uno al nuovo servizio e poi quel servizio fa i due originali. I database relazionali hanno elementi di fantasia che ottimizzano le visualizzazioni, che devono essere implementate a livello di servizio. Non lo ottieni "gratuitamente".

I’m finding it hard to avoid data duplication....

Secondo Microsoft ebook sull'architettura dei microservizi , non c'è nulla di sbagliato nella duplicazione dei dati. Fondamentalmente, la duplicazione dei dati aumenta il disaccoppiamento tra i servizi e quindi rafforza i loro ruoli come un'unica autorità. Un passaggio rilevante:

And finally (and this is where most of the issues arise when building microservices), if your initial microservice needs data that's originally owned by other microservices, do not rely on making synchronous requests for that data. Instead, replicate or propagate that data (only the attributes you need) into the initial service's database by using eventual consistency (typically by using integration events...