11

1 つの WAR ( app.war ) と 1 つのコンテナー (Tomcat、Jetty、Glassfish など) があります。私の目標は、この同じ Web アプリケーションの何百ものインスタンスをコンテナーにオンデマンドでデプロイすることです。

http://foo/app1 --> app.war
http://foo/app2 --> app.war
http://foo/app3 --> app.war 
...
http://foo/appN --> app.war

これを達成するいくつかの明白な方法:

  • Tomcat で、アプリごとに 1 つの context.xml ファイル ( appN.xml という名前) を作成し、すべてが同じ WAR を指すようにします。他のコンテナにも同様の方法があります
    • このアプローチの問題: WAR N 回爆発し、多くのディスク領域を占有します。
  • シンボリック リンクを使用して、展開されたバージョンの app.war を指す webapp/{app1,app2,appN} フォルダーを作成します。これにより、ディスク容量の爆発は防止されますが、JVM は依然として多くの重複した JAR をメモリにロードしています。
  • 一部の共有 lib フォルダーを使用して、ほとんどの jar (および前の 2 つのオプションの組み合わせ) を含めます。

これを行うためのより良い方法があるかどうか疑問に思います。理想的には、新しいインスタンスを作成する際に (限界構成ファイル以外の) ディスク領域をまったく消費せず、スレッド実行スタックやその他のランタイム割り当てに関連するメモリのみを消費する必要があります。

何か案は？

4

5 に答える 5

5

Jetty は、オーバーレイと呼ばれるものを使用して、探しているもののサポートを追加しました。

http://wiki.eclipse.org/Jetty/Tutorial/Configuring_the_Jetty_Overlay_Deployer

wikiページから少しコピー：

  • どのバージョンを展開したかが明確になるように、WAR ファイルを不変 (署名済みであっても) に保つことができます。
  • Web アプリケーションをカスタマイズ/構成するために行ったすべての変更は個別の WAR であるため、レビューや新しいバージョンへの移行のために簡単に識別できます。
  • Web アプリケーションの多くのインスタンスに適用される共通のカスタマイズと構成を含むパラメーター化されたテンプレート オーバーレイを作成できます (マルチテナント展開など)。
  • 階層化されたデプロイメントでは、共通コンポーネントとインスタンス固有のコンポーネントが明確に識別されるため、Jetty はテンプレートのクラスローダーと静的リソース キャッシュを共有でき、複数のインスタンスのメモリ フットプリントを大幅に削減できます。
于 2012-04-17T17:56:52.693 に答える
2

少し話題から外れて申し訳ありませんが、私の見解では、シナリオは「マルチテナンシー」アプリケーションを叫んでいるため、複数の「テナント」（顧客）にサービスを提供する単一のアプリケーションがあります。

マルチテナンシーのセットアップに関しては、次の考慮事項を考慮する必要があります。

マルチテナンシーの利点:

  • 共有コードとは、1 人の顧客に対して修正されたバグがすべての顧客に対して修正されることを意味します (これは、何がバグを構成し、何が機能を構成するかについて、さまざまな顧客が異なる見解を持っている場合にも不利になる可能性があります)。
  • クラスタ化された展開では、顧客間で負荷を共有できます (ただし、すべての顧客がピーク容量を利用できるようにする必要があります)。

欠点:

  • 顧客同士のデータを誤って公開することなく、顧客間の「差別」が機能することをクエリで確認する必要があるため、コードはもう少し複雑になります。
于 2012-04-17T09:07:22.440 に答える
1

フロントエンド（mod_proxy / mod_proxy_ajp）でApacheを設定して、名前付き仮想ホストがTomcatにデプロイされた単一のWARを指すようにすることができます。アプリケーションは、すべてのリクエストを処理するように設計/作成する必要があります。ウェブサイト名ごとに、特定の構成をデータベースに保存するか、アプリケーション内の構成ファイルとして保存できます。アプリは、ユーザーのリクエストするドメイン名をプローブするだけで済みます。正しい設定が適用されていることを確認します（セッションごとに1回）。一般的に言えば、1つのアプリケーションでこれを解決できるはずです。優れた開発者はLAZYです。

于 2012-04-17T01:07:37.390 に答える
0

これが実験用である場合は、リストした方法のいずれかが機能します。

これが本番用の場合は、これをお勧めしません。すべてのコンテナーをテストしたわけではありませんが、使用したコンテナーから、コンテナーを使用してヘッドレス VM を単純にプロビジョニングする方がはるかに回復力があると信じています。Linux VM は非常に小さい場合があり、VM テクノロジを使用すると、必要な数のインスタンスを追加または削除できます。

動的に成長するソリューションが本当に必要な場合は、世界全体を 1 つにまとめようとするのではなく、単一障害点を排除するように努める必要があります。

「秒まで」の負荷の拡張/縮小が本当に必要な場合は、AWS または CloudFoundry を検討する必要があります。

于 2012-04-17T01:34:16.960 に答える
0

Jetty を使用している場合は、プログラムでコンテキストを追加できます。

WebAppContext webapp = new WebAppContext();
webapp.setBaseResource(myBaseDirectory);
webapp.setContextPath(myContextPath);

すべてのコンテキストに対してループでこれを行うだけです。ディスクスペースのオーバーヘッドはゼロに近いはずです。

おそらくTomcatでも同様の方法があります。

于 2012-04-17T01:58:42.883 に答える