マイクロサービスアーキテクチャ-認証サーバーをユーザーリソースサーバーとして使用する

マイクロサービスアーキテクチャに基づいてアプリケーションを設計しています。

このアプリケーションでは、Authマイクロサービスが必要です。

また、おそらく複数のアドレス、アバター画像などの追加のユーザー情報を保存する必要があります

これにより、2つのマイクロサービス（1つは認証用、もう1つはユーザー用）を持つというアイデアにつながります。

これまでのところ、私は次のアイデアを持っています：

1. 認証サービスが、追加のアドレス（おそらくアバターなど）を含むユーザー情報を保持するリソースサーバーになることも許可します。これは、ユーザーに関連するすべてを1か所にまとめて、新規登録などの操作の複雑さを軽減できるので、便利なソリューションです。ユーザー、ユーザーの削除。ただし、このソリューションはマイクロサービスの概念と矛盾しているようですが、私にとっては、このソリューションが最も魅力的です

2. 2つの異なるマイクロサービス-認証とユーザー。Authはトークンの処理のみを担当し、ユーザーに関連するデータは保存しません。トークンのリクエストが受信されると、Authサービスはユーザーを呼び出してユーザーデータを受信し、決定を行います

3. 2つの異なるマイクロサービス-認証とユーザー。Authはトークンの処理を担当し、認証に関連するユーザー情報の一部（おそらくパスワード、ロール）も格納します。ユーザーサービスは、追加のアドレス、アバターなど、他のすべての情報を保持します。この方法は、複雑なユーザーの削除/新しいユーザーの作成操作を必要とするため、複雑すぎるようです

さて、これらの解決策の1つを選択する必要がありますが、迷っていて、どれが正しい解決策なのかわかりません。

これに関するアドバイスをいただければ幸いです。

ありがとう

3が正解です。

あなたの認証サーバーはユーザーを認証します、あなたのユーザーサーバーはおそらく 'UserProfiles'と名付けられるでしょう

ユーザーの多くはプロファイルを持つユーザーであることがわかりますが、他のAPIのサービスユーザーや、おそらく認証サーバーを使用して対応するプロファイルを持たない単純なAPIキーもあるでしょう。

さらに、すぐに使用できるAuthサーバーとフレームワークが数多くあることに気付くでしょうが、UserProfileはニーズに合わせてカスタマイズされます。多くの場合userid、カスタムプロファイルを既製の認証DBと統合するよりも、カスタムプロファイルにを追加する方が簡単です。