3

これはJava中心の質問ですが、実際には多層アーキテクチャを利用するすべてのシステムに当てはまります。

3層アーキテクチャでは、通常、次の3つの層があります。

  • クライアントコードが存在するクライアント/プレゼンテーション層。と
  • ビジネスロジックが存在するミドルウェア層。と
  • RDBMSやその他のデータ量の多いシステムが存在するデータ/eis層

Javaランドでは、Webアプリケーションの場合、これは次のようになります。

  • GlassFish「Web層」（Webアプリのクライアント層を構成するWAR）と「ビジネス層」（EJB、ミドルウェアなど）の両方を実行するようなアプリケーションサーバー。と
  • データ層を具体化するRDBMSサーバー

仮想化/クラスター化された環境では、これらのアプリケーション（GlassFish、OracleやPostgreSQLなどのRBMBSなど）はVM上で実行されます。

私の質問：これらのVM間でこの3層アーキテクチャを割り当て/配布する標準的な方法は何ですか？つまり、次の「戦略」のいずれかが実行可能である可能性がありますが、優先的ではありません。

  1. GlassFishとRDBMS（3層すべて）の両方を実行する1つのVM（たとえば、すべてのVMがUbuntuサーバーであるため、コスト/価格は方程式に考慮されません）
  2. 2つのVM：GlassFishを実行しているアプリケーションサーバーVMと、PostgreSQLなどを実行しているデータベースサーバーVM
  3. 3つのVM：2つのアプリサーバーVMは両方ともGlassFishを実行していますが、1つのGlassFishインスタンスはWAR（Web層）のみを実行していますが、2番目のFlassFishインスタンスはミドルウェア/ビズロジックを実行しています。次に、3番目のDBサーバー

明らかに、すべてのサーバー（すべての層）が同じVMで実行されている場合、ネットワークの遅延に悩まされることはないため、サーバーはより高速またはより効率的に実行される可能性があります。ただし、それらは同じVM上にあるため、それらをサポートするにはメガハードウェアが必要になります。この設定にはセキュリティ上の懸念もあるかもしれません。

それぞれに長所/短所があります。次の目標を最もよく達成する戦略に興味があります。（1）スループット/速度を最大化する、（2）クラスター化/クラウド環境に最適、（3）セキュリティを最大化する。

前もって感謝します！

4

2 に答える 2

2

（1）スループット/速度を最大化します。

これは完全にアプリケーションに依存します。たとえば、データベースがボトルネックになる可能性があります。その場合、JVMで何をするかが非常に重要になります。

（2）クラスター/クラウド環境に最適

システムを配布する場合は、プレゼンテーション層を配布することをお勧めします。これは、彼らが行う作業はクライアントの数に依存し、各クライアントが行う作業はほとんど独立しているためです。（プレゼンテーション層内）

（3）セキュリティを最大化します。

VMの数が増えても、セキュリティの向上は保証されません。JVMで実行されているさまざまなアプリケーションがとにかくかなり分離されるように、JVMをセットアップする必要があります。攻撃の拒否を防ぎたい場合で、バックエンドサービスが他のシステムで使用されている場合は、それらを分離することをお勧めします。それ以外の場合は、大きな違いはありません。

于 2012-01-09T16:59:23.430 に答える
1

あなたの質問への答えは、このアプリケーションの動作やデータベースの使用状況などに大きく依存していると思います。現在のパフォーマンスメトリックを確認しないと何も言えません（他の答えはすでに述べています）。私は自分の考えのいくつかをガイドラインとして投稿します。

データベース

ほとんどの組織は別々のホストでRDBMSを実行しており、一部のエンジニアは、DBベンダーのベストプラクティスが彼らのケースについて何を言っているかに応じて、これらを仮想化しないことを選択します（つまり、私は通常、VMを物理ホストと同等と見なし、いつでも使用します可能）。

パフォーマンスの面では、RDBMSはカーネルの調整または型破りなファイルシステム戦略を必要とすることが多く、それらを別々のホストに配置すると役立つ場合があります。DBを高可用性モードまたはクラスターでセットアップする必要がある場合は、DBをアプリケーションサーバーから分離することで作業を簡単にすることもできます。データベースの調整は、それを行う必要がある場合、真剣に受け止めれば難しいトピックになる可能性があることに注意してください。これには、ディスク内のパーティションの調整、データベースデータセグメント/ファイルの巧妙な割り当てによるディスクヘッドの移動の削減などが含まれることがよくあります。 DBMSとOSのキャッシュサイズと戦略...これはすべて、同じホストで実行されている他のアプリケーションに影響を与える可能性があるため、DBをそのままにしておきます。

さらに、RDBMSは多くの場合複数のアプリケーションにサービスを提供します（これには十分な理由があります。一部の統合では、複数のアプリケーションデータベースへのアクセスが必要になる場合があります）。それらをアプリケーションサーバーから分離しておくと役立ちます。

また、DBシステムには独自のアップグレード、バックアップ、配布/クラスタリング、および管理手順があり、多くの場合、アプリケーションサーバーとは異なる人によって保守されます。したがって、データベース管理のトピック全体を個別に検討すると、扱いやすくなります。また、データベースがボトルネックになった場合、他の層がパフォーマンスに影響を与えているかどうかを考慮せずに、データベースだけで作業できます。

適度なサイズの本番環境では、RDBMSを単一のホストに単独で保持することをお勧めします。ただし、もちろん、パフォーマンス、管理、または可用性の要件がない場合は、すべてに共有サーバーを使用することを検討できます。

Glassfish

一般的に、Java EEアプリケーションを複数のサーバーにデプロイする場合（負荷分散または高可用性のため）、クラスター内のすべてのアプリケーションサーバーに同じアプリケーションサーバーと成果物をインストールします。次に、クラスターの各ノードで有効にするアーティファクトを選択できます。一部のアプリケーションサーバーは、サーバーの負荷に応じてコンポーネントを有効または無効にできます。この場合、アプリケーションサーバーは配布する必要のある「ユニット」です。

現在、あなたまたはあなたの組織が、Web層とビジネス層のネットワーク層を完全に分離することを好む場合があります（つまり、セキュリティ上の懸念）。この場合、これには別のホストを使用します。Web層が非常に重く、ビジネス層とは別にスケーリングする必要がある場合（つまり、6つのWebサーバーが必要であるが、1つまたは2つのEJBコンテナーで作成できる場合）、これら2つの層を分離します。それも。

注：同じGlassfishインスタンスでWeb層とEJB層を実行することには、わずかな利点があります。これらはJVMを共有するため、Web層とビジネス層の間の呼び出しで参照による呼び出しセマンティクスを使用できます。作業負荷と応答のサイズおよびシリアル化コストによっては、これによりパフォーマンスが著しく向上する可能性があります。

ほとんどの場合、多くの企業アプリケーションでは、両方のレイヤーを含む1つまたは2つのサーバー（高可用性が必要かどうかに応じて）を使用します。これは、負荷が増加しても、垂直方向（サーバーの電力またはVMリソースを増やす）または水平方向に拡張できるためです。 （別のサーバーと負荷分散要求を追加します）。

世界的に利用可能でスループットの高いアプリケーションは、スケーラブルにするために他の多くの側面を考慮する必要があります（Java EEクラスターノードにノードを追加するだけではカットされません）。したがって、このソリューションのいずれも優れているとは思いません。 「クラウド」にデプロイするためにはさらに悪いことですが、一般的に、エラスティック仮想化サービスにデプロイすることを計画していて、要件がそれを正当化する場合は、Web層とビジネス層を分離することをお勧めします。

安全

私の意見では、議論されたトピックはセキュリティに直接影響を与えません。

最後に、このトピックについてはもっと多くのことが言えると確信しており、私の経験は限られているので、もっと意見を聞いてください;）。

于 2012-01-09T17:32:26.857 に答える