Come mantenere l'integrità della relazione con Microservice Architecture

0

Attualmente quando costruisco applicazioni, le costruisco come un'unica grande applicazione monolitica in modo che tutto risieda in un unico assembly compilato e i dati risiedano in un unico database SQL (con alcuni redis / elasticsearch usati come supporto). Questo funziona relativamente bene per i miei scopi, ma mi piacerebbe passare alla progettazione di architetture di micro-servizi. Tuttavia, ho difficoltà a capire come viene mantenuta l'integrità relazionale quando i vostri servizi / database sono distribuiti su più server.

Osservare il diagramma seguente:

Inquestoesempio,ilservizioIdentityèseparatodalserviziodiordinazione.Ovviamentel'IdentityMicroserviceavrebbebisognodirecuperareidatiutentedaundatabaseconcosecomenome,cognome,password,ruoli/reclami,ecc.

Ovviamentealtrepartidelsistemahannorelazioniconl'utente.Adesempio,ogniordineèprobabilmentelegatoall'utentechehaeffettuatol'ordine.InundatabaseSQLtradizionale,sidovrebbesemplicementeavereunachiaveesternapermantenerel'integritàrelazionale.Conildiagrammasopra,"Ordering Microservice" sembra completamente indipendente dal database dell'utente. In che modo l'integrità relazionale viene mantenuta in tale architettura? Il servizio di ordinazione inserisce semplicemente un record "Ordine" con l'ID dell'utente senza mantenere alcun rapporto da nessuna parte? Cosa succede se quell'utente viene quindi cancellato dal sistema. In questo particolare esempio probabilmente vorrai mantenere i dati dell'ordine, ma ci sono molti esempi in cui vorresti cancellare i dati relativi a quell'utente quando l'utente viene cancellato. In un'architettura di microservice sembra che tutto questo debba essere fatto manualmente con un sacco di spazio per errori.

    
posta Brad 10.11.2018 - 04:01
fonte

3 risposte

1

Does the ordering service just insert an "Order" record with the user's ID without maintaining any relationship anywhere?

Yup

La cosa da tenere a mente qui è che questi servizi, anche se sono chiamati "micro", tendono ad essere piuttosto grandi. Avrai molti oggetti strettamente accoppiati, come gli indirizzi o qualsiasi altra cosa al loro interno.

Qualunque sistema sceglie uno scope dove dice "ok, non mi interessa davvero che l'albero genealogico dei clienti risalga a 100 anni o che tipo di auto guidi".

L'architettura dei microservizi ti sfida a considerare che il tuo sistema totale potrebbe non essere un singolo ambito.

Quando si è abituati a programmare monoliti o grandi database relazionali, il pensiero immediato è "ma ho bisogno dell'integrità referenziale tra clienti e ordini !!" Ma spesso la realtà è che non lo fai.

Puoi immaginare un'intera tonnellata di logica correlata solo al mantenimento di un sistema cliente / autenticazione che non ha alcuna influenza sul fatto che il tuo sistema sia un sito di e-commerce o una bacheca o un sistema fiscale o altro.

Vuoi essere in grado di aggiungere funzionalità a quella parte del sistema senza preoccuparti di acquistare beni o compilare dichiarazioni dei redditi.

Quindi l'accoppiamento lento di un id utente negli altri sistemi va bene, anche se ovviamente vorrete stare attenti ai senari in cui le informazioni dell'utente vengono cancellate o perse. Mantenendo una pista di controllo o copiando campi chiave, ad esempio nome e indirizzo su altri sistemi in cui sarebbe ragionevole farlo, ad esempio sull'ordine completato che richiede un'etichetta di consegna.

    
risposta data 10.11.2018 - 10:08
fonte
0

Utilizzi i servizi API: s e microservizi liberamente accoppiati . In pratica ciò significa comunicazione REST tra i tuoi servizi. Se un'entità viene aggiunta, eliminata, modificata o ripristinata in un microservizio e questo influenza i dati in altri microservizi, si consente al primo servizio di effettuare una richiesta API REST su http, autenticata forse con un token nell'intestazione http e tale richiesta rende il secondo servizio aggiornare i suoi dati sottostanti, indipendentemente dalla struttura, in modo che mantenga la sua validità.

    
risposta data 10.11.2018 - 06:37
fonte
0

Penso che dovresti avere un singolo componente del punto di ingresso (forse eshop webapp MVC) nell'ecosistema dei tuoi vari servizi, che svolgerà il ruolo di un orchestratore, ovviamente i tuoi microservizi potrebbero collaborare su http, ma per operazioni di scrittura, richieste di questo tipo dovrebbe passare attraverso una singola voce e l'orchestratore deve assicurare l'ordine delle operazioni per un utente (attraverso uno stato di coda e operazione), altrimenti si potrebbe incontrare un problema quando la scrittura di un ordine si verifica dopo la cancellazione di un utente (solo un esempio ...), questo è il motivo per cui devi mantenere l'ordine di tali operazioni per un'identità.

Potresti anche trasformare la tua architettura in una event-driven, che potrebbe anche assicurare l'ordine delle operazioni.

    
risposta data 10.11.2018 - 18:21
fonte

Leggi altre domande sui tag