データ アクセス レイヤのローカル EJB とリモート EJB のどちらを使用するかを決定しようとしています。多くの調査を通じて、スケーラビリティが必要な場合はリモート EJB を使用する必要があるというのが一般的なコンセンサスのようです。
それはどういう意味ですか？リモート EJB はスケーリングでき、ローカルはスケーリングできない理由を明示的に示すものは見つかりません。
4 に答える
0
古典的な Java EE シナリオについて話していると思います。
client (usually browser) ----> Servlet ----> EJB ----> DB
その場合、サーブレットと EJB を同じ場所に配置してローカル インターフェイスを使用するか、サーブレットと EJB を別々のレイヤーに配置してリモート インターフェイスが必要になる可能性があります。 .
最初にローカル シナリオをスケーリングすることを検討してください。サーブレット/EJB エンジンは蒸気を使い果たしたので、別のエンジンをデプロイして、より多くの電力を取得します (明らかに、サーブレットの前にある噴霧器が作業を分散する必要があります。より多くの電力が必要であり、さらに多くのサーブレット/EJB レイヤーを追加します。うまくスケールします。しかし ...
EJB レイヤーがたまたま非常に重く、おそらくデータを取得した後に複雑な計算を行っているとします。必要なパフォーマンスを達成するために、結合されたサーブレット/EJB レイヤーをスケーリングしますが、サーブレット エンジンのこれらすべてのコピーは必要ありませんでした。それらはほとんど作業を行っておらず、すべての作業は EJB レイヤーで行われ、メモリやその他のリソースを消費します。理由もなく。このようなシナリオでは、リモート EJB を使用すると有利になる可能性があります。個別にデプロイして、サーブレット エンジンと EJB エンジンのコピーを必要なだけ取得できます。リモート ホップのコストは、複雑な計算コストと比較して無視できる場合があります。 .
于 2013-09-11T20:32:18.307 に答える
0
まあ、私は受け入れられた答えを理解していますが、リモート EJB の使用は、必ずしも複数のサーバーに分散されたビジネス ロジックを意味するわけではありません。
リモート EJB を使用したスケーラビリティの良い例は、API ゲートウェイです。API ゲートウェイを EJB クライアント (例では単一の WAR) として構成して、ビジネス ロジックを含むさまざまなサーバー (例では EAR) からリモート EJB を使用できます。
この考え方を使用すると、複数のサーバーを使用して API ゲートウェイにリモート EJB を提供し、それぞれのすべてのサーバーに作業を分散させることができますlookup。
于 2017-02-21T13:35:08.897 に答える