Dovrei avere una singola istanza Microservice quando ci sono diverse versioni dello stesso database

Question

Dovrei avere una singola istanza Microservice quando ci sono diverse versioni dello stesso database

#1 da (2 voti)

3

Abbiamo 25 istanze dello stesso database che facilitano diversi impianti di produzione nella nostra organizzazione. Fondamentalmente, la posizione X usa la propria copia del database, la posizione Y usa la propria copia, ecc. Il database facilita la stessa funzionalità e persiste lo stesso tipo di dati per ogni posizione, quindi un microservizio che si posizionerebbe sopra un'istanza di database farebbe la stessa cosa del microservice su un'istanza diversa.

Alla fine, aggregeremo tutte queste informazioni in un data warehouse globale.

La mia domanda è, dovremmo avere un'istanza del microservizio per database e instradare al microservizio corretto tramite un altro servizio di routing, o se i nostri clienti includono solo informazioni su quale database desiderano utilizzare nelle intestazioni delle richieste a un un singolo microservizio in grado di gestire internamente il routing del database?

Il vantaggio di utilizzare un singolo servizio che gestisce il routing internamente è che invece di 25 istanze potremmo avere un paio di istanze (per gestire il carico). Anche se, non sono del tutto sicuro che avere un paio di servizi con bilanciamento del carico sia davvero un vantaggio.

Questo sarà un microservizio basato su REST.

Infine, se esiste un'alternativa migliore a queste due scelte e sembra che rientrino nell'ambito della domanda menzionare l'alternativa, per favore fallo. Queste due scelte sono i paradigmi che sto considerando al momento.

database rest microservices soa routing

posta Carson 10.10.2016 - 20:37

fonte

1 risposta

Leggi altre domande sui tag database rest microservices soa routing

Qualcuno ha tentato di creare un sistema che utilizza le funzionalità di stile e in Javascript? L'accoppiamento di un'interfaccia gonfia con un Enum è una buona idea?

score 2 · Accepted Answer

Direi, dipende: ci sono più fattori che possono guidare la decisione in una direzione o nell'altra:

Operare (ad esempio hosting, monitoraggio) e mantenere (ad esempio aggiustare, aggiornare) più istanze dello stesso servizio significa più costi (ad es. hardware) e più lavoro (lavoro manuale o implementazione dell'automazione).

Tieni presente che l'automazione di solito è una buona cosa, anche se hai solo una o più istanze.
Se è necessario aggiornare il servizio e questo aggiornamento richiede una nuova colonna in una tabella, è possibile eseguire tutto contemporaneamente in tutti i database? Puoi aggiornare tutti i tuoi clienti contemporaneamente?
Disponi di SLA diversi o intervalli di manutenzione per istanza (ad esempio a causa dei fusi orari)?
L'affidabilità può aumentare quando si hanno più istanze: se un servizio non funziona (ad esempio a causa di richieste di carico o non valide), almeno gli altri servizi non dovrebbero essere interessati.
Se il client di ogni istanza di servizio è distribuito localmente (ad esempio città diverse) può essere opportuno posizionare ciascun database con il proprio servizio nella posizione dei client. Pertanto, anche se la rete interurbana (ad esempio la connessione Internet) non funziona, il cliente può lavorare autonomamente con il suo servizio.
Da un punto di vista architettonico (come hai già detto nella tua domanda):

Sposta il routing dal servizio ( tutti i client vanno a un servizio singolo e questo servizio deve conoscere il database giusto per ogni richiesta ) al client ( ogni client deve sapere a quale servizio andare, ma quel servizio parla sempre allo stesso database ).

Se si dispone di una relazione "statica" 1: n tra database e client (ad esempio, un cliente specifico parla sempre con lo stesso database), tenderei alla soluzione "un servizio per database".
Quando si hanno più istanze del servizio, la ricerca di errori viene spesso moltiplicata su tutte queste istanze (ad esempio lievi differenze di configurazione tra istanze) ma d'altra parte può essere più localizzata (ad es. cercare solo un piccolo file di registro invece di un gigante).

Questi sono solo alcuni fattori da considerare (in nessun ordine particolare) e probabilmente ce ne sono altri.

Solo dai punti sopra il mio sommario sarebbe: Se hai bisogno di almeno una parte della flessibilità e puoi permetterti il costo, vai per "un servizio per database". Ma, come sempre, dipende.