Architecture de microservice - Utilisation d'Auth Server en tant que serveur de ressources utilisateur
Je concevons une application basée sur l'architecture de Microservices,
Dans cette application, j'aurai besoin d'AUTH Microservice,
De plus, j'aurai besoin de stocker des informations d'utilisateur supplémentaires telles que, peut-être, plusieurs adresses, photo avatar, etc.
Cela conduit à une idée d'avoir deux microservices - un pour Auth et un autre, utilisateur, qui pourrait stocker des informations supplémentaires sur l'utilisateur,
Jusqu'à présent, j'ai les idées suivantes:
Autoriser le service d'authentification également d'être un serveur de ressources qui conserverait des informations utilisateur, y compris des adresses supplémentaires, peut-être, un avatar, etc. Il s'agit d'une solution pratique, car permettant d'avoir tout ce qui concerne l'utilisateur à un endroit et réduit la complexité des opérations telles que l'enregistrement de nouveau. Utilisateur, suppression de l'utilisateur. Cependant, cette solution semble contredire le concept de microservices, mais comme pour moi, cette solution est la plus attrayante
Avoir deux microservices différents - authentifiant et utilisateur. L'authentifie ne serait responsable que pour la manipulation des jetons et ne stockera aucune donnée liée à l'utilisateur. Ainsi, lorsque la demande de jeton est reçue, le service d'authentification appelle l'utilisateur à recevoir des données utilisateur et à prendre une décision.
Avoir deux microservices différents - authentifiant et utilisateur. L'authentifie serait responsable de la manipulation des jetons et de stocker également une partie des informations utilisateur telles liées à l'authentification (peut-être mot de passe, rôles). Le service utilisateur tiendra toutes les autres informations telles que des adresses supplémentaires, des avatars, etc. Cette approche de moi semble trop complexe car elle nécessite un utilisateur de suppression complexe/crée de nouvelles opérations utilisateur.
Maintenant, je devrai choisir l'une de ces solutions mais je suis perdu et je ne suis pas sûr lequel est le bon,
Appréciera tout conseil en ce qui concerne cela,
Merci
3 est la bonne réponse.
Votre authentificateur authentifie les utilisateurs, votre serveur utilisateur serait peut-être mieux nommé 'UserProfiles'
Vous constaterez que bon nombre de vos utilisateurs seront des profils avec des profils, mais vous aurez également des utilisateurs de services pour d'autres API ou peut-être de simples clés d'API, qui utilisent également le serveur d'authentification pour authentifier, mais n'ont pas de profil correspondant.
De plus, vous constaterez probablement qu'il y en a de nombreuses serveurs et cadres de la boîte, mais vous pouvez utiliser UserProfile pour répondre à vos besoins. Il est souvent plus facile d'ajouter un userid à un profil personnalisé que d'intégrer un profil personnalisé avec un dB d'authentification prématuré.