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.