マイクロサービスでのユーザー登録フロー
承認サービス（JAuthを使用したOAuth2）、VideoService、MyApplicationServiceなどの複数のマイクロサービスがあるとします。
VideoServiceは、MyApplicationServiceのビデオを提供します。どちらのサービスもユーザーデータを保存します。
フロントエンドは3つのサービスすべてを使用し、ユーザーは実際に複数のサービスを使用していることを知りません。
問題は、ユーザーが許可サービスに登録することです。したがって、彼はまだ他の2つのサービスに登録する必要があります。これはどのように行う必要がありますか？
これまでに思いついた最善の解決策は、ユーザーを暗黙的に登録することです。これにより、不明なユーザーがリクエストを行うと、新しいユーザーが自動的に作成されます（もちろん、認証が有効である限り）。これはまともな解決策のようですが、「クリーン」に感じません。
より良い、またはより標準的なソリューションはありますか？
これは、中央メッセージングコンポーネントがマイクロサービス環境で適切に機能する場所です。承認サービスは、他のサービスが必要とする最小限の情報とともに、新しいユーザーが登録されたイベントを発行する（メッセージをキューに送信する）必要があります。他のサービスはこのキューで新しいメッセージをリッスンし、プロファイルを自動作成して「ユーザー登録」メッセージに応答します。
したがって、基本的にワークフローは次のようになります。
認証サービスは「ユーザー登録」メッセージをユーザー認証キューに発行します
VideoServiceとMyApplicationServiceは認証キューをリッスンし、「ユーザー登録」メッセージに応答します
他の2つのサービスは、「ユーザー登録」メッセージに応答した結果としてユーザープロファイルを作成します。
正直に言うと、独自の「ユーザープロファイル」機能を持つ各マイクロサービスは、マイクロサービスアーキテクチャの主要なガイドラインの1つに違反します。各マイクロサービスは、1つだけのビジネス機能に特化する必要があります。 「ユーザープロファイル」はビジネス機能です。
VideoServiceとMyApplicationServiceの「ユーザープロファイル」機能をさらに別のサービスであるユーザープロファイルサービスに抽出することをお勧めします。
異なるサービスのユーザープロファイルの明確な抽象化を特定する必要があります。この概念の抽象化を合理的に作成できない場合は、他のサービスでユーザープロファイルを保持します。
あなたの質問に基づいて、以下を確認することをお勧めします：
- 「VideoServiceはMyApplicationServiceのビデオを提供します」。理想的には、マイクロサービスは互いに提供（通信）すべきではありません。ユーザー（または外部クライアント）にのみサービスを提供する必要があります。サービスのネットワークが互いに通信することで、「分散した大きな泥の塊」と呼ばれるものが作成されます。
- 「どちらのサービスもユーザーデータを保存します」。別のデータを保存する限り、これで問題ありません。たとえば、「MyServiceService」がユーザー名と電話番号を格納するかどうかに関係なく、「VideoService」は「ユーザーの好みのビデオカテゴリ」を格納します。したがって、各サービスには、そのサービスが動作するために必要な「ユーザーの一部」のみが格納されます（これは、サービス間の通信を回避するための基礎です）。
- 「彼はまだ他の2つのサービスに登録する必要があります」。これがあなたの主な質問です。以下に回答します。
「登録済み」とは、各サービスがユーザーの存在を「知る」必要があることを意味します。たとえば、新しいユーザーが登録されると、VideoServiceは「優先動画カテゴリ」の空のリストを含むレコードを作成します。正しいアプローチは、Greg Burghardtが提案したものです（メッセージをキューに入れないことを明確にしますが、イベントをパブリッシュすると、各サービスに1つずつ、2つのキューにメッセージが送られます）。このパターンは、「ユーザーが登録されると、デフォルトのユーザープロファイルが作成される」などの要件を満たしている場合に識別できます（「When」の部分は通常、公開されているビジネスイベントを識別し、別のサービスが関心を持っています）。
そうでなければ、「他の2つのサービスに登録されている」と言ったときに認証について話している場合、問題はまったく異なります。個人的には、クライアントが複数のAPIと通信することはありません。代わりに、内部マイクロサービスAPIを呼び出す単一のAPIゲートウェイを用意します。このゲートウェイは、認証と基本的な承認（すべてのエンドポイントへのアクセスに必要なロールまたはアクセス許可の検証）を処理します。一方、クライアントがすべてのマイクロサービスと直接通信することを希望する場合は、すべてのAPIへのシングルサインオンを処理する共有インフラストラクチャを構築して、ユーザーを1回だけ登録する必要があるようにします。
マイクロサービスのポイント-または私がそれらをfocussedサービスと呼んでいるところ-1つのロジカルサービス（複数の物理インスタンスである可能性があります）に関する1つのトピックを扱っています。
あなたが説明する種類のアーキテクチャは、次のサービスに入れることができます：
- Auth
- ユーザー
- 応用
- ビデオ
- （お支払い...）
どちらのサービスもユーザーデータを保存します。
あなたが書いたものからは、「ユーザーデータ」が何を意味するのか明確ではありません。 user identifierに関連付けられた情報のようなものを意味する場合は、これで問題ありません。ある種の「ユーザー」オブジェクトを格納している場合、それは変更される可能性があります。ユーザーに関連するものはすべてUser- Serviceに保持するのが最適です。
アプリケーションを配布するときに、言うまでもなくUserを配布します。すべてのサービスは、userが何であるかについての視点を持っています。要約が必要な場合は、要約する必要があります。
問題は、ユーザーが許可サービスに登録することです。したがって、彼はまだ他の2つのサービスに登録する必要があります。これはどのように行う必要がありますか？
それは確かに非常に単純化した説明に従いますが、要点を理解する必要があります。
上で何をしていたかから。 auth- Serviceの仕事は、単一の信頼点を構築することです。
authサービスは、入場チケットを提供する「興行収入」のようなものです。
他のサービスは、authサービスによって提供される有効なチケットを信頼します。彼らの唯一の責任は、訪問者が持っているチケットの有効性をチェックすることです。
特定のユーザーが存在するかどうかを、単一のサービスが知る必要はありません。 チケットを信頼する必要があるだけです。または別の言い方をすると、ユーザーはauthサービス以外のサービスに登録されている必要はありません。
より興味深い質問は、基本的にvalidチケットを無効にする必要があるという情報をどのように配布するかです。しかし、それは別のトピックです。
私はさらに読むことをお勧めします：
サービスとしての認証：
敷地内に
TL DR;すべてが問題なければ、API Gatewayでセキュリティジョブを実行し、リクエストをマイクロサービスにルーティングします。
マイクロサービスアーキテクチャにはAPI Gatewayアプローチを使用する必要があります。
APIゲートウェイ（zuulなど）があるとしましょう。認証サーバー（UAA、キークロークなど）をそのゲートウェイに直接接続できます。そして、インバウンド要求が認証を必要とすることをチェックする事前フィルターを定義します。はいの場合、ゲートウェイレベルでトークンをチェックし（トークンが有効であり、特定のジョブを実行するための有効な権限を持っていることを認証サーバーに直接尋ねて）、要求を使用するマイクロサービスにルーティングします。