Perché è considerata una buona pratica isolare la gestione dei dati in un microservizio?

Un grande vantaggio dell'architettura di Microservices è che ogni servizio può essere sviluppato, testato e implementato in modo sicuro in modo indipendente. Avere servizi di condivisione di un database mina questo dato che consente modifiche sottili in un servizio per introdurre errori in altri servizi, ad es.

• Un servizio potrebbe iniziare a scrivere dati in un formato inatteso in colonne lette da un altro servizio
• I servizi potrebbero iniziare a bloccare i record in modo leggermente diverso, causando problemi di prestazioni o addirittura deadlock in altri servizi

A causa della difficoltà nell'assicurarsi che una determinata modifica non abbia un impatto su un altro utente di un database, la verifica delle modifiche diventa più complicata e le implementazioni di servizi "indipendenti" spesso vengono interconnesse (ad es. le modifiche devono essere implementate in ordini specifici altrimenti testati è invalidato). Inoltre, anche le modifiche dello schema diventano sostanzialmente più difficili in quanto è difficile identificare quali servizi potrebbero essere interessati da una determinata modifica.

Avere servizi di comunicazione utilizzando le API REST o code di messaggi aiuta a mantenere indipendenti i servizi poiché le suite di test automatizzate possono verificare più facilmente che le modifiche siano retrocompatibili e che i servizi possano apportare modifiche altrimenti senza influire su altri servizi, ad es. introducendo nuove versioni API / endpoint.

Supponete che il vostro software sia abbastanza grande da far funzionare numerosi team, in gran parte indipendenti. Puoi avere un database per tutti o un database per team.

Un database per tutti consente di utilizzare le funzionalità del database per le query, ma, soprattutto, è possibile fare affidamento sulla coerenza del database perché il database gestisce le transazioni. Quindi, se hai molte transazioni complicate, questa potrebbe essere la scelta migliore.

Un database per team si assicura che altri team non blocchino, sovrascrivano o addirittura distruggono i tuoi dati. Il team definisce le interfacce per accedere e modificare i dati e nessuno può venire da dietro e fare qualcosa nelle tue tabelle. D'altro canto, la coerenza è essenzialmente un problema irrisolto, poiché le transazioni che si eseguono su più database del team sono difficili da gestire.

A rischio di problemi di miscelazione. Se tutti i tuoi microservizi si connettono a un database, in sostanza hai appena creato un'applicazione monolitica più complessa con un singolo punto di errore. Sicuramente puoi sfruttare le operazioni del database quando tutto è sullo stesso server; ma se i contesti dei dati dei microservizi sono progettati con attenzione, la miscelazione di questi contesti in una query dovrebbe essere una richiesta ad hoc piuttosto che un normale utilizzo quotidiano.

Inoltre, è necessario pensare alla scalabilità, se si dispone di un numero limitato di microservizi che si possono ottenere facendo in modo che tutti guardino al server del database, ma quando si inizia a ridimensionare ciascun microservizio deve funzionare in modo indipendente l'uno dall'altro .

Se hai un servizio di tipo X e ne fai girare sei istanze. Ognuno potrebbe avere il proprio archivio dati; oppure si utilizzano contenitori docker per il servizio stesso e questo punto si riferisce a un archivio dati comune per servizi di tipo X.

Un sacco di schemi da esplorare

Se riesci a mettere tutti i tuoi dati in un unico database, allora nella mia mente non hai il tipo di problema che ha bisogno di microservizi. Rallegrati, questo risparmia molto lavoro!

I microservizi sono una soluzione per problemi su larga scala, quando non è possibile avere tutti i dati in un unico database e / o avere team diversi che lavorano su servizi diversi, o hanno altri motivi per dividere il software in parti distinte. Ciò rende sempre le cose più difficili a causa del genere di cose che hai citato, ma a un certo punto è un costo necessario.

Il problema con qualsiasi progetto modulare è che non è possibile avere moduli consapevoli dei dati di altri moduli al di fuori del severo contratto che i moduli espongono, perché si è obbligati a introdurre l'accoppiamento a livello di dati che non si volere. I moduli dovrebbero essere intercambiabili, ma non lo saranno se il modulo A dipende dalle strutture dati nel modulo B.

Ho visto un esempio esatto di ciò che hai menzionato. Un sistema modulare condivide il database tra diversi moduli. Vincoli e vincoli di chiave esterna collegano le tabelle dei diversi moduli insieme, ma se uno dei moduli deve essere modificato, l'accoppiamento a livello di database lo rende quasi impossibile. I moduli non possono essere disaccoppiati dal sistema facilmente e occorre svolgere un lavoro considerevole per riscrivere sostanzialmente entrambi i moduli, poiché entrambi dipendono dai rispettivi dati interni.