Database condiviso nell'architettura dei servizi di micros

Ok, quindi il classico problema con la configurazione è che le chiamate ad alto volume rallentano o interrompono le chiamate a basso volume. o nel tuo caso i Servizi rallentano gli utenti.

La soluzione è dividere il servizio in due come hai fatto. È quindi possibile ridimensionare o limitare il servizio senza influire sugli utenti

Come indicato, non è consigliabile condividere il codice tra i servizi. Immagino che ti sia rimasto da quando erano un servizio. E come dici tu, stanno entrambi usando lo stesso datalayer.

Ora c'è qualcosa di sbagliato. Ma non è tanto il codice condiviso quanto il fatto che stai ancora condividendo un database.

Essere sullo stesso db significa che le chiamate ad alto traffico possono ancora influenzare gli utenti. Se li avessi spostati, probabilmente non avresti più codice condiviso.

La condivisione di un codice di per sé potrebbe comportare delle difficoltà di manutenzione e dovresti cercare di effettuare il refactoring, se possibile. Ma non è la radice del problema.

Potresti scoprire che se il servizio ad alto volume riscontra dei limiti prestazionali dovuti alla CPU o alla memoria piuttosto che alle chiamate al database, hai già risolto i tuoi problemi suddividendo il servizio a livello di codice. In tal caso, la condivisione del codice del datalayer non è una brutta cosa.

Presupposto: i "problemi di traffico" sono una questione di ridimensionamento per far fronte al carico aggiuntivo.

Idealmente sì, non dovresti usare lo stesso codice, ma, cosa più importante per me, non utilizzerei lo stesso database.

Al suo livello più grande, la dimensione di un microservizio è quella che comprende un dominio della tua azienda: forse due servizi che hai sono "Ordini" e "Cliente". Il servizio "Ordini" può comunicare con il tuo servizio "Cliente" tramite un protocollo concordato, ma non è necessario integrarlo a livello di database. Il motivo per cui lo fai è perché ti consente di avere due team di sviluppatori indipendenti ma comunicanti. Verifico che i "servizi" che hai deciso di suddividere siano simili a queste dimensioni.

Potrebbe essere creato un "Ordine" che richiede l'indirizzo corrente di un cliente per spedire un articolo, quindi contatta il servizio "Cliente" per ottenere quell'indirizzo. Tuttavia: "Ordini" memorizza la propria copia in quanto appartiene all '"Ordine" - non al "Cliente".

Il modello più semplice è che un servizio sia proprietario di alcuni dati: nulla oltre a quel servizio dovrebbe aggiornare quei dati. Dovresti comportarti come se non avessi alcun controllo sui dati o sull'interfaccia dell'altro servizio, anche se lo fai perché potresti rompere i client esistenti.

I microservizi hanno un paio di spese generali:

• Versionare l'interfaccia (in modo da non causare problemi ai client)
• Isolamento pulito dei dati su servizi e database separati
• Scoperta / comunicazione del servizio - "Come posso parlare ad altri servizi?"
• e sono sicuro che ne manchi alcuni.

Se non fai bene quanto sopra, hai anche ulteriori complicazioni nell'implementazione del tuo software in quanto dovrai coordinare le distribuzioni di più servizi.

Se hai una base di codice ben progettata, puoi semplicemente cambiare l'implementazione dei metodi per parlare con il tuo nuovo servizio (esterno). Se non lo fai, questo sarà un viaggio molto più difficile.