マイクロサービス：外部キー関係の処理方法
マイクロサービスアーキテクチャは、各サービスが独自のデータを処理することを提案しています。したがって、他のサービス（サービスB）が所有するデータに依存するサービス（サービスA）は、直接のDB呼び出しを行うのではなく、2番目のサービス（サービスB）が提供するapiを介してそのようなデータにアクセスする必要があります。
だから、マイクロサービスのベストプラクティスは、外部キー制約のチェックについて何を示唆していますか。
例：製品の配信機能（マイクロサービス1）を開発しており、特定の製品は、製品マイクロサービス（mircoservice 2）のみがアクセスできる製品表に記載されている特定の場所にのみ配信可能です。
マイクロサービス1（配信機能）がサービスを受けていない場所に注文を送らないようにする方法を教えてください。配信機能は製品データベースに直接アクセスできないため、この質問があります。したがって、配信注文が配信データベースに配置されるときにDBレベルで適用される制約はありません（製品データベースに外部キーの一致が存在するかどうかを確認することはできません）またはテーブル）。
複数のマイクロサービスに共有データベースを使用することが可能です。このリンクでマイクロサービスのデータ管理のパターンを見つけることができます： http://microservices.io/patterns/data/database-per-service.html 。ちなみに、マイクロサービスアーキテクチャにとって非常に便利なブログです。
あなたの場合、サービスパターンごとにデータベースを使用することを好みます。これにより、マイクロサービスがより自律的になります。この状況では、複数のマイクロサービス間でデータの一部を複製する必要があります。マイクロサービス間のAPI呼び出しでデータを共有することも、非同期メッセージングでデータを共有することもできます。インフラストラクチャとデータの変更頻度に依存します。頻繁に変更されない場合は、非同期イベントでデータを複製する必要があります。
あなたの例では、配達サービスは配達場所と製品情報を複製できます。製品サービスは、製品と場所を管理します。次に、必要なデータが非同期メッセージとともに配信サービスのデータベースにコピーされます（たとえば、rabbit mqまたはApache kafkaを使用できます）。デリバリサービスは製品と場所のデータを変更しませんが、ジョブを実行するときにデータを使用します。デリバリサービスで使用される製品データの一部が頻繁に変更される場合、非同期メッセージングによるデータ複製は非常にコストがかかります。この場合、製品と配送サービスの間でAPI呼び出しを行う必要があります。配達サービスは、製品が特定の場所に配達可能かどうかを確認するように製品サービスに依頼します。配送サービスは、製品のサービス（ID、名前、IDなど）と製品の場所を要求します。これらの識別子は、エンドユーザーから取得するか、マイクロサービス間で共有できます。ここではマイクロサービスのデータベースが異なるため、これらのマイクロサービスのデータ間で外部キーを定義することはできません。
API呼び出しは実装が簡単かもしれませんが、このオプションではネットワークコストが高くなります。また、API呼び出しを行っている場合、サービスの自律性は低下します。なぜなら、あなたの例では、Productサービスがダウンしているとき、Deliveryサービスはその仕事をすることができません。非同期メッセージングでデータを複製する場合、配信を行うために必要なデータは、配信マイクロサービスのデータベースにあります。製品サービスが機能していない場合、配送を行うことができます。
カップリングを削減するためにコードを配布する場合、リソースの共有を避けたいのですが、データは共有を避けたいリソースです。
もう1つのポイントは、システム内の1つのコンポーネントのみがデータを所有し（状態変更操作用）、他のコンポーネントは読み取りはできるが書き込みはできない、データのコピーを保持できる、または最新の状態を取得するために使用できるビューモデルを共有できることですオブジェクトの。
参照整合性を導入すると、カップリングが再導入されます。代わりに、主キーにGUIDなどを使用し、オブジェクトの作成者が作成し、残りは結果整合性の管理に関するものです。
Udi Dahanの 詳細についてはNDC Osloで話してください をご覧ください
お役に立てれば