モノリシックアプリケーションをマイクロサービスに分割している人々にとって、データベースをバラバラにするという難問をどのように処理していますか。私が取り組んだ典型的なアプリケーションは、パフォーマンスと単純さの理由から、多くのデータベース統合を行います。
論理的に異なる2つのテーブル(制限されたコンテキストがある場合)があり、そのデータの大容量で集約処理を頻繁に行う場合、モノリスではオブジェクト指向を避け、代わりにデータベースの標準を使用している可能性が高い統合されたビューをアプリ層に戻す前に、データベース上のデータを処理する機能に参加します。
データベースではなくAPIを介してデータを「結合」する必要があると思われる場合、そのようなデータをマイクロサービスに分割することをどのように正当化しますか。
私はサム・ニューマンのマイクロサービスの本を読んでおり、モノリスの分割の章で彼はAPIを介した結合の実行が遅くなることを認めている「Breaking Foreign Key Relationships」の例を挙げていますが、あなたのアプリケーションはとにかく十分に高速です、それが以前より遅いことは重要ですか?
これは少しglibのようですか?人々の経験は何ですか? API結合のパフォーマンスを許容範囲内にするためにどのようなテクニックを使用しましたか?
パフォーマンスやレイテンシーがそれほど重要でない場合(はい、必ずしも必要ではありません)、必要な追加データのクエリに単純なRESTful APIを使用するだけで十分です。異なるマイクロサービスに対して複数の呼び出しを行い、1つの結果を返す必要がある場合は、 API Gateway パターンを使用できます。
Polyglot persistence 環境で冗長性を持たせても大丈夫です。たとえば、マイクロサービスにメッセージングキューを使用して、何かを変更するたびに「更新」イベントを送信できます。他のマイクロサービスは必要なイベントをリッスンし、データをローカルに保存します。したがって、クエリを実行する代わりに、特定のマイクロサービスの適切なストレージにすべての必要なデータを保持します。
また、キャッシングについても忘れないでください:) Redis や Memcached などのツールを使用して、他のデータベースへの頻繁なクエリを回避できます。
サービスが他のサービスからの特定の参照データの読み取り専用の複製コピーを持つことは問題ありません。
それを考えると、モノリシックデータベースをマイクロサービスにリファクタリングしようとすると(書き換えではなく)
これにより、他のアプリケーションを中断することなく、テーブルデータ/構造を個別に変更できます。
ビューを使用するのではなく、トリガーを使用して、あるスキーマから別のスキーマにデータを複製することも検討できます。
これは、コンポーネントの継ぎ目を確立する正しい方向への漸進的な進歩であり、RESTへの移動は後で行うことができます。
*ビューは拡張できます。重大な変更が必要な場合は、同じビューのv2を作成し、不要になった古いバージョンを削除します。 **またはテーブル値関数、またはSproc。
CQRS ---コマンドクエリ集約パターンは、Chris Richardsonによるthiの答えです。各マイクロサービスが独自のデータモデルを更新し、以前のマイクロサービスからの必要な結合データを持つマテリアライズドビューを更新するイベントを生成するようにします。このMVは、クエリ最適化されたNoSql DBまたはRedisまたはelasticsearchです。この手法により、最終的に一貫性が確保されますが、これは決して悪くはなく、リアルタイムのアプリケーション側の参加を回避します。これが答えを願っています。
運用領域とレポート機能など、使用分野ごとにソリューションを分離します。
他のマイクロサービスからのデータを必要とする単一のフォームにデータを提供するために動作するマイクロサービスの場合(これは動作上のケースです)、API結合を使用する方法が良いと思います。大量のデータは必要ありません。サービスでデータ統合を行うことができます。
もう1つのケースは、集計などを行うために大量のデータに対して大きなクエリを実行する必要がある場合です(レポートケース)。この必要性のために、元のスキームと同様に共有データベースを維持し、マイクロサービスデータベースからのイベントで更新することを検討します。この共有データベースでは、ストアドプロシージャを引き続き使用できます。これにより、労力を節約し、データベースの最適化をサポートできます。
マイクロサービスでは、差分を作成します。モデルを読むので、例えば:diffが2つある場合。バインドされたコンテキストと誰かが両方のデータを検索したい場合、誰かが両方のバインドされたコンテキストからイベントをリッスンし、アプリケーション固有のビューを作成する必要があります。
この場合、より多くのスペースが必要になりますが、結合も結合も必要ありません。