web-dev-qa-db-ja.com

マイクロサービス間のデータ共有

現在のアーキテクチャ：

enter image description here

問題：

フロントエンドレイヤーとバックエンドレイヤーの間には2段階のフローがあります。

  • 最初のステップ：フロントエンドは、マイクロサービス1（MS1）上のユーザーからの入力I1を検証します
  • 2番目のステップ：フロントエンドはI1および詳細情報をマイクロサービス2に送信します

マイクロサービス2（MS2）は、I1の整合性を検証する必要があります（フロントエンドから送信されるため）。 MS1への新しいクエリを回避する方法最善のアプローチは何ですか？

ステップ1.3と2.3を削除して最適化しようとしているフロー

フロー1：

  • 1.1ユーザーXはMS2にデータ（MS2_Data）を要求します
  • 1.2ユーザーXはMS1でデータ（MS2_Data + MS1_Data）を保持します
  • 1.3 MS1は、B2B HTTP要求を使用してMS2_Dataの整合性をチェックします
  • 1.4 MS1は、MS2_DataとMS1_Dataを使用してデータベース1を永続化し、HTTP応答を作成します。

フロー2：

  • 2.1ユーザーXには既にローカル/セッションストレージにデータ（MS2_Data）が保存されています
  • 2.2ユーザーXはMS1でデータ（MS2_Data + MS1_Data）を保持します
  • 2.3 MS1は、B2B HTTP要求を使用してMS2_Dataの整合性をチェックします
  • 2.4 MS1は、MS2_DataとMS1_Dataを使用して永続化し、データベース1とHTTP応答を構築します。

アプローチ

考えられるアプローチの1つは、MS2とMS1の間でB2B HTTP要求を使用することですが、最初のステップで検証を複製します。別のアプローチでは、MS1からMS2にデータを複製します。ただし、これはデータ量とボラティリティの性質のために禁止されています。複製は実行可能なオプションではないようです。

より適切なソリューションは、マイクロサービス2でマイクロサービス1が必要とするすべての情報をフェッチし、マイクロサービス2に配信する責任をフロントエンドが負うという私の意見です。これにより、このB2B HTTP要求がすべて回避されます。

問題は、マイクロサービス1がフロントエンドから送信された情報をどのように信頼できるかです。おそらく [〜＃〜] jwt [〜＃〜] を使用して、マイクロサービス1とマイクロサービス2からのデータに何らかの方法で署名すると、メッセージを検証できます。

注マイクロサービス2がマイクロサービス1からの情報を必要とするたびに、B2B http要求が実行されます。 （HTTPリクエストは [〜＃〜] etag [〜＃〜] および Cache Control：max-age を使用します。これを避ける方法は？

アーキテクチャの目標

enter image description here

マイクロサービス1は、MS1データベースでMS1_DataおよびMS2_Dataを永続化できるように、オンデマンドでマイクロサービス2からのデータを必要とするため、ブローカーを使用するASYNCアプローチはここでは適用されません。

私の質問は、この種の推力コミュニケーションを可能にするデザインパターン、ベストプラクティス、またはフレームワークが存在するかどうかです。

現在のアーキテクチャの欠点は、各マイクロサービス間で実行されるB2B HTTP要求の数です。キャッシュ制御メカニズムを使用しても、各マイクロサービスの応答時間は影響を受けます。各マイクロサービスの応答時間は非常に重要です。ここでの目標は、パフォーマンスの向上と、フロントエンドをゲートウェイとして使用して複数のマイクロサービスにデータを分散する方法をアーカイブすることですが、スラスト通信を使用します。

MS2_Dataは、MS1がデータの整合性を維持するために使用する必要がある製品SIDやベンダーSIDのようなエンティティSIDです。

可能な解決策

enter image description here

アイデアは、MS1およびMS2からのHTTP応答をキャッシュし、それらをMS2 SDKおよびMS1 SDKへの応答として使用するAPIゲートウェイ要求処理としてゲートウェイを使用することです。この方法では、MS1とMS2の間で直接通信（SYNC OR ASYNC）が行われることはなく、データの重複も回避されます。

もちろん、上記のソリューションは、マイクロサービス間で共有されるUUID/GUID専用です。完全なデータの場合、イベントバスを使用して、非同期方式でイベントとデータをマイクロサービス全体に分散します（イベントソーシングパターン）。

インスピレーション： https://aws.Amazon.com/api-gateway/ および https://getkong.org/

関連する質問とドキュメント：

design-patternsarchitecturemicroservicesaws-api-gatewaydata-sharing
29
Leonel

私の質問のセクション可能な解決策を確認してください：

アイデアは、MS1およびMS2からのHTTP応答をキャッシュし、それらをMS2 SDKおよびMS1 SDKへの応答として使用するAPIゲートウェイ要求処理としてゲートウェイを使用することです。この方法では、MS1とMS2の間で直接通信（SYNC OR ASYNC）が行われることはなく、データの重複も回避されます。

インスピレーション： https://aws.Amazon.com/api-gateway/ および https://getkong.org/

2
Leonel

質問とコメントから、システムのパフォーマンスを向上させるためにブロックを再配置しようとしていることを理解しています。図で説明されているように、microservice1がmicroservice2を照会する代わりに、ゲートウェイがmicroservice2を照会し、microservice1を照会してmicroservice2から情報を提供することをお勧めします。

そのため、これによりシステムのパフォーマンスが大幅に向上するかはわかりませんが、変更はロジックを動かすだけのようです。

状況を改善するには、重要なmicroservice2のパフォーマンスを強化する必要があります。これは、microservice2ソフトウェアのプロファイリングと最適化（垂直スケーリング）によって実行できます。また、負荷分散（水平スケーリング）を導入し、複数のサーバーでmicroservice2を実行できます。この場合に使用される設計パターンは、 サービス負荷分散パターン です。

2
iluwatar

パブリッシュ/サブスクライブパターンを使用して、b2b通信の同期方法を非同期のものに変更することを検討できます。その状況では、サービスの操作はより独立したものになり、b2bリクエストを常に実行する必要がなくなる場合があります。

分散システムで高速化する方法は、非正規化によるものです。 ms2dataがめったに変更されない場合（例：書き換えるよりも読むのであれば、サービス間で複製する必要があります。これを行うことにより、待ち時間と一時的な結合を削減できます。カップリングの側面は、多くの状況で速度よりもさらに重要な場合があります。

Ms2dataが製品に関する情報である場合、ms2はms2dataを含むProductCreatedイベントをバスに発行する必要があります。 Ms1はこのイベントにサブスクライブし、ms2dataを独自のデータベースに格納する必要があります。これで、ms1がms2dataを必要とするときはいつでも、ms2への要求を実行する必要なしにローカルで読み取ります。これが、一時的なデカップリングの意味です。このパターンに従うと、ソリューションの耐障害性が向上し、ms2をシャットダウンしてもms1には影響しません。

マイクロサービスアーキテクチャにおける同期通信の背後にある問題を説明する 良いシリーズの記事 を読むことを検討してください。

関連するSO質問 here および here よく似た問題を議論しているので、見てみましょう。

1
IlliakaillI

ただし、ボックスの「内部」を見ずにソリューションの実行可能性を判断することは困難です。

  • ここで気にすることだけがフロントエンドがデータを改ざんする可能性を阻止することである場合、MS2がフロントエンドに送信するデータパケットの一種の「署名」を作成し、パケットとともにMS1に署名を伝搬できます。署名は、マイクロサービスによって共有されるシードから決定論的に生成された擬似乱数で汚染されたパケットのハッシュにすることができます（したがって、MS1は、追加のB2B HTTP要求を必要とせずにMS2と同じ擬似乱数を再作成できますパケットの整合性）。

  • 私の頭に浮かぶ最初のアイデアは、データの所有権を変更できるかどうかを確認することです。 MS1がMS2のデータのサブセットに頻繁にアクセスする必要がある場合、そのサブセットの所有権をMS2からMS1に移動できる場合があります。

  • 理想的な世界では、マイクロサービスは完全にスタンドアロンであり、それぞれが独自の永続化レイヤーとレプリケーションシステムを備えています。ブローカーは実行可能なソリューションではないと言うので、共有データレイヤーについてはどうでしょうか。

それが役に立てば幸い！

1
lud1977