私はまだマイクロサービスアーキテクチャを理解しようとしています。
異なるアプリケーション(データベースを含む)を分離するという考えは私をワクワクさせます。しかし、2つのマイクロサービスがある場合、私はまだ混乱しています。製品とユーザー。データベース内の製品とユーザーの両方のテーブル製品とユーザーの両方。マイクロサービスのベストプラクティスによると、データベースにアクセスできるのはサービスからのみです。
問題は、user_id列を持つ製品テーブルがあると仮定します。製品を作成したユーザーの名前も返す製品検索を実行したいと考えています。これには、製品マイクロサービスの製品テーブルとユーザーマイクロサービスのユーザーテーブルを結合する必要があります。これをどのように扱いますか?
各マイクロサービスを呼び出して手動で参加するか、関連するユーザーIDを各サービスに渡す必要があります。
UserMicroservice:
SELECT * FROM Users WHERE some condition is true
id
sを含むユーザーのリストを取得します。
ProductMicroserivce:
SELECT * FROM Products WHERE some condition is true AND userId IN (.........)
したがって、ユーザーと製品は2つの異なるデータベースに存在することができ、製品にはuserIdの概念が必要です。
逆も可能です、ProductMicroserivce:
SELECT * FROM Products WHERE some condition is true
すべてのUserIdを抽出してから、UserMicroserviceを呼び出します。
SELECT * FROM Users WHERE some condition is true AND id IN (.........)
Janが提案した方法でそれを行うことには何の問題もないと私は思いますが、マイクロサービスがシステムに追加する必要のある違いは異なる性質のものであると付け加えたいと思います。
上記のサービスの分離は、SOAの世界でよく見られるものであり、多くの価値を提供することなく非常に複雑になりすぎることが判明しました。
あなたと私がそれが単なる例であることを理解している場合、製品に接続しているユーザーにクエリを実行する必要があります。なぜサービスを分割するのですか?あなたは、与えられた要件が何であるか、私には境界のあるコンテキストに見えるものを見るのではなく、dbエンティティごとにサービスを設計することになります。
-ラーズ
このようなシナリオに対する最良の答えはCQRSです。ユーザーと製品の関係の具体化されたビューを維持します。メーター化されたビューは、NoSql DBのように、読み取りの待ち時間が短いものであれば何でもかまいません。コマンドがマイクロサービスによってユーザーまたは製品を更新するたびに、対応するイベントが生成され、このMaterializedViewを管理する他のサービスによってキャプチャされます。このサービスは、関心のあるクエリをフェッチするために使用されます。常に心に留めておいてください。マイクロサービスアーキテクチャは、結果整合性を信じていますが、これは間違いなく悪いことではありません:)。