5

JBoss EAP 6.1 にデプロイする JavaEE 6 ベースのアプリケーションを開発中です。アプリには、Web 管理コンソールと RESTful サービス API という 2 つの主要なプレゼンテーション メカニズムがあります。バックエンドでは、管理コンソールと RESTful サービス API の両方が、一連の EJB を使用してトランザクション ロジックを実行し、POJO サービスを使用してデータを取得します。

これらのさまざまなレイヤーのすべてでパフォーマンスとリソースのニーズが異なる可能性は十分にあります。RESTful サービスはかなりシンで完全にステートレスですが、管理コンソールはステートフルでよりインタラクティブな機能を備えています (したがって、より多くのメモリと処理が必要になります)。EJB は主要なトランザクション ビジネス ロジックを実行するため、単純にデータベースにクエリを実行する POJO データ サービスよりも多くの処理能力を必要とします。

このようなセットアップが与えられた場合、これらすべてのコンポーネントを含む単一の EAR (クラスター化された構成の複数のアプリケーション サーバー) を展開するか、個々のコンポーネントを個別の EAR に分割する方が理にかなっていますか? 個別の EAR に関する私の考えでは、たとえば、EJB サービスにスケーラビリティの問題があることがわかった場合は、Web コンソール (たとえば) が問題なくスケーリングされていても、EJB サービスのインスタンスをさらにデプロイできます。

各レイヤー/コンポーネントのスケーラビリティが異なるという事実を考えると、どのようなアプローチを取る必要がありますか? EAR 間でリモート EJB 呼び出しを行わなければならないというオーバーヘッドは、そのようなモデルを検討するには高すぎますか? どんなアドバイスも大歓迎です！

4

2 に答える 2

5

「Java EE」の方法は、アプリケーションを単一の EAR としてクラスターにデプロイすることです。REST/管理コンソールから EJB へのローカル インターフェイス呼び出しを使用していると仮定します。セッション レプリケーションが必要ない場合 (スティッキー セッションを使用できます)、スケーラビリティは非常に優れています。

必要な唯一の追加要素は、Web アプリケーションのロード バランサーです (たとえば、SSL デコード、静的リソースの提供、および場合によってはキャッシュ可能な要求のキャッシュも処理する Apache サーバー)。

このようなセットアップの唯一の問題は、負荷が大きい場合に発生する可能性があります。たとえば、EJB が多くのサーバー リソースを消費する可能性があるため、Web アプリケーションのスループットを制御するのが難しく、EJB によって悪影響を受ける可能性があります。スティッキー セッションを使用すると、ユーザーは常に同じサーバーにリダイレクトされるため、ユーザー セッションが続く限り、一部のユーザーを負荷の低いサーバーに移動する機会はありません。

そのため、高負荷を計画している場合は、Web アプリケーションと EJB を別々のボックス (または仮想マシン) に保持するのが理にかなっています。これにより、ボトルネックを特定しやすくなり、それを必要とするレイヤーを簡単にスケーリングできます。

これに対するペナルティは次のようになります。

  1. EJB へのリモート呼び出し。ただし、JBoss 6 にはかなり高度な EJB プーリング構成があるため、それほど深刻な問題ではない可能性があります。
  2. これらのリモート呼び出しによって引き起こされるネットワーク トラフィック (したがって、EJB と Web レイヤーの間で大量のデータを渡すと、問題になる可能性があります)。
于 2013-05-21T16:16:37.543 に答える