Ho letto di microservizi e mi sembra illogico creare un DB separato per servizio solo per raggiungere l'isolamento. Posso ottenere lo stesso utilizzando solo i servizi Web e un singolo database. Perché ne abbiamo addirittura bisogno? La cosa che separa il database è fuori discussione. O ho torto? Puoi guidarmi su questo?
Why do we even need it?
Non lo fai.
La creazione di un database separato per ciascun servizio aiuta a far rispettare i limiti del dominio, ma è solo un approccio. Non c'è nulla che ti impedisca di condividere tutti i tuoi servizi con lo stesso database.
Finché i tuoi servizi si comportano e non fanno cose inaspettate ai dati di proprietà di altri servizi, starai bene.
Non so cosa leggi, ma dovresti sapere che ci sono molte opinioni diverse sull'architettura dei microservizi. Ecco un buon post sul blog sull'argomento.
I’ve seen folks refer to this idea in part, trivially, as “each microservice should own and control its own database and no two services should share a database.” The idea is sound: don’t share a single database across services because then you run into conflicts like competing read/write patterns, data-model conflicts, coordination challenges, etc.
But a single database does afford us a lot of safeties and conveniences: ACID transactions, single place to look, well understood (kinda?), one place to manage, etc.
The journey to microservices is just that: a journey. It will be different for each company. There are no hard and fast rules, only tradeoffs.
Come risponde Dan Wilson, non ne hai davvero bisogno. I microservizi sono la cosa nuova e, come tutte le novità, le persone li usano in molti luoghi anche quando non forniscono molto valore.
I microservizi consentono di distribuire e ridimensionare le cose in modo indipendente a un livello "micro". Questa granularità offre una serie di vantaggi tecnici e ancor più vantaggi non tecnici poiché consente di separare meglio i team di sviluppo, rilasciare se necessario piuttosto che un'unica release, provare nuove tecnologie o processi in isolamento, ecc. Avere un DB condiviso uccide molto di questo a causa della dipendenza dal DB. Se non puoi implementare il tuo servizio senza preoccuparti dei dati di altri servizi, hai perso.
The thing that separate database is beyond discussion. Or I am plain wrong?
Detto questo, hai anche torto.
Quando lavori nel cloud, i database sono economici. Di solito libero! Certo, il server costa, ma non parliamo di un singolo server per microservizio (almeno, non all'inizio). Un singolo server con una serie di database (logici) va benissimo fintanto che si è diligenti nell'evitare le query tra database (che introducono dipendenze che danneggiano "indipendentemente distribuibili e scalabili"). Inferno, le query incrociate su DB sono impossibili in alcuni servizi di database cloud come Azure SQL. Non hai nemmeno bisogno di essere diligente lì ...
E ho persino visto i microservizi su cui hanno condiviso un database, ma ogni servizio ha il proprio schema. Ancora una volta, è necessario essere diligenti per evitare query che attraversano i confini dei dati.
Molti luoghi non sono così diligenti. Hanno degli sviluppatori entry level o persone che non apprezzano l'approccio dei microservizi, o hanno indecisi lead di team, o hanno una pressione temporale che induce le persone a prendere scorciatoie.
Avere un database separato è il modo più pulito per applicare quel disaccoppiamento che consente l'indipendenza dal servizio, ma non è l'unico modo. E non è che costoso, specialmente quando lo si confronta con il tempo / lo stipendio spesi cercando di applicare i limiti dei dati in un database condiviso.
Dipende da ciò che consideri "costoso".
Un database non deve necessariamente essere un costoso server di database commerciale (si pensi a Oracle), non deve necessariamente essere un affare affamato di risorse. A seconda di quali sono i requisiti, è possibile utilizzare il database SQLite o persino il file system come archivio dati persistente.
Tutti questi servizi potrebbero anche condividere una singola istanza / server di database e avere solo schemi isolati per servizio.
L'argomento chiave qui è che il servizio deve possedere e controllare i suoi dati. Come si ottiene ciò, è una questione di scelta e dettagli tecnici.
Il modo migliore in cui un servizio può possedere e controllare i suoi dati è avere un proprio database "personale". Ciò consente una completa libertà di scelta della tecnologia e dell'evoluzione dello schema di dati. L'unico modo in cui qualsiasi altro servizio può accedere ai dati di proprietà di un servizio è richiedendo i dati da un servizio. In questo modo, se la rappresentazione dei dati interni deve essere modificata, può essere facilmente modificata e nessun altro servizio si interromperà.
Quindi, per ricapitolare. Non è necessariamente costoso avere un database per servizio, né è necessario. È semplicemente una decisione che devi prendere ad un certo punto nello sviluppo dei microservizi. Ciascuna delle scelte ha le sue implicazioni e limitazioni. Studia quelli e fai la tua scelta.
Why do we even need it?
L'enorme vantaggio dei microservizi - e più in gran parte, SOA - è l'alto livello di astrazione degli interni: non solo l'implementazione, ma anche le tecnologie utilizzate. Ad esempio, se un sistema viene sviluppato in cinque microservizi da cinque team, un team può decidere di passare a uno stack tecnologico completamente diverso (ad esempio dallo stack Microsoft a LAMP) senza nemmeno chiedere ad altri team la propria opinione.
Guarda Amazon AWS o Twilio. Sai se i loro servizi sono implementati in Java o Ruby? Usano Oracle o PostgreSQL o Cassandra o MongoDB? Quante macchine usano? Ti importa anche di questo? in altre parole, sono quelle scelte tecnologiche che influenzano il modo in cui si utilizzano quei servizi? ... E ancora più importante, se si spostano in un altro database, dovresti cambiare la tua applicazione client di conseguenza?
Ora, cosa succede se due servizi utilizzano lo stesso database? Ecco una piccola parte dei problemi che possono sorgere:
Il team che sviluppa il servizio 1 desidera passare da SQL Server 2012 a SQL Server 2016. Tuttavia, il team 2 si basa su una funzionalità obsoleta rimossa in SQL Server 2016.
Il servizio 1 è un enorme successo. L'hosting del database su due macchine (master e failover) non è più un'opzione. Ma ridimensionare il cluster su più macchine richiede strategie come lo sharding. Nel frattempo, la squadra 2 è soddisfatta della scala attuale e non vede alcun motivo per passare a qualsiasi altra cosa.
Il servizio 1 dovrebbe passare a UTF-8 come codifica predefinita. Il servizio 2, tuttavia, è felice di utilizzare Code Page 1252 Windows Latin 1.
Il servizio 1 decide di aggiungere un utente con un nome specifico. Tuttavia, questo utente esiste già, creato pochi mesi fa dal secondo team.
Il servizio 1 ha bisogno di molte caratteristiche diverse. Service 2 è un componente estremamente critico e deve mantenere le funzionalità del database al minimo per ridurre il rischio di attacchi.
Il servizio 1 richiede 15 TB di spazio su disco; la velocità non è importante, quindi gli hard disk ordinari sono perfettamente a posto. Il servizio 2 richiede al massimo 50 GB, ma deve accedervi il più velocemente possibile, il che significa che i dati devono essere memorizzati su un SSD.
...
Ogni piccola scelta colpisce tutti. Ogni decisione deve essere presa in collaborazione, da persone di ogni squadra. I compromessi devono essere fatti. Confrontalo con una completa libertà per fare ciò che vuoi in un contesto SOA.
it's too [...] unmanageable.
Allora stai sbagliando. Suppongo che tu stia implementando manualmente .
Questo non è il modo in cui le cose dovrebbero essere fatte. È necessario automatizzare la distribuzione di macchine virtuali (o contenitori Docker) che eseguono il database. Una volta automatizzati, la distribuzione di due server o venti server o duemila server non è molto diversa.
La cosa magica dei database isolati è che è estremamente gestibile . Hai provato a gestire un enorme database utilizzato da dozzine di team? È un incubo. Ogni squadra ha richieste specifiche e non appena tocchi qualcosa, colpisce qualcuno. Con un database associato a un'app, l'ambito diventa molto ristretto, il che significa che ci sono molte meno cose a cui pensare.
Se un enorme database richiede amministratori di sistema specializzati, i database che sono utilizzati da un solo team possono essenzialmente essere gestiti da questo team (DevOps è anche a riguardo), liberando il tempo degli amministratori di sistema.
it's too costly
Definisci costo.
I costi di licenza dipendono dal database. Nell'era del cloud computing, sono abbastanza sicuro che tutti i principali attori hanno ridisegnato le loro licenze per adattarsi al contesto in cui invece di un enorme database ci sono molti piccoli. In caso contrario, si può prendere in considerazione il passaggio a un altro database. Tra l'altro, ci sono un sacco di open source.
Se parli di potenza di elaborazione, sia le macchine virtuali sia i contenitori sono ottimizzati per la CPU, e non sarei molto affermativo sul fatto che un enorme database consuma meno CPU di molti piccoli che fanno lo stesso lavoro.
Se il tuo problema è la memoria, allora le macchine virtuali non sono una buona scelta per te. I contenitori sono Sarete in grado di estendervi quante ne volete, sapendo che non consumeranno più RAM del necessario. Mentre il consumo totale di memoria sarà maggiore per molti piccoli database rispetto a uno grande singolo, suppongo che la differenza non sarà troppo importante. YMMV.
Leggi altre domande sui tag database architecture microservices web-services services