特定のドメインのデータをマイクロサービスとレガシーデータベースの間で分散しています。レガシーデータベースとマイクロサービスデータベースの両方のフィールドにまたがる検索があります。以前（マイクロサービスの分割前）、1つのSQLクエリで実行されていました。この検索機能を提供するには、REST呼び出しとレガシーデータベースへのクエリが必要です。ここでは数百万行について話しています。これをどのように最適にモデル化できますか？データ量が多いため、REST呼び出しは通常、ページ分割された結果も返します。SQL呼び出しを起動し、結果をREST応答と結合およびマージする単純なアプローチは遅すぎて、実際的ではありません。
回答:
検索機能は、言及した2つのサービスとは別の責任を持つ別のサービスとしてモデル化できます。したがって、ここでのアプローチは、新しいサービス（「検索」）を作成し、両方のサービスからのデータのコピーを、インデックスと検索が簡単な形式で保存することです。目的の形式。
そのため、たとえば、mySqlなどを使用するレガシーSQLデータベース、MongoDBなどを使用する他のマイクロサービス、およびより便利なアクセスのために既に貼り付けられた（非正規化）の両方のデータを使用したelasticsearchを使用した新しい検索サービスを使用できます。もちろん、詳細は実行する必要のある検索の種類によって異なります。
2つのサービスからのデータは、KafkaやHermesなどのイベントバスを介して検索インデックスに非同期で転送するのが最適で、スループットを向上させ、サービス間の結合を減らします。2つのサービスのいずれかを変更すると、検索サービスにデータを更新するよう通知するイベントが送信されます。
もちろん、サービスの変更と検索サービスの変更との間に追加の遅延のコストがありますが、マイクロサービスは通常、分散システムで使用されるため、何らかの遅延と一時的な矛盾は避けられません。追加のサービスがあり、他の2つのサービスに既にあるデータのコピーに追加のストレージを使用することも、マイクロサービスを使用した高度に分散されたスケーラブルなシステムを持つ一般的なコストです。