Instradamento di tutte le query SQL tramite un unico micro-servizio

Question

Instradamento di tutte le query SQL tramite un unico micro-servizio

#1 da (7 voti)

4

Al momento ho un sito Web, composto da circa 20 micro-servizi e una (ancora troppo grande) principale applicazione web monolitica. Il monolite e più micro servizi eseguono ogni query allo stesso database, ogni volta che devono gestire l'accesso al DB e la formattazione / esecuzione delle query.

Potrei passare i nostri database da SQL a NoSQL nel prossimo futuro; per aiutare questa transizione, così come ogni modifica futura che coinvolge il mio database, ho pensato di creare un micro-servizio che fungerà da punto di accesso al database. Gestirà la connessione ed eseguirà le query passate.

Quali sarebbero gli svantaggi di tale architettura?
Passare le query come stringhe è un'idea ragionevole, oppure dovrei creare una funzione wrapper all'interno del micro-servizio per ogni query che devo eseguire (come getThatThing () o updateThisItem ( ) )?
Il micro-servizio dovrebbe essere consapevole del tipo di risultati per le query, al fine di restituire un oggetto costruito con ORM?

database architecture microservices orm

posta Raphaël 19.02.2018 - 14:53

fonte

1 risposta

Leggi altre domande sui tag database architecture microservices orm

Verifica degli aggiornamenti del framework Le annotazioni migliorano le prestazioni in Java?

score 7 · Accepted Answer

What would be the drawbacks of such an architecture?

Punto singolo di errore.
Unire il microservizio a tutti gli altri, ostacolando le distribuzioni e il controllo delle versioni.
Il servizio di accesso ai DB sarà molto grande.

Is passing the queries as strings a reasonable idea, or should I create a wrapper function inside the micro-service for each query I have to run (like getThatThing() or updateThisItem())?

No. Passarli come stringhe probabilmente significa che non possono essere memorizzati nella cache dal server. anche significa che stai perdendo il tuo linguaggio di query per i tuoi consumatori. Se vuoi davvero spostare tutto su NoSQL, stai davvero intenzione di far sì che tutti i tuoi altri servizi correggano le loro query? Perché dovrebbero sapere / curarsi?

Should the micro-service be aware of the type of results for the queries, in order to return an object built with ORM?

Forse. Non vorrei che tutti i consumatori dovessero duplicare il codice per trasformare una tabella arbitraria in un oggetto. D'altra parte, non sono sicuro di voler accoppiare il servizio di accesso ai dati ai suoi consumatori ancora più difficile condividendo modelli di oggetti.

Un buon compromesso è forse limitare i tuoi dati in modo che possano adattarsi perfettamente a JSON, che i consumatori possono quindi deserializzare nei loro oggetti, mentre il servizio di accesso ai dati può funzionare solo con JSON.

Ma per la maggior parte degli scenari che posso immaginare, questa è solo una cattiva idea e dovresti evitarlo.