私はDatawarehouseアプリケーションにMicroservicesを適用します。マイクロサービスのボトルネックを避ける
1）データサービス：外部データソースをDWHにインポート/エクスポートし、DWHからクエリデータをインポートします。
2）分析サービス：UI
3のグラフの可視化のための）機械学習：推薦システムの
4）レポート：
を報告するための以下のよう
図を生成します
各サービスは独自のDBを持ち、TCPとThを介して直接通信しますift直列化。ここでの問題は、データサービスが他のサービスからの負荷が高く、アプリケーションのSPOFになる可能性があることです。 DWHのデータも大きすぎます（おそらく最大100万のレコード）。この場合、データサービスのボトルネックを回避する方法は？または、ボトルネックを避けるために、正しくバインドされたコンテキストを定義するにはどうすればよいですか？
あなたは、いくつかのビジネスロジックに基づいて、およそ
Data Serviceを分割すると思うかもしれ。Data Service（必要に応じて）複数のサービスインスタンスをサポートするように変更します。次に、ロードバランサを使用して、それらのインスタンス間でリクエストを分割します。ロードバランサは、リバースプロキシとして動作し、サーバの数を横切っネットワークまたはアプリケーショントラフィックを配信する装置です。ロードバランサは、容量（同時ユーザー）とアプリケーションの信頼性を高めるために使用されます。 「一つのデータベース、複数のサービス」について
：
各microserviceはそうでない場合、あなたは分解していない、独自のデータストレージを持っている必要があります。私たちは、関係データベースについて話している場合、これは以下のパターンのいずれかを使用して達成することができます。サービスごと
Data WarehouseデータベースとData Serviceから別々のテーブルを使用して、あなたのサービスが唯一の任意の追加の処理ロジックなしでデータベースへのアクセス層を提供している場合は、[はい、あなたはData Serviceを削除し、対応するサービスへのデータアクセスロジックを移動させることができます。しかし、もう一つの手で考えてみてください。今は、という1つの場所しか持っておらず、Data Warehouseでどのようにアクセスして操作するのか、それはマイクロサービスについてです。
他のマイクロサービス（Analytics、Reports、MLなど）にDWHデータベースに直接アクセスさせることはできますか？この場合、「1つのデータベース、複数のサービス」になります。 DWHのデータは大きく、データは定期的に更新されるためです。 – Barcelona
@Barcelona私は答えを – Set
更新しました。DataService（DS）は、データアクセスロジック（基本CRUD）のみを他のサービスに提供し、他の処理ロジックは提供しません。他の処理ロジック（インポート、エクスポートなど）は、クライアント呼び出し用です。 DWHへのアクセス、クエリ、および他のサービスへの更新方法のロジックを隠すために、他のサービスとDSとの通信を許可する理由です。他のサービスはDSを呼び出してデータを取得または更新します。 – Barcelona