Microservizi e archiviazione dei dati

Sto considerando di spostare un'API REST monolitica in un'architettura a microservizi e mi sto confondendo un po 'sull'archiviazione dei dati. A mio avviso, alcuni dei vantaggi dei microservizi sarebbero:

• Scalabile orizzontalmente: posso eseguire più copie ridondanti di un microservizio per far fronte al carico e / o al malfunzionamento di un server.
• Liberamente accoppiati: posso cambiare le implementazioni interne dei microservizi senza dover cambiare gli altri e posso implementarli e cambiarli in modo indipendente, ecc.

Il mio problema è con l'archiviazione dei dati. A mio avviso, ci sono diverse opzioni:

1. Un unico servizio di database condiviso da tutti i microservizi: ciò sembrerebbe eliminare completamente qualsiasi vantaggio derivante dall'accoppiamento libero.
2. Un'istanza di database installata localmente su ciascun microservizio: non riesco a vedere un modo per ridimensionare orizzontalmente questo, quindi non penso che sarebbe un'opzione.
3. Ogni microservizio ha il proprio servizio di database - questo sembra il più promettente, in quanto preserva i vantaggi dell'accoppiamento lento e del ridimensionamento orizzontale (usando copie di database ridondanti e / o sharding tra più)

Per me, la terza opzione sembra essere l'unica, ma mi sembra incredibilmente pesante e una soluzione molto ingegnosa. Se lo capisco bene, quindi per una semplice applicazione con 4-5 microservizi dovrei eseguire 16-20 server - due istanze effettive di microservizi per microservizio (in caso di guasto del server e per la distribuzione senza tempi di inattività), e due istanze del servizio di database per microservizio (in caso di errore del server ecc ...).

Questo, francamente, sembra leggermente ridicolo. 16-20 server per eseguire una semplice API, tenendo presente che un progetto realistico avrà probabilmente più di 4-5 servizi? C'è qualche concetto fondamentale che mi manca che spiegherà questo?

Alcune cose che possono essere utili durante la risposta:

• Sono l'unico sviluppatore di questo progetto e lo sarà per il prossimo futuro.
• Sto usando Node.js e MongoDB, ma sarei interessato a risposte indipendenti dalla lingua - una risposta potrebbe anche essere che sto usando solo le tecnologie sbagliate!

Delle tre opzioni, la prima (un singolo database condiviso) e la terza (un "servizio di database") sono le più comuni.

Il primo si chiama database di integrazione . Questo non è generalmente visto come una buona soluzione in un'architettura a microservizi. Aggiunge l'accoppiamento ai tuoi servizi. Inoltre, rende molto semplice per un servizio bypassare semplicemente gli altri servizi e interrogare direttamente un database. Potresti perdere qualsiasi tipo di integrità o convalida dei dati fornita dal livello dell'applicazione non applicata a livello di database.

La tua terza idea si chiama database dell'applicazione . E hai ragione: ti consente di applicare l'accoppiamento flessibile a livello di API tra i servizi e ti consente di ridimensionare più facilmente i servizi a livello di database. Inoltre, semplifica la sostituzione della tecnologia del database sottostante con qualcosa di appropriato per ciascun servizio, così come è possibile modificare la tecnologia o altri dettagli di implementazione di ciascun servizio. Molto flessibile.

Tuttavia, proporrei una soluzione intermedia.

Invece di creare un servizio di database per ogni microservizio, creare uno schema per ogni servizio. Se si utilizzano più tecnologie di database, potrebbe essere necessario suddividere in modo leggermente diverso, ma l'idea sarebbe quella di ridurre al minimo il numero di server di database in esecuzione, ma rendere molto semplice suddividere un servizio nel proprio server di database se e quando diventa necessario. Finché si consente a un database di accedere solo al proprio schema, si hanno i vantaggi di un database di applicazione, ma senza l'overhead dei server di database esistenti per ogni applicazione o servizio.

Tuttavia, come sviluppatore solista, sfiderei l'intera nozione di microservizi in questo momento - Martin Fowler scrive di Monolith First e Microservice Premium , Simon Brown parla di monoliti modulari e DHH parla di Majestic Monolith. Non sono sicuro di quanto bene sia organizzato il tuo monolito, ma rifattoriale e organizzarlo. Identifica i componenti e crea separazioni pulite tra loro per estrarre facilmente i pezzi in un servizio. Lo stesso vale per la struttura del database. Concentrati su un'architettura buona, pulita e basata su componenti in grado di supportare il refactoring nei servizi. I microservizi aggiungono molto sovraccarico a un singolo sviluppatore per la creazione e il supporto nelle operazioni. Tuttavia, una volta effettivamente necessario ridimensionare parte del sistema, utilizzare i sistemi di monitoraggio e reportistica per identificare i colli di bottiglia, estrarli in un servizio e ridimensionarli secondo necessità.

Ogni microservizio ha il proprio servizio di database - questo sembra il più promettente, in quanto preserva i vantaggi dell'accoppiamento lento e del ridimensionamento orizzontale (usando copie di database ridondanti e / o sharding tra più)

Essere d'accordo. La terza opzione è la scelta naturale per i micro servizi. Se si intende che il micro servizio sia realmente indipendente (e non parte di un monolito distribuito ), è normale che abbiano, ciascuno, un database.

[...] due istanze effettive del microservizio per microservizio (in caso di guasto del server e per la distribuzione senza tempi di inattività) e due istanze del servizio di database per microservizio (in caso di guasto del server ecc ...).

Hai ragione sulla quantità di micro servizi in esecuzione se desideri avere un bilanciamento del carico. Se si prevede di disporre di 4 micro-servizi, è necessario preparare almeno 2 istanze di ciascun micro-servizio (8 in totale), come già spiegato.

Ma due database per micro-servizio? Questo è davvero discutibile. Non conosco i dettagli sul problema aziendale a cui parteciperanno i tuoi micro servizi, ma avere una ridondanza del database è abbastanza per la maggior parte dei prodotti / progetti. Raccomanderò di iniziare con un singolo database con un buon backup e minimizzare (almeno inizialmente) la complessità della tua infrastruttura.

Questo, francamente, sembra leggermente ridicolo. 16-20 server per eseguire una semplice API, tenendo presente che un progetto realistico avrà probabilmente più di 4-5 servizi? C'è qualche concetto fondamentale che mi manca che spiegherà questo?

Per una semplice API questo numero non corrisponde. Fai attenzione se non stai cadendo in una delle trappole "Microservice First" .

I microservizi sono una forma di architettura orientata ai servizi, forse all'estremo. Il loro scopo generale è ridurre l'accoppiamento e consentire uno sviluppo e una distribuzione indipendenti.

In termini molto approssimativi in ​​termini architettonici, microservizi è un termine che si applica, diciamo, a livello logico. I microservizi sono logicamente separati l'uno dall'altro. Da questo punto di vista i microservizi dovrebbero possedere ciascuno e provvedere al proprio spazio di archiviazione, che dovrebbe essere disaccoppiato dall'archiviazione di altri microservizi. Per i microservizi, questa indipendenza di archiviazione è la chiave del loro obiettivo di modularità e accoppiamento libero.

Dal punto di vista architettonico, il ridimensionamento orizzontale si applica a un livello inferiore, più vicino all'implementazione, diciamo, a livello fisico. A questo livello, stiamo implementando un microservizio e possiamo scomporre questo singolo microservizio, internamente, in un componente stateless scalabile orizzontalmente e in un componente stateful condiviso da tutti i componenti stateless.  Ma non confondiamo solo la parte apolide da sola con il microservizio stesso.

Quindi, quando parliamo dei singoli microservizi, siamo a livello logico parlando di API e responsabilità separate e cicli di sviluppo / distribuzione separati. E quando parliamo di ridimensionamento orizzontale, siamo a livello fisico parlando dell'implementazione di un (singolo) microservizio e della sua decomposizione in componenti stateless e stateful.

Durante l'implementazione di più microservizi, abbiamo la possibilità di riutilizzare la tecnologia del database per i componenti con stato:

• database separato per microservizio
• database condiviso con:
  • schema separato / privato per microservizio
  • tabelle separate / private per microservizio

Vedi di più qui .

Un unico servizio di database condiviso da tutti i microservizi: ciò sembrerebbe eliminare completamente qualsiasi vantaggio derivante dall'accoppiamento libero.

D'accordo, se intendi condividere tabelle e colonne di tabelle, non si tratterebbe davvero di microservizi.

Se possiamo disaccoppiare - nei nostri processi di pensiero - la nozione logica di microservizi dalla nozione più fisica di componenti statali e apolidi di un microservizio, potremmo trovare più facile ottenere l'accoppiamento libero offerto dai microservizi, pur mantenendo l'efficienza di un condiviso banche dati.

Generalmente, c'è una buona dose di microservizi e persistenza con stato, vedi anche qui .

Bene, ho letto tutti i post di questo thread e posso dirti che sono confuso con la domanda: mescola microservice (MS) con servizi con servizio di accesso ai dati (servizio DB) con database e server ...

Se MS è un componente indipendente (distribuibile) che risolve un compito più semplice in modo apolide, di che database ha bisogno? Se un compito più complesso da risolvere, che richiede più di un sottoattività più semplice (SM?) Da risolvere insieme, è ancora un SM? In SOA, si chiama un servizio di orchestrazione. Implementa il "processo" e coordina l'invocazione della SM, quindi deve persistere nel suo stato (tutte le orchestrazioni / organizzatori / compositori / ecc. Sono stateful) e ha bisogno di un archivio dati personale: nessun altro può mitigare lo stato dell'orchestratore.

Tuttavia, non parliamo di database ma di MS Access / Database Access, e questa è una questione completamente diversa. Uno Stato membro potrebbe aver bisogno di alcuni dati raccolti nell'azienda (non nell'applicazione in cui opera) e non può chiedere a un altro Stato membro tramite la sua API / interfaccia i dati. Questo è lo scenario più comune e realistico. E un altro SM della stessa o diversa Applicazione potrebbe aver bisogno di questi dati o addirittura di modificarli. Sì, competono per i dati come sempre prima dell'emissione della SM.

Perché siamo in crash la "porta", che è ben nota e aperta? Qual è la differenza al riguardo tra una SM e un normale oggetto auto-persistente? Perché abbiamo bisogno di un database individuale per gli Stati membri se deve (ai fini della flessibilità e della componibilità) impegnarsi comunque nel suo servizio di accesso ai dati (DAS)? Non dimenticare che DAS protegge l'MS con un'attività aziendale dalla consapevolezza della connettività fisica al database. Questo accoppiamento lento e la flessibilità che gli Stati membri dovrebbero preservare per partecipare liberamente a più applicazioni senza ancorare il database.