Micro-servizi e replica dei dati

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

Inizialmente, credevamo che i microservizi e un'architettura guidata dagli eventi ci abilitassero a noi per correggere il sottostante database di dati di fango condiviso.

Quello che abbiamo imparato è che i microservizi e un'architettura basata sugli eventi ci hanno richiesto per sbarazzarci del sottostante database di dati di fango condiviso.

Credo che i dati condivisi siano incredibilmente difficili da fare bene con i microservizi: per me è proibitivo. Raccomando di non consentire ai servizi di vedere i rispettivi dati. Se non puoi interrogarlo, non puoi introdurre accidentalmente una dipendenza.

Se fai condividi i dati, sicuramente solo un servizio può mai registrare un dato; è l'unico servizio che scrive sul record e qualsiasi altro utente con gli stessi dati deve avere accesso solo in lettura.

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

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

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

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

Ad esempio, potresti immaginare che un servizio di postal postal potrebbe aver bisogno di tenere traccia delle modifiche a un indirizzo del cliente, nel caso in cui debba pubblicare qualcosa. Ma se il messaggio "articolo pronto per la spedizione" include l'indirizzo di destinazione come parte dei dati del messaggio, il servizio di spedizione non deve più tenere traccia degli indirizzi di modifica relativi ai clienti; solo indirizzi point-in-time relativi agli articoli così come vengono spediti.

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

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

L'idea è che ogni volta che un servizio deve intraprendere un'azione importante, dovrebbe avere una copia delle informazioni aggiornate per agire correttamente, sia tracciato indipendentemente, sia come parte del messaggio che sta rispondendo a.

L'archiviazione dei dati condivisa 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 piuttosto che approfondire il servizio. I tuoi microservizi non sarebbero indipendenti se condividessero lo spazio di archiviazione comune e qualsiasi modifica al meccanismo di archiviazione, convalida o altri vincoli avrebbe dovuto essere implementata in entrambi i servizi. In pratica, ciò non accade mai e presto si impedisce ad entrambe le applicazioni di apportare modifiche seri.

Quindi, utilizza un servizio come unico modo per accedere ai tuoi dati, ad es. Account. Può accadere che l'implementazione di una funzione in altri servizi richieda una modifica al servizio Account, e questo è OK. Ricorda solo che la logica specifica per qualsiasi servizio dovrebbe essere in quel servizio e il minimo possibile di materiale specifico dovrebbe andare nel microservizio Account.

would need to have access to the same master data instances e.g. Accounts, Products

Non è la stessa cosa. Ogni micro servizio dovrebbe fare la propria mappatura per account, prodotti, ecc. Supponiamo che ogni 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 modo diverso.

Se hai bisogno di ulteriori informazioni, ti consiglio il libro Costruzione dei microservizi: Progettazione di sistemi a grana fine

Hai preso in considerazione il concetto di record di scheletro basato su un set principale?

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