In microservizio, si tratta di un singolo database o di una singola istanza di database per ciascun servizio?

Dipende veramente dai requisiti di scalabilità e da come / se le istanze di microservice devono collaborare per fornire un singolo risultato. Aiuta a capire quali sono i trade-off:

Mantieni tutto in un unico database

• Una configurazione più semplice
• Non sono necessari coordinamento o comunicazione con altre istanze del servizio
• Più facile scoprire il set di dati completo
• Prestazioni del sistema limitate dalle prestazioni del database

Mantenimento dei database separati

• La risposta completa per una richiesta può essere suddivisa tra istanze di microservizio
• In questo caso hai aumentato la comunicazione e la negoziazione per risolvere la richiesta
• Gestire i dati quando si perde il nodo del microservizio (anche quando il database è ancora attivo, non è possibile raggiungerlo finché non ne viene ripristinato uno nuovo con la configurazione corretta)
• Maggiore complessità di configurazione

Qual è il problema che stai risolvendo?

In alcuni casi, sei solo preoccupato per i dati effimeri. Se il database non funziona, non è un grosso problema. In quei casi potresti non aver nemmeno bisogno di un database per cominciare. Basta tenere tutto in memoria e rendere le cose incredibilmente veloci. Questa è la soluzione più semplice con cui lavorare.

In altri casi, è necessaria l'integrità dei dati, ma il database è in grado di espandere la capacità in base al numero di nodi che ha. In questo caso, un singolo database è probabilmente più che sufficiente e gestire la sua reattività in modo indipendente è la risposta giusta.

Ci sono un certo numero di casi nel mezzo. Ad esempio, potresti avere database che sono regionalmente specifici, quindi per ogni istanza del tuo servizio in una regione diversa hai un database separato. I database in genere non funzionano bene tra le regioni, quindi questo è un modo per localizzare i dati un po 'e controllare il coordinamento da soli.

Dottrina e realtà

Ho letto una serie di articoli sui microservizi e su come dovrebbero essere modulari. Le raccomandazioni vanno dal mantenere il front-end, il microservice e il livello dati dell'intera unità per condividere il database e / o il codice di front-end per tutte le istanze. Solitamente, un maggior isolamento offre la massima scalabilità, ma comporta un aumento della complessità.

Se il tuo microservizio è pesante in termini di calcolo, ha senso consentire il numero di tali microservizi in scala se necessario: la condivisione del database o persino del codice di front end non danneggia o ostacola questo approccio.

La realtà è che le esigenze specifiche del tuo progetto avranno bisogno di un diverso insieme di compromessi per portare a termine il lavoro in modo tempestivo e gestire il carico del sistema che stai misurando (più un po 'di più). Considerare l'obiettivo elevato il front-end, il microservizio e il trio di livello dati completamente isolati. Maggiore è la domanda sul tuo sistema, più vicino a quell'obiettivo che probabilmente dovrai essere. Non siamo tutti [insert name of highly successful web entity here] , e non hanno iniziato dove sono ora. A volte hai solo bisogno di iniziare con una situazione non perfetta, e sii felice con quello.

Supponendo che tu abbia alcuni servizi che possono utilizzare lo stesso tipo di sistema e versione DB, se si utilizzano database differenti o istanze db è una decisione che non dovrebbe essere necessaria in fase di progettazione. Invece, dovresti essere in grado di prendere una decisione al momento dell'implementazione, qualcosa che puoi semplicemente configurare. Progetta i tuoi servizi in modo da essere indipendenti dal luogo in cui sono ospitati i database di altri servizi.

Durante il funzionamento, è possibile iniziare con un'istanza e, se il sistema funziona correttamente, lasciarlo in questo modo. Tuttavia, se noti che questo non si adatta bene al tuo sistema, poiché diversi database su un'istanza condividono troppe risorse, hai sempre la possibilità di utilizzare diverse istanze, se questo aiuta.

Quindi un servizio non viola l'architettura dei microservizi solo perché consente a due di loro di condividere alcune risorse - la viola quando la condivisione della risorsa diventa obbligatoria.

Non importa.

L'unico scenario in cui potrebbe teoricamente importare è se un servizio deve migrare a versioni diverse del database. Ma anche in questo caso, non vi è alcuna reale differenza tra l'avere istanze separate dall'inizio rispetto alla migrazione di quel servizio da un'istanza condivisa a una separata. In realtà direi che avere istanze separate solo a causa di questo scenario è un esempio di YAGNI.

Un'istanza RDS è una singola casella. Se hai più database su una singola istanza, condividono la CPU / la memoria ecc.

Se le prestazioni del microservice sono limitate dalle prestazioni del database : quindi distribuendo più copie del microservice, ognuna utilizza un database diverso, ma con ciascun database sulla stessa istanza RDS. È inutile * (ad eccezione del failover). Il tuo microservice cluster funzionerà alla stessa velocità di un singolo microservizio

Tuttavia , direi che un microservizio associato alle prestazioni del database è inusuale.

Di solito il tuo microservice riceverà dati da un db, eseguirà una qualche logica e scriverà alcune informazioni nel database. Il collo di bottiglia delle prestazioni è la logica , non la selezione e / o l'inserimento.

In questo caso puoi semplicemente condividere lo stesso database su tutte le istanze di microservice

L'obiettivo di mantenere un database privato in un servizio è l'incapsulamento. Il tuo microservizio è una scatola nera che altri servizi nel sistema utilizzeranno tramite un'interfaccia pubblica.

Ci sono due piani su cui opera l'incapsulamento:

• Il primo è logico, a livello di applicazione. Il tuo servizio possiede alcuni oggetti business nel tuo sistema e ha bisogno di mantenere lo stato su questi oggetti. Che alcuni particolari database backs questi oggetti di business è solo dettagli di implementazione. Mantenendo un database separato, si impedisce ad altri servizi di avere accesso backdoor alla propria implementazione, costringendoli invece a utilizzare la propria interfaccia pubblica. L'obiettivo qui è un'architettura pulita e una programmazione disciplinata. Dove esattamente la vita del database è irrilevante a questo livello, purché il tuo servizio abbia i giusti dettagli di connessione in modo che possa trovarlo.

• Il secondo livello è operativo. Anche se il tuo disegno è una scatola nera perfetta, come fai notare, i diversi lavori posti in una singola macchina possono competere per le risorse. Questa è una buona ragione per mettere database logici separati su macchine separate. Come hanno notato altre risposte, se le vostre esigenze non sono molto impegnative e il vostro budget è limitato, questo è un argomento pragmatico per la colocation su una singola macchina. Tuttavia, come sempre, i compromessi: questa configurazione potrebbe richiedere più babysitting man mano che il sistema cresce. Se il budget lo consente, preferisco quasi sempre due piccole macchine separate per eseguire due attività rispetto alla condivisione di una macchina più grande.

Penso che potrebbe essere d'aiuto essere un po 'più teorico qui. Una delle idee motivanti alla base dei microservizi è condivisa: niente, processi di trasmissione dei messaggi. Un microservizio è come un attore nel modello di attore. Ciò significa che ogni processo mantiene il proprio stato locale e l'unico modo per un processo di accedere allo stato di un altro è l'invio di messaggi (e anche in questo caso l'altro processo può rispondere a piacimento a tali messaggi). Ciò che si intende per "ogni microservizio ha il proprio database" è in realtà che lo stato di un processo (cioè microservizio) è locale e privato . In larga misura, ciò suggerisce che il "database" dovrebbe essere collocato con il microservice, cioè il "database" deve essere memorizzato ed eseguito sullo stesso nodo logico del microservice. Diverse "istanze" del microservice sono processi separati e quindi ognuno dovrebbe avere il proprio "database".

Un database globale o un database condiviso tra microservizi o anche istanze di un microservizio costituirebbe, da questa prospettiva, uno stato condiviso. Il modo "appropriato" di gestire questo dal punto di vista dei microservizi è quello di avere il database condiviso mediato da un microservizio di "database". Altri microservizi che volevano sapere del contenuto del database invierebbero messaggi a quel "microservice di database". Questo in genere non eliminerà la necessità dello stato locale (vale a dire per i "database" di istanza di microservizio) per i microservizi originali! Ciò che cambia è ciò che rappresenta lo stato locale. Invece di memorizzare "Utente Sally è un amministratore", memorizzerebbe "Il database microservizio ha detto 'Utente Sally è un amministratore' cinque minuti fa". In altre parole, al di là di ogni stato che controlla completamente, memorizzerebbe le sue credenze sullo stato di altri microservizi.

Il vantaggio di questo è che ogni microservizio è autonomo. Ciò rende un microservizio un'unità di guasto atomico. Tu (soprattutto) non devi preoccuparti di un microservizio in uno stato parzialmente funzionale. Ovviamente, il problema è stato spostato nella rete di microservizi. Un microservizio potrebbe non riuscire a svolgere la funzione desiderata a causa dell'impossibilità di contattare altri microservizi. Il vantaggio, tuttavia, è che il microservizio sarà in uno stato ben definito e potrebbe essere in grado di offrire un servizio degradato o limitato, ad es. lavorando su convinzioni antiquate. Il rovescio della medaglia è che è molto difficile ottenere un'istantanea coerente del sistema nel suo complesso, e ci può essere un bel po 'di (indesiderata) ridondanza e duplicazione.

Ovviamente, il suggerimento non è di incollare un'istanza di Oracle in ogni contenitore Docker. Innanzitutto, non tutti i microservizi richiedono un "database". Alcuni processi non richiedono che lo stato persistente funzioni correttamente. Ad esempio, un microservizio che si traduce tra due protocolli non ha necessariamente bisogno di uno stato persistente. Perché quando lo stato persistente è necessario, la parola "database" è solo una parola per "stato persistente". Può essere un file con JSON in esso o un database Sqlite o una copia locale in esecuzione di Oracle se si desidera o qualsiasi altro mezzo di localmente che memorizzi in modo persistente i dati. Se il "database" non è locale, quindi da un punto di vista microservizi puro, dovrebbe essere trattato come un servizio (micro) separato. A tal fine, non ha mai senso avere un'istanza RDS come "database" per un microservizio. Di nuovo, la prospettiva non è "un mucchio di microservizi con i propri database RDS" ma "una serie di microservizi che comunicano con database RDS". A questo punto non fa differenza se i dati sono memorizzati nella stessa istanza di database o meno.

Pragmaticamente, un'architettura di microservizi aggiunge una enorme quantità di complessità. Questa complessità è solo il prezzo di affrontare seriamente il fallimento parziale. Per molti, è eccessivo che forse non ne vale la pena. Dovresti sentirti libero di progettare il tuo sistema in qualsiasi modo ti sembra più vantaggioso. C'è una buona possibilità che le preoccupazioni riguardo alla semplicità e all'efficienza possano portare a deviazioni da un'architettura di microservizi pura. Il costo sarà un ulteriore accoppiamento che introduce le proprie complessità come le interazioni invisibili tra i servizi e le restrizioni sulla libertà di distribuzione e ridimensionamento a piacimento.