Se un'architettura di microservizi necessita di un database separato per microservizio, è troppo costosa e ingestibile. Perché ne abbiamo bisogno?

Ho letto di microservizi e mi sembra illogico creare un DB separato per servizio solo per ottenere l'isolamento. Posso ottenere lo stesso utilizzando solo i servizi Web e un singolo database. Perché ne abbiamo bisogno? La cosa che separa il database è fuori discussione. O ho torto? Puoi guidarmi su questo?

Perché ne abbiamo bisogno?

Non

La creazione di un database separato per ciascun servizio aiuta a rafforzare i confini 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 con i dati di proprietà di altri servizi, starai bene.

Non so cosa leggi, ma dovresti essere consapevole che ci sono molte opinioni diverse sull'architettura dei microservizi. Ecco un buon post sul blog sull'argomento.

Ho visto gente riferirsi a questa idea in parte, banalmente, come "ogni microservizio dovrebbe possedere e controllare il proprio database e nessun servizio dovrebbe condividere un database". L'idea è valida: non condividere un singolo database tra i servizi perché si verificano conflitti come modelli di lettura / scrittura concorrenti, conflitti di modelli di dati, sfide di coordinamento, ecc.

Ma un singolo database ci offre molte sicurezze e comodità: transazioni ACID, un unico posto in cui cercare, ben compreso (un po '?), Un posto da gestire, ecc.

Il viaggio verso i microservizi è proprio questo: un viaggio . Sarà diverso per ogni azienda. Non ci sono regole rigide e veloci, solo compromessi.

La parte più difficile dei microservizi: i tuoi dati

Come risponde Dan Wilson, non ne hai davvero bisogno. I microservizi sono la nuova novità e, come tutte le novità, le persone li usano in molti luoghi anche quando non forniscono molto valore.

I microservizi ti consentono di distribuire e ridimensionare autonomamente le cose a livello "micro". Tale granularità offre un sacco di vantaggi tecnici e ancora più vantaggi non tecnici poiché ti consente di separare meglio i team di sviluppo, rilasciare secondo necessità piuttosto che una grande release, provare nuove tecnologie o processi in isolamento, ecc. Avere un DB condiviso uccide molto a causa della dipendenza dal DB. Se non riesci a distribuire il tuo servizio senza preoccuparti dei dati di altri servizi, hai perso.

La cosa che separa il database è fuori discussione. O ho torto?

Detto questo, hai anche torto.

Quando lavori nel cloud, i database sono economici. Di solito gratis! Certo, il server costa denaro, ma non stiamo parlando di un singolo server per microservizio (almeno, non all'inizio). Un singolo server con un sacco di database (logici) va bene purché tu sia diligente nell'evitare query tra database (che introducono dipendenze che danneggiano "indipendentemente distribuibile e scalabile"). In effetti, le query tra DB sono impossibili in alcuni servizi di database cloud come Azure SQL. Non hai nemmeno bisogno di essere diligente lì ...

E ho anche visto microservizi in cui condividevano un database, ma ogni servizio ha il suo schema. Ancora una volta, devi essere diligente nell'evitare query che attraversano i confini dei dati.

Molti posti non sono così diligenti. Hanno sviluppatori entry-level, o persone che non apprezzano l'approccio al microservizio, o che hanno scarse capacità di squadra o che hanno una pressione temporale che induce le persone a prendere scorciatoie.

Avere un database separato è il modo più pulito per imporre quel disaccoppiamento che consente l'indipendenza del servizio, ma non è l'unico modo. E non è poi così costoso, soprattutto quando lo si confronta con il tempo / stipendio impiegato nel tentativo di imporre limiti ai dati in un database condiviso.

Perché ne abbiamo bisogno?

L'enorme vantaggio dei microservizi - e più in gran parte, della SOA - è l'alto livello di astrazione degli interni - non solo l'implementazione, ma anche le tecnologie utilizzate. Ad esempio, se un sistema è sviluppato in una forma di 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, quelle scelte tecnologiche stanno influenzando il modo in cui usi quei servizi? ... E ancora più importante, se si spostano in un database diverso, dovresti cambiare di conseguenza la tua applicazione client?

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 affida a una funzionalità obsoleta che è stata rimossa in SQL Server 2016.

• Il servizio 1 è un enorme successo. Ospitare il database su due macchine (master e failover) non è più un'opzione. Ma il ridimensionamento del cluster su più macchine richiede strategie come lo sharding. Nel frattempo, il team 2 è soddisfatto dell'attuale scala e non vede alcun motivo per passare a qualcos'altro.

• Il servizio 1 dovrebbe passare a UTF-8 come codifica predefinita. Il servizio 2, tuttavia, è soddisfatto dell'uso della pagina codice 1252 Windows Latin 1.

• Il servizio 1 decide di aggiungere un utente con un nome specifico. Tuttavia, questo utente esiste già, creato alcuni mesi fa dal secondo team.

• Il servizio 1 richiede molte funzionalità diverse. Il servizio 2 è un componente estremamente critico e deve ridurre al minimo le funzionalità del database per ridurre il rischio di attacchi.

• Il servizio 1 richiede 15 TB di spazio su disco; la velocità non è importante, quindi i normali dischi rigidi vanno benissimo. Il servizio 2 richiede al massimo 50 GB, ma deve accedervi il più rapidamente possibile, il che significa che i dati devono essere archiviati su un SSD.

• ...

Ogni piccola scelta riguarda tutti. Ogni decisione deve essere presa in modo collaborativo, da persone di ogni squadra. I compromessi devono essere fatti. Confrontalo con una completa libertà di fare quello che vuoi in un contesto di SOA.

è troppo [...] ingestibile.

Allora stai sbagliando. Suppongo che stai distribuendo manualmente .

Non è così che dovrebbero essere fatte le cose. È 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, ciò influisce su 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 utilizzati da un solo team possono essenzialmente essere gestiti da questo team (DevOps è anche questo), liberando il tempo degli amministratori di sistema.

è troppo costoso

Definire il costo.

I costi di licenza dipendono dal database. Nell'era del cloud computing, sono abbastanza sicuro che tutti i principali attori hanno riprogettato le loro licenze per adattarsi al contesto in cui invece di un enorme database ce ne sono molti di piccole dimensioni. In caso contrario, è possibile passare a un altro database. A proposito, ce ne sono molti open source.

Se stai parlando di potenza di elaborazione, sia le macchine virtuali che i contenitori sono compatibili con la CPU e non sarei molto sicuro che un enorme database consumerà meno CPU rispetto a molti di quelli piccoli che fanno lo stesso lavoro.

Se il tuo problema è la memoria, le macchine virtuali non sono una buona scelta per te. I contenitori sono. Sarai in grado di estendere quanti ne vuoi, sapendo che non consumeranno più RAM del necessario. Mentre il consumo totale di memoria sarà maggiore per molti database di piccole dimensioni rispetto a uno grande, suppongo che la differenza non sarà troppo importante. YMMV.

Dipendendo da ciò che consideri "costoso".

Un database non deve necessariamente essere un costoso server di database commerciale (pensa Oracle), non deve necessariamente essere un affare affamato di risorse. A seconda delle esigenze, è possibile utilizzare il database SQLite o persino il file system come memoria 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 riesce a farlo, è una questione di scelta e dettagli tecnici.

Il modo migliore in cui un servizio può possedere e controllare i propri dati è disporre di un proprio database "personale". Ciò consente la completa libertà di scelta dell'evoluzione della tecnologia e dello schema dei dati. L'unico modo in cui qualsiasi altro servizio può accedere ai dati di proprietà di un servizio è chiedere i dati a un servizio. In questo modo, se è necessario modificare la rappresentazione interna dei dati, è possibile modificarla facilmente e nessun altro servizio verrà interrotto.

Quindi, per ricapitolare. Non è necessariamente costoso disporre di un database per servizio né è necessario. È semplicemente una decisione che devi prendere ad un certo punto durante lo sviluppo di microservizi. Ciascuna delle scelte ha le sue implicazioni e limitazioni. Studia quelli e fai la tua scelta.