マイクロサービス アーキテクチャでは、各サービスが独自のデータを処理することが推奨されています。したがって、他のサービス (サービス B) が所有するデータに依存するサービス (サービス A) は、直接 DB を呼び出すのではなく、2 番目のサービス (サービス B) が提供する API を介してそのようなデータにアクセスする必要があります。
では、マイクロサービスのベストプラクティスでは、外部キー制約のチェックについて何を推奨しているのでしょうか。
例: 製品の配送機能 (マイクロサービス 1) を開発していますが、製品テーブルに記載されているように、特定の製品は、製品マイクロサービス (マイクロサービス 2) のみがアクセスできる特定の場所にのみ配送可能です。
マイクロサービス 1 (つまり、配送機能) が注文をサービスが提供されていない場所に届けないようにするにはどうすればよいでしょうか。配送機能は製品データベースに直接アクセスできないため、配送注文が配送データベースに入力されたときに DB レベルで適用可能な制約がない (製品データベースまたはテーブルに外部キーの一致が存在するかどうかを確認することができない) ため、この質問があります。
ベストアンサー1
複数のマイクロサービスで共有データベースを使用することもできます。マイクロサービスのデータ管理のパターンについては、次のリンクを参照してください。http://microservices.io/patterns/data/database-per-service.htmlちなみに、マイクロサービスアーキテクチャに関して非常に役立つブログです。
あなたの場合、サービス パターンごとにデータベースを使用することを好みます。これにより、マイクロサービスがより自律的になります。この状況では、複数のマイクロサービス間でデータの一部を複製する必要があります。マイクロサービス間の API 呼び出しでデータを共有するか、非同期メッセージングで共有できます。これは、インフラストラクチャとデータの変更頻度によって異なります。頻繁に変更されない場合は、非同期イベントでデータを複製する必要があります。
この例では、配送サービスが配送場所と製品情報を複製できます。製品サービスは製品と場所を管理します。次に、必要なデータが非同期メッセージを使用して配送サービスのデータベースにコピーされます (たとえば、rabbit MQ または apache kafka を使用できます)。配送サービスは製品と場所のデータを変更しませんが、ジョブの実行時にデータを使用します。配送サービスによって使用される製品データの部分が頻繁に変更される場合、非同期メッセージングによるデータの複製は非常にコストがかかります。この場合、製品と配送サービスの間で API 呼び出しを行う必要があります。配送サービスは、製品サービスに、製品が特定の場所に配送可能かどうかを確認するように依頼します。配送サービスは、製品サービスに製品と場所の識別子 (名前、ID など) を要求します。これらの識別子は、エンドユーザーから取得することも、マイクロサービス間で共有することもできます。ここではマイクロサービスのデータベースが異なるため、これらのマイクロサービスのデータ間に外部キーを定義することはできません。
API 呼び出しは実装が簡単かもしれませんが、このオプションではネットワーク コストが高くなります。また、API 呼び出しを行っているときは、サービスの自律性が低下します。これは、この例では、製品サービスがダウンすると、配信サービスがその機能を実行できないためです。非同期メッセージングでデータを複製すると、配信に必要なデータは配信マイクロサービスのデータベースにあります。製品サービスが機能していない場合は、配信を行うことができます。