Numerose associazioni in microservizi

Al momento ho due microservizi. Li chiameremo Ae B.

Il database in microservice Aha la seguente tabella:

A
|-- users

Il database in microservice Bha la seguente tabella:

B
|-- trackers

I requisiti lo affermano userse trackershanno una relazione molti-a-molti.

Non sono sicuro di come gestirlo correttamente all'interno di un'architettura di microservizi.

Ho potuto vedere questo lavoro in tre modi:

1. Una user_trackerstabella viene aggiunta a microservizio A. Funziona in modo simile a una tabella di join contenente "chiavi esterne" a userse trackers.
2. Una ownerstabella viene aggiunta a microservizio B. Questa tabella si comporta in modo simile a una tabella di join polimorfica. Ciò consentirebbe a qualsiasi servizio di creare un'associazione con un tracker. Questo potrebbe apparire un po 'così: B |-- trackers |-- owners |-- owner_id |-- owner_type |-- tracker_id
3. Conservare i record per userse trackersin ciascun microservizio. Tienili sincronizzati con una sorta di sistema pubsub.

Inizialmente avrei optato per l'opzione 2 perché mi piaceva che preservasse i confini delle transazioni. Posso creare un tracker e associarlo atomicamente a qualcosa. Tuttavia, sembra fuori dal campo di applicazione del microservizio B. Perché il microservizio dovrebbe Bpreoccuparsi che il microservizio Avoglia creare un'associazione?

Sento che probabilmente c'è un buon modello qui di cui non sono a conoscenza. Alcune delle opzioni che ho presentato hanno un senso? C'è un'altra opzione che potrebbe avere più senso?

Prima di tutto, inizierei con la descrizione del dominio. Non hai menzionato di cosa si tratta (posso immaginare, ma sarebbe solo una supposizione). Dopodiché proverei a scomporlo usando l' analisi della catena del valore o la mappatura delle capacità aziendali . E solo dopo avrei pensato all'implementazione.

Considerando il tuo problema, la prima cosa che mi viene in mente è che hai identificato i confini del tuo servizio in modo sbagliato, semplicemente perché hanno bisogno dei reciproci dati. Non vuoi finire con il monolito distribuito , vero?

La seconda cosa è che probabilmente non hai lavorato abbastanza bene sul tuo dominio. Quale concetto è rappresentato con la userstabella? È un registered user, con tutte le informazioni e il comportamento richiesti per la registrazione? Sei sicuro che sia il concetto giusto per comunicare trackers(qualunque esso sia)? Quindi, se ho capito bene, la tua opzione 2 riguarda esattamente questo: introdurre il ownerconcetto che è molto più vicino al tuo dominio. Se è davvero così, sono anche per l'opzione 2.

Tuttavia, sembra fuori campo per il microservizio B. Perché il microservizio B dovrebbe preoccuparsi che il microservizio A voglia creare un'associazione?

Si tratta di confini. Immagino che tu voglia formare microservizi attorno alle entità. Ecco dove la SOA ha fallito con la sua architettura di servizio a strati . L'approccio migliore è creare servizi che rappresentino alcune funzioni aziendali, in modo da incapsulare sia i dati che il comportamento. Da un punto di vista più pratico, si tratta di creare servizi attorno a processi aziendali o casi d'uso. Ad esempio, potresti avere un servizio per la registrazione dell'utente. Contiene i dati e il comportamento dell'utente richiesti per registrare un utente. Quindi il concetto di usersi forma naturalmente, e appartiene solo al servizio A. E questo mi porta al punto successivo: l'altro modo di pensare ai servizi è il contesto limitato . È buona norma allineare servizi e contesti limitati.

Quando l'utente è registrato, l' UserCreatedevento potrebbe essere emesso. Il tuo secondo servizio credo sia interessato a questo. Quindi, ricevendola, si potrebbe creare un'entità completamente diversa, diciamo, Ownerentità (qualunque essa sia). Sono abbastanza sicuro che ci siano molte collaborazioni interessanti tra esso e l' trackerentità: tienili in un unico servizio.

Prestare estrema attenzione con l'opzione 3. Se si copiano i dati, la funzionalità segue. Si traduce in accoppiamento stretto. E non coprire il termine CQRS , non si tratta della sincronizzazione dei dati tra servizi tramite eventi.

La risposta di Zapadlo contiene molte buone informazioni e ragionamenti. Aggiungerò qui un piccolo consiglio pratico che potrebbe semplificare la risoluzione dei problemi e i consigli in quella risposta.

Il modo in cui hai incorniciato la tua domanda di progettazione si basa sulle strutture di database e su come soddisfare un nuovo requisito per le tue strutture. Ciò implica che stai costruendo il design del servizio dal tuo modello di dati. Ad esempio, ciò che non vedo è come accedere o utilizzare la relazione tra utenti e tracker.

Nella progettazione del servizio, la struttura dell'interfaccia è la cosa più importante nella progettazione. In effetti, l'implementazione è quasi irrilevante in confronto, in particolare nel caso dei microservizi. Il motivo è che una volta messo in atto il servizio, tutte le dipendenze dal servizio dovrebbero esistere solo nell'interfaccia. Se hai capito bene, dovresti essere in grado di riscrivere completamente l'implementazione senza alcun consumatore. E questo è il principale vantaggio dell'autonomia. A nessuno importa come l'hai costruito. Hanno solo bisogno che funzioni nel modo in cui hai comunicato che funzionerà.

Prima che qualcuno possa determinare come appare nel database o dove lo desideri, devi davvero spiegare come verranno utilizzate queste informazioni. È qualcosa che verrà esposto attraverso un servizio o è una sorta di dati che si desidera trasferire per l'analisi?

Da un lato, eviterei le dipendenze bidirezionali a quasi tutti i costi. Se hai dipendenze, vuoi davvero che solo una parte sappia dell'altra. Una volta che le dipendenze sono in entrambe le direzioni, i servizi diventano essenzialmente un'unità atomica.

Molto dipende dal dominio stesso. Se un utente con zero tracker non ha senso, il servizio utente deve conoscere i tracker. Se un tracker deve avere un utente, i tracker devono conoscere gli utenti. Se qualcosa come avere un tracker con più proprietari o essere in grado di trasferire un tracker da un utente a un altro ha senso, forse queste informazioni appartengono a un altro servizio.

Domanda: Perché i tuoi dati sono separati su Datatables?

Tenderei ad andare con l'opzione 3: i servizi sono totalmente separati e possono rispondere alle rispettive domande a cui potrebbero aver bisogno di rispondere. Inoltre, sono molto più resistenti. Ma fai attenzione, i tuoi servizi potrebbero essere sincronizzati se mancano gli eventi, ma ciò può essere risolto attraverso l'eventuale coerenza.

Inoltre, potresti prendere in considerazione la fusione di entrambi i servizi: se entrambi non sono in grado di rispondere senza conoscersi, li fonderei semplicemente perché probabilmente fanno parte di un singolo dominio.