マイクロサービスアーキテクチャ：クロスサービスデータ共有
オンラインストアプロジェクトの次のマイクロサービスを検討してください。
Users Serviceは、ストアのユーザーに関するアカウントデータ（姓、名、電子メールアドレスなど）を保持します
購入サービスは、ユーザーの購入に関する詳細を追跡します。
各サービスは、関連するエンティティを表示および管理するためのUIを提供します。 Purchase Serviceインデックスページには、購入が一覧表示されます。各購入アイテムには次のフィールドが必要です。
id、購入ユーザーのフルネーム、購入したアイテムのタイトルと価格。
さらに、インデックスページの一部として、ユーザー名を購入することでストアマネージャーが購入を検索できるようにする検索ボックスが欲しいのですが。
Purchase Serviceが保持していないデータ（たとえば、ユーザーのフルネーム）をどのように取得するかは、私にはわかりません。ユーザー名を購入して検索購入などのより複雑なことをしようとすると、問題はさらに悪化します。
ユーザーの作成時になんらかのイベントをブロードキャストすることで2つのサービス間でユーザーを同期する（そして、購入サービスエンドで関連するユーザープロパティのみを保存する）ことで、これを明らかに解決できると考えました。それは私の見解では理想からほど遠いです。何百万ものユーザーがいる場合、これにどのように対処しますか？ユーザーデータを消費する各サービスで何百万ものレコードを作成しますか？
別の明白なオプションは、指定されたIDに基づいてユーザーの詳細を返すユーザーサービスエンドでAPIを公開することです。つまり、すべてのページがPurchase Serviceに読み込まれると、正しいユーザー名を取得するために、Usersサービスを呼び出す必要があります。理想的ではありませんが、私はそれと共存できます。
ユーザー名に基づく購入検索の実装についてはどうですか？ええと、クエリ用語を受け取るユーザーサービスエンドで別のAPIエンドポイントを常に公開し、ユーザーサービスでユーザー名に対してテキスト検索を実行して、条件に一致するすべてのユーザーの詳細を返すことができます。 Purchase Serviceで、関連するIDを正しい名前にマッピングし、ページに表示します。このアプローチも理想的ではありません。
何か不足していますか？上記を実装するための別のアプローチはありますか？多分私がこの問題に直面しているという事実は一種のコードのにおいですか？他の解決策を聞きたいです。
これは、マイクロサービスに移行する際の非常に一般的で中心的な問題のようです。そのための良い答えがあったらいいのに:-)
ここですでに述べた推奨パターンについては、ポリグロット永続性ではなくデータ非正規化という用語を使用します。これは、必ずしも異なる永続化テクノロジーである必要はないためです。ポイントは、各サービスが独自のデータを処理することです。そして、はい、データの重複があり、通常、サービス間でデータを共有するには、ある種のイベントバスが必要です。
別のオプションがあります。これは、最初の一種のテイクです-検索自体を別個のサービスとして作成します。
したがって、この例では、ユーザーを管理するためのUserサービスがあります。 Purchasesサービスは、購入を管理します。それぞれが独自のデータと必要なデータのみを処理します（たとえば、Purchasesサービスではユーザー名は必要なく、IDのみが必要です）。また、他のサービスによって生成されたデータを使用し、結合されたデータから検索「ビュー」を作成する3番目のサービス（検索サービス）があります。
適切なデータを別のデータベースに保持することはまったく問題ありません。これは Polyglot Persistence と呼ばれます。はい、ユーザーデータと購入に関するデータを別々に保持し、同期にはメッセージキューを使用します。何百万ものユーザーが私には問題ないと思います。それはスケーラビリティであり、デザインの問題ではありません;-)
検索の場合-たぶんユーザー名だけではなく検索したいでしょう？したがって、メッセージキューを使用してサービス間でデータを更新する場合、このデータをElasticSearchなどに簡単にルーティングすることもできます。 ElasticSearchの観点からは、インデックスを作成するフィールド（ユーザー名や製品のタイトル）は実際には重要ではありません。
私は通常両方のアプローチを使用します。ときどき、他のxサービスの上に位置し、データを組み合わせる別のサービスがあります。このアプローチは、サービス間の依存関係と結合を引き起こしているため、あまり好きではありません。したがって、一般的に、私の最後のプロジェクトでは、ポリグロットの永続性に固執しようとしました。
また、ある種のミドルウェアサービスでデータを組み合わせるためにx sub httpリクエストが必要な場合は、レイテンシが長くなることを考慮してください。私たちは常に、1つのタスクに対する要求の量を削減し、非同期キューを介して可能なことすべてを処理しようとします。 （特にデータ同期）