シーンの説明
マイクロサービスアーキテクチャでは、各マイクロサービスが独自のデータベースを担当し、マイクロサービスAがマイクロサービスBのデータベースに直接接続して操作することは許可されていません。
2つのマイクロサービスがあります。1つは注文サービスで、もう1つはユーザーサービスです。
データレポートの要件があります。ユーザー情報を含む注文レポートを生成するためです。
これには、接続と集約のために2つのサービスでデータを取得する必要があります。
このデータレポートサービスを構築するにはどうすればよいですか？
シナリオ1データベースに直接接続する
注文サービスとユーザーサービスのデータベースに直接接続し、必要なデータを取得し、取得後に処理します。
非常に単純ですが、明らかな問題があります。
1つ目は、上記のマイクロサービスの原則を破壊することです。他の人のデータベースに直接接続するには失礼です。
さらに深刻な問題があります。注文サービスとユーザーサービスのデータベーステーブル構造が変更された場合はどうなりますか？
レポートサービスもそれに合わせて変更する必要があり、感度が高すぎます。
スキーム2データコンバージェンス
データは直接接続されていません。これら2つのサービスのRESTAPIインターフェースを呼び出して、必要なデータを取得してください。
前の解決策の問題は解決されましたが、この方法の最大の問題はパフォーマンスの低下です。
レポートサービスは最新のデータを必要とし、これら2つのサービスに頻繁にアクセスします。データサイズが大きくなると、3つのサービスのパフォーマンスはますます低下します。
解決策3データをバッチでプルする
レポートサービス用に独自のデータベースを作成し、タイミングプログラムを使用して、2つのサービスのデータベースからデータをバッチでプルし、それらを独自のデータベースに保存します。
以前のソリューションの問題は解決され、パフォーマンスは大幅に向上しましたが、マイクロサービスの原則を破り、データテーブル構造の変更に非常に敏感であるため、最初のソリューションの問題に戻ったようです。
利点は、独自のデータベースがあるため、はるかに便利でパフォーマンスが向上することです。
シナリオ4イベントプッシュモデル
オーダーサービスとユーザーサービスでは、データテーブルが更新された後、イベントが生成され、メッセージシステム（kafkaなど）に公開され、レポートサービスが関連トピックをサブスクライブし、受信したデータが独自のデータベースに書き込まれます。
利点：
-
疎結合では、ビジネスインターフェイス層であろうとデータベース層であろうと、ビジネスサービスとレポートサービスの間に呼び出し関係はありません。
-
データの整合性は良好で、ほぼリアルタイムで、ビジネスサービスのデータテーブルが更新された直後にイベントメッセージが送信され、レポートサービスをすばやく利用できます。
-
パフォーマンスは良好です。データスループットが向上した後、レポートサービスはイベントを処理するためのワーカーを増やし、処理機能を提供できます。
- スケーラビリティが高く、リアルタイム分析などのデータ処理要件を将来的に追加すると便利です。将来的には、注文レポートを実行するだけでなく、より多くのビジネスシステムデータを分析する可能性があります。その時点で、新しいサービス独自のデータ変更イベントを追加するだけで、メッセージシステムに送信できます。
最後に書く
私の公開アカウント[風と波はコードと同じくらい静かです]、多数のJava関連の記事、学習資料が更新され、ソートされた資料もそこに配置されます。
文章が良いと思うなら、それと同じようにフォロワーを追加してください！注意してください、迷子にならないでください、更新を続けてください！！！