Il punto dei microservizi - o come li chiamo servizi focalizzati - si occupa di un argomento su un servizio logistico (che potrebbe essere diverse istanze fisiche).
Il tipo di architettura che descrivi potrebbe essere inserito nei seguenti servizi:
- Auth
- utente
- Application
- Video
- (Pagamento ...)
Both services save user data.
Da quello che scrivi, non è chiaro, cosa significa "dati utente". Se ciò significa qualcosa come le informazioni correlate a un user identifier , questo andrebbe bene. Se stai memorizzando un qualche tipo di oggetto "utente", ciò potrebbe essere soggetto a modifiche. Tutto ciò che è correlato all'utente dovrebbe essere mantenuto nel User -Service.
Mentre distribuisci la tua applicazione, devi distribuire il User per dire. Ogni servizio ha una prospettiva su ciò che un utente è. Se hai bisogno di un sommario, devi aggregarne uno.
The problem is that the user registers on the authorization service. Therefore, he still needs to be registered at the 2 other services. How should this be done?
Segue una descrizione dichiaratamente semplicistica, ma dovresti ottenere il punto:
Da quello che era wirtten sopra. Il lavoro di auth -Service è semplicemente quello di creare un singolo punto di fiducia.
Il servizio auth è qualcosa come un "botteghino" che offre i biglietti per entrare.
Gli altri servizi si fidano di biglietti validi offerti dal servizio auth .
La loro unica responsabilità è di controllare la validità del biglietto che il visitatore ha.
Non è necessario che i singoli servizi sappiano, se esiste un utente specifico. Devono solo fidarsi del ticket . O per metterlo in un altro modo: l'utente non deve essere registrato in nessun altro servizio rispetto al servizio auth .
La domanda più interessante sarebbe, come distribuire le informazioni che un ticket valido fondamentalmente dovrebbe essere invalidato. Ma questo è un altro argomento.
Mi raccomando per ulteriori letture:
Autorizza come servizio:
On Premise