Micro-servizi e replica dei dati

Sto costruendo una nuova applicazione e stavo leggendo sull'architettura dei micro-servizi. L'architettura stessa ha molto senso dal punto di vista dello sviluppo, della distribuzione e della gestione del ciclo di vita. Tuttavia, è emerso un problema relativo alla gestione dei dati anagrafici.

Ad esempio, ho 2 app: ad esempio app di vendita e un'app di ticketing. Supponiamo che entrambe queste app siano costruite come propri micro-servizi. Tuttavia, entrambe queste app, una volta distribuite (supponendo che siano distribuite separatamente, dicono che Sales utilizza MongoDB e Ticketing utilizza MariaDB), dovrebbero avere accesso alle stesse istanze di dati anagrafici, ad esempio Account, Prodotti. Ciò significherebbe che ci sarebbe un'app del proprietario per una determinata entità di dati anagrafici (ad es. Per gli account potrebbe essere l'app di vendita) e una parte interessata (ad es. L'app di ticketing dovrebbe avere informazioni sugli account).

Esistono diversi modi in cui ciò può essere ottenuto: - Replica dei dati da master a parte interessata - Lettura sincrona da parte interessata a master (la dipendenza dalla sincronizzazione non è consigliata dal paradigma dell'architettura dei micro-servizi) - Repository centralizzato proprio

Anche all'interno degli account, può esserci una parte fondamentale comune sia per le vendite che per i biglietti (ad es. Nome account, indirizzo ecc.). Tuttavia, alcuni aspetti del Conto potrebbero essere SOLO rilevanti per le Vendite e altri SOLO rilevanti per il Biglietto.

Qualche pensiero / best-practice / opinione su una delle opzioni sopra menzionate?

Facevo parte di un team che ha costruito con successo un'architettura di microservizi utilizzando un bus di servizio.

Inizialmente, credevamo che i microservizi e un'architettura guidata dagli eventi avrebbero funzionato ci consentito di correggere il database di palla di fango di dati condivisi sottostante.

Ciò che abbiamo imparato è stato che i microservizi e un'architettura guidata dagli eventi ci hanno richiesto di sbarazzarci del database di palla di fango di dati condivisi sottostante.

Credo che i dati condivisi siano incredibilmente difficili da fare bene con i microservizi - per me è proibitivamente difficile. Consiglio di non consentire i servizi a vedere i dati degli altri. Se non è possibile interrogarlo, non è possibile introdurre accidentalmente una dipendenza.

Se tu fai condividere i dati, certamente solo un servizio può mai avere un record; è l'unico servizio che scrive nel record e qualsiasi altro utente degli stessi dati dovrebbe avere accesso in sola lettura.

Sfortunatamente, anche questa piccola quantità gestita di condivisione introduce un accoppiamento significativo tra i tuoi servizi. E se un servizio non volesse i dati in quella forma? Forse vuole un'aggregazione. Ottieni il tuo servizio "proprietario / scrittura" per scrivere dati aggregati a beneficio di un altro servizio? Non lo consiglierei.

Cosa succede se il proprietario desidera mantenere i dati in una forma diversa? Quindi ogni servizio di lettura deve essere aggiornato. È un incubo per la manutenzione.

La migliore soluzione che abbiamo avuto è stata una significativa duplicazione e denormalizzazione dei nostri dati. I micro servizi hanno conservato le loro copie dei dati a cui tenevano.

I messaggi venivano spesso pubblicati con sufficienti dati di accompagnamento per elaborarli.

Ad esempio, potresti immaginare che un servizio di spedizione postale potrebbe dover tenere traccia delle modifiche a un indirizzo del cliente, nel caso in cui debba pubblicare qualcosa. Ma se il tuo messaggio "articolo pronto per la spedizione" include l'indirizzo di destinazione come parte dei dati del messaggio, allora il servizio di spedizione non ha più bisogno di tenere traccia degli indirizzi mutevoli relativi ai clienti; solo gli indirizzi temporali relativi agli articoli quando vengono spediti.

Non posso suggerire come progettare soluzioni con dati sincronizzati. Le nostre soluzioni di dati sono state costruite attorno all'idea di "eventuale coerenza".

Pertanto, quando un cliente aggiorna il proprio indirizzo, il servizio Indirizzo elabora il comando iniziale dall'interfaccia utente. Una volta che i suoi dati sono corretti, pubblica un evento per informare tutti gli altri servizi interessati "Indirizzo cliente aggiornato" - con l'indirizzo completo allegato come dati. Tali servizi aggiorneranno i propri archivi dati con le parti dei dati a cui tengono.

L'idea è che ogni volta che un servizio deve intraprendere un'azione importante, dovrebbe disporre di una copia delle informazioni sufficientemente aggiornata per agire correttamente, tracciata in modo indipendente o come parte del messaggio a cui sta rispondendo.

L'archiviazione dei dati condivisi andrebbe contro l'architettura dei microservizi. Il punto è che se ci sono Account, ci dovrebbe essere un servizio per gestirli e non ci dovrebbe essere altro modo di interagire con questi Account se non quello di approfondire il servizio. I microservizi non sarebbero indipendenti se condividessero l'archiviazione comune e fosse necessario implementare in entrambi i servizi eventuali modifiche al meccanismo di archiviazione, la convalida o altri vincoli. In pratica, ciò non accade mai e presto si impedisce a entrambe le applicazioni di apportare modifiche gravi.

Quindi, utilizza un servizio come unico modo di accedere ai tuoi dati, ad es. Account. Può accadere che l'implementazione di una funzione in qualche altro servizio richieda una modifica al servizio Account, e va bene. Ricorda solo che la logica specifica di qualsiasi servizio dovrebbe trovarsi in quel servizio e che il minor numero di elementi specifici possibile dovrebbe andare nel microservizio di Account.

dovrebbe avere accesso alle stesse istanze di dati anagrafici, ad es. Account, Prodotti

Non lo stesso. Ogni micro servizio dovrebbe eseguire la propria mappatura per account, prodotti, ecc. Supponiamo che ciascun micro servizio abbia un modo diverso di lavorare con le entità.

In Domain Driven Design questo è comune, in cui ogni contesto limitato (nella stessa app!) Può mappare la stessa entità in un modo diverso.

Se hai bisogno di ulteriori informazioni, ti consiglio il libro Building Microservices: Progettazione di sistemi a grana fine

Hai considerato il concetto di record di scheletro basato su un set master?

Ad esempio, un microservizio gestisce gli account e l'altro gestisce i prodotti. Un terzo può conservare i record di entrambi per il suo scopo specifico di dominio.