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