Modelli di dominio condiviso con architettura di microservizio

9

Supponiamo che abbiamo un'applicazione Spring Boot che utilizza l'architettura dei microservizi. Ciascuno dei servizi ha i propri modelli di dominio, ma ogni servizio deve fare riferimento a un oggetto dominio utente. Quale sarebbe l'approccio migliore su come risolvere questo problema? Sarebbe meglio per ogni servizio avere solo un ID utente e quindi, quando necessario, chiedere al servizio utente i dettagli dell'utente, o sarebbe meglio avere una libreria di dominio condivisa per tutti i microservizi?

    
posta user1176999 24.07.2016 - 15:20
fonte

2 risposte

8

Se hai scelto i microservizi per trarre vantaggio dalla scalabilità, dall'accoppiamento lento e dalla semplice modifica indipendente di ciascun servizio, dovresti rispettarlo nella massima misura possibile.

Architettura generale

Penso che l'approccio migliore sarebbe:

  • ha un microservizio per la gestione generale delle informazioni dell'utente;
  • conserva le informazioni utente specifiche del microservizio (ad esempio profili, autorizzazioni, preferenze) in ciascun microservizio (utilizzando il riferimento dell'ID generale)

Letture aggiuntive:

  • Questo articolo descrive molto bene questo tipo di architettura e logica , con il caso specifico di autorizzazioni.
  • Questo articolo descrive le sfide e la soluzione per la gestione dell'identità degli utenti, per evitare che tutti i servizi accesso allo stesso repository.
  • Questo articolo descrive come utilizzare JWT per passare l'identità dell'utente tra i servizi (osservando che alcune informazioni di base possono essere fornite nel token ID, che evita di dover interrogare il servizio utente ancora una volta dopo il login, almeno per informazioni di base).

Condivisione codice

Ora, se siete d'accordo sulla soluzione di cui sopra, abbiamo un microservizio utente (incapsulare il modello di dominio per l'utente) e tutti gli altri servizi sono consumatori dello stesso microservizio. La domanda è quindi sapere se vuoi:

  • ciascun microservizio per reinventare il codice del consumatore, seguendo il dogma della strong separazione per consentire cicli di rilascio flessibili e distinti,
  • o per condividere il codice consumer come parte della libreria, considerando che questa informazione fondamentale è un'estensione del "chassis" modello di infrastruttura .

Non prenderò una posizione netta su questo argomento, in quanto ci sono guerre per un'opinione opinata su questo argomento di condivisione del codice, e non penso di essere nella posizione di prendere una posizione obiettiva. Ecco alcune letture aggiuntive:

  • Questo articolo ritiene che non esista la soluzione migliore e tutto dipende dai tuoi obiettivi
  • La posizione di questo articolo è che la condivisione del codice è dannosa solo se crea un strong accoppiamento e la condivisione del codice può portare alcune sinergie
  • Questo articolo (di persone che hanno implementato microservizi su larga scala) insistono sulla necessità disporre di build separati e potenziali problemi di disattivazione del codice precedente. Avere una libreria condivisa per consumare con una solida gestione delle versioni non impedisce queste buone pratiche.

La mia opinione in merito è che NON DEVI CONDIVIDERE il codice tra il fornitore dell'utente e il consumatore-utente, al fine di evitare un accoppiamento stretto. Tuttavia, è possibile CONDIVIDERE il codice di consumo dell'utente tra i consumatori se si dispone di una gestione delle versioni avanzata. Questo approccio avrebbe alcuni vantaggi:

  • Potrebbero essere creati diversi microservizi che consumano utenti con versioni diverse del codice di consumo utente condiviso (purché le versioni siano compatibili con il fornitore di utenti indipendente). Stessa flessibilità che reinventa la ruota ma maggiore produttività.
  • È possibile modificare il servizio del fornitore di utenti in modo indipendente senza impatto sui consumatori.
  • Se viene rilevato un errore dal lato del consumo, è possibile correggerlo una volta e distribuire tutti i consumatori come i migliori (grazie alla gestione della versione). Questo potrebbe anche portare a una maggiore qualità del servizio.
  • Se per un motivo sei obbligato ad aggiornare l'API del fornitore di utente, puoi distribuire il consumo di utenti aggiornato in modo più accurato. Mantiene attivo il vecchio e nuovo servizio provider durante la transizione, questa possibilità di condivisione potrebbe consentire di rimuovere più rapidamente la versione precedente del fornitore del consumatore.
risposta data 22.08.2016 - 21:14
fonte
1

Eviterei una libreria condivisa se possibile. Chiediti quali sono le proprietà di un utente che ogni servizio richiede? Spesso esiste un dominio di base in cui vivrà la maggior parte del comportamento che circonda un utente, con i domini di supporto che spesso richiedono solo un ID utente.

Se il tuo servizio necessita di altri dettagli relativi a un utente, dai un'occhiata ad alcuni suggerimenti qui su come gestire tali situazioni

    
risposta data 24.07.2016 - 18:21
fonte

Leggi altre domande sui tag