マイクロサービスアーキテクチャ-認証サーバーをユーザーリソースサーバーとして使用する
マイクロサービスアーキテクチャに基づいてアプリケーションを設計しています。
このアプリケーションでは、Authマイクロサービスが必要です。
また、おそらく複数のアドレス、アバター画像などの追加のユーザー情報を保存する必要があります
これにより、2つのマイクロサービス（1つは認証用、もう1つはユーザー用）を持つというアイデアにつながります。ユーザーには、ユーザーの追加情報を保存できます。
これまでのところ、私は次のアイデアを持っています：
認証サービスが、追加のアドレス（おそらくアバターなど）を含むユーザー情報を保持するリソースサーバーになることも許可します。これは、ユーザーに関連するすべてを1か所にまとめることができ、新規登録などの操作の複雑さを軽減するため、便利なソリューションです。ユーザー、ユーザーの削除。ただし、このソリューションはマイクロサービスの概念と矛盾しているようですが、私にとっては、このソリューションが最も魅力的です
AuthとUserの2つの異なるマイクロサービスがあります。 Authはトークンの処理のみを担当し、ユーザーに関連するデータは保存しません。トークンのリクエストを受信すると、Authサービスはユーザーを呼び出してユーザーデータを受信し、決定を行います
AuthとUserの2つの異なるマイクロサービスがあります。 Authはトークンの処理を担当し、認証に関連するユーザー情報の一部（おそらくパスワード、ロール）も格納します。ユーザーサービスは、追加のアドレス、アバターなど、他のすべての情報を保持します。この方法は、複雑なユーザーの削除/新しいユーザーの作成操作を必要とするため、複雑すぎるようです
さて、これらのソリューションの1つを選択する必要がありますが、どちらが適切かわからないので迷っています。
これに関するアドバイスをいただければ幸いです。
ありがとう
3が正解です。
あなたの認証サーバーはユーザーを認証します、あなたのユーザーサーバーはおそらく 'UserProfiles'と名付けられるでしょう
ユーザーの多くはプロファイルを持つユーザーであることがわかりますが、他のAPIのサービスユーザーや、おそらく認証サーバーを使用して対応するプロファイルを持たない単純なAPIキーも存在します。
さらに、すぐに使用できるAuthサーバーとフレームワークが数多くあることに気付くでしょうが、UserProfileはニーズに合わせてカスタマイズされます。多くの場合、カスタムプロファイルにuseridを追加する方が、カスタムプロファイルを既成の認証DBと統合するよりも簡単です