データ重複のないマイクロサービス

最も単純なマイクロサービス設計であっても、データの重複や共有データベースを回避するのが難しいと感じているため、何かが足りないと思っています。これが私が直面している問題の基本的な例です。誰かがWebアプリケーションを使用して在庫を管理していると仮定すると、2つのサービスが必要になります。1つはアイテムと在庫数を管理する在庫管理用、もう1つはユーザーデータを管理するユーザーサービス用です。データベースの在庫者の監査が必要な場合、在庫サービスのデータベースにユーザーIDを最後に在庫された値として追加できます。

アプリケーションを使用して、不足しているすべてのアイテムと、前回アイテムを在庫していた人のリストを確認して、再度在庫を補充するよう依頼することができます。上記のアーキテクチャを使用して、在庫サービスにリクエストを行い、数量が5未満のすべてのアイテムのアイテム詳細を取得します。これにより、ユーザーIDを含むリストが返されます。次に、インベントリサービスから取得したユーザーIDのリストのユーザー名と連絡先の詳細を取得するために、ユーザーサービスに対して別の要求が行われます。

これは非常に非効率的なようで、複数のデータベースクエリを作成するさまざまなサービスAPIに対して複数のリクエストを行うまで、これ以上多くのサービスを必要としません。別の方法は、インベントリデータにユーザーの詳細を複製することです。ユーザーが連絡先の詳細を変更した場合、他のすべてのサービスを通じて変更を複製する必要があります。しかし、これは、マイクロサービスの限定されたコンテキストの考えに適合しないようです。また、単一のデータベースを使用してこれを異なるサービス間で共有し、統合データベースのすべての問題を抱えることもできます。

これを実装する正しい/最良の方法は何ですか？

複製する必要がある場所を完全に見落としました。

マイクロサービスの中心的な原則は、サービスが単一の機関であることです。つまり、在庫管理とユーザー管理を完全に分離できます。ユーザー管理は、在庫システムの存在すら知らないように設計します。

ただし、ユーザーID以外のユーザーに関する情報を保存しないように、インベントリシステムを設計します。ユーザー情報の変更を伝播する問題を処理します。

ログ、監査、印刷出力など、在庫情報とユーザー情報の両方を必要とするものについては、情報が変更されても更新されません。彼らは何があったかの記録です。繰り返しますが、変更を伝播しません。

そのため、どの場合でも、最新のユーザー情報が必要な場合は、ユーザー情報サービスに問い合わせてください。

データの重複を避けるのは難しいと思っています。...

マイクロサービスアーキテクチャに関するMicrosoftの電子書籍によると、データの複製に問題はありません。基本的に、データを複製すると、サービス間の分離が促進されるため、単一の機関としての役割が強化されます。関連する一節：

そして最後に（そして、これはマイクロサービスを構築する際にほとんどの問題が発生する場所です）、最初のマイクロサービスが他のマイクロサービスによって元々所有されているデータを必要とする場合、そのデータの同期リクエストを行うことに依存しません。代わりに、結果整合性を使用して（通常は統合イベントを使用して）、そのデータ（必要な属性のみ）を初期サービスのデータベースに複製または伝播します。

在庫サービスに対してリクエストが行われ、数量が5未満のすべてのアイテムのアイテム詳細を取得します。これにより、ユーザーIDを含むリストが返されます。次に、インベントリサービスから取得したユーザーIDのリストのユーザー名と連絡先の詳細を取得するために、ユーザーサービスに対して別の要求が行われます。

たしかにそう。

確かに、モノリスでは、関連するアイテムを照会するインベントリモデルを作成し、それをユーザーモデルにフィードして同じデータを取得できます。

または、同じリレーショナルデータベースにそれらを配置し、データベースがインベントリテーブルとユーザーテーブルを取得するSQLを記述している場合、さらに処理することができます。これにより、いくつかの魔法が実行され、目的のデータが取得されます。

かかわらず、あなたがそれを行う方法の、どこかだろう、本質的に、在庫システムからユーザーIDのリストを取得し、ユーザーのシステムにそれらを供給し、データのリストをコンパイルするコードです。

答える必要がある質問は、パフォーマンスとメンテナンス、およびその他の「ソフト」品質についてです。

マイクロサービスの主な利点はスケーリングです。1台のマシンに1万人のユーザーがいて、少し遅い場合は、別のマシンを追加すると、システムの速度が2倍になります。さらに8つ追加すると、10倍の速度になります。（線形スケーリングはおそらく楽観的ですが、それは理想的なものであり、期待するほど不合理ではありません。）

そして、これはサービスごとです。インベントリシステムがボトルネックの場合、ユーザーに関するレポート以外にも使用されます。そのサービスだけにマシンを追加できます。機械も特化できます。このサービスは大量のメモリを必要とし、そのサービスは重い計算を行い、より多くのCPUを必要とします。

スケーリングが必要ない場合、マイクロサービスにはもう1つの利点があります。それらはモジュール式です。もちろん、モノリシックアプリはモジュール化することもできます。データベースは正規化されています... マイクロサービスは固体鋼で分離されています。

あなたのユーザーシステムが文字通り発火した場合、それはインベントリシステムに少しも影響を与えません。誰が何を在庫したかについてのきれいなレポートを印刷することはできませんが、顧客は在庫のあるアイテムがあることを知っているので安全に注文を出すことができます。

また、リレーショナルデータベース（*）で行うよりも、microservicesでデータを複製することはありません。リレーショナルデータベースでは、結合を行うことができます。これに相当するのは、説明したようなコードのリストをマージすることです。

ビューを追加することもできますが、同等の方法は、マージを行う新しいサービスを追加することです。その結果、3つの要求が発生します。1つは新しいサービスに、それからそのサービスは元の2つを行います。リレーショナルデータベースには、ビューを最適化する派手なものがあり、サービスレベルで実装する必要があります。「無料」では入手できません。

2つの値が一致しない場合、どちらが間違っているかがわかるという点で、キャッシュはデータ複製とは異なります。多くの場合、一貫性を犠牲にして可用性を高めるためにマイクロサービスで使用されます（CAP定理）。リレーショナルデータベースは一貫性の祭壇で可用性を完全に犠牲にしているため、あまり一般的ではありません。マイクロサービスには、キャッシングを簡単にする固有のものは何もないと思いますが、実際にはキャッシングが主な関心事であり、マイクロサービスでキャッシングを簡単にします。

（*）マイクロサービスの群れでデータを複製することが理にかなっている場合、おそらく同等のリレーショナルデータベースで意味があるでしょう。