Java WAR を実動サーバー (クラスターなし、OSGi なし) に再デプロイする「スムーズな方法」があるかどうか疑問に思っていました。
私が思いつくことができるのは、サーバーを停止し、ファイルを更新し、サーバーを再起動することだけです。そして、10分前にサイトにメンテナンス警告を表示する必要があります.
あなたのアプローチは何ですか？
3829 次
6 に答える
8
まず、hot-deployは常に機能するとは限りません。すべての新しいモジュールがロードされていることを確認するために多くの時間を費やし、問題を起こす価値がないと判断しました。したがって、あなたがしていることは悪いように聞こえるかもしれませんが、それは新しいWARを展開するための最も信頼できる方法です。
現在のアプローチは、すべてのサーバーの前にロードバランサーを備えたスイッチを使用することです。アプリケーションサーバーのインスタンスを少なくとも2つ実行します。メンテナンスのために一方のサーバーをシャットダウンすると、トラフィックは自動的にもう一方のサーバーに送られます。
一部のスイッチは本当に安価です。新しいボックスを正当化するのに十分な負荷がなく、2つのインスタンスを同じボックスで実行できる場合。
状況によっては、スイッチは実際にお金を節約することができます。たとえば、以前は6つのボックスを使用していたSSLページがあり、スイッチでSSLアクセラレーションを使用すると2つのボックスで正常に実行されるようになりました。
于 2010-05-31T15:38:02.983 に答える
1
JRebelを見たことがあるかもしれませんが、本番環境では使用しません。本番環境でも基本的に同じことを行いますが、上司は常にホット再デプロイを夢見ています。残念ながら、それらはほとんど紙の上でサポートされています。ほとんどの複雑なアプリケーションでは、ホット再デプロイで常に何かがうまくいかないことがあります。増分ホット再デプロイについても同じことが当てはまります...
于 2010-05-31T15:01:55.977 に答える
1
一部のアプリケーション サーバーは、サービスを中断することなく再展開をサポートします。これは、少なくとも WebLogic には当てはまります。Using Production Redeployment to Update Applications を参照してください。これはホット デプロイではないことに注意してください(また、運用サーバーでホット デプロイを使用することは決してありません)。
アプリケーション サーバーのサポートがなければ、本当の「スムーズな」再展開を行うことはできません。ダウンタイムを最小限に抑えるには、新しいアプリケーションを並行して (同じサーバーまたは別のサーバーに) デプロイし、完了したらルーティング ルールを変更する方法があります。ただし、クライアントはセッションを失います。
于 2010-05-31T15:51:22.777 に答える
1
通常、起動時間を最適化することは可能です。私たちの Web アプリケーションは、5 ～ 7 秒で Jetty から開始されます。他の Java Web サーバーは、起動が非常に遅いため、さらに悪化します。
また、私が知っているように (私はしませんでした)、フロントエンド Web サーバー (apache など、lighttpd を使用) は、Jetty が処理されている間、リクエストを一定期間 (私たちのサーバーでは最大 30 秒) 保持するように構成できます。準備ができていません。そのため、デプロイ中に Jetty を簡単に再起動するだけで、ユーザーは最悪の場合でも数秒の遅延が発生するだけです。これは通常、インターネット接続の不具合のように見えます。
于 2010-09-03T07:51:05.890 に答える
0
通常、mv old.war new.warそこから AS に任せますが、非常に忙しい 24 時間年中無休のサービスでは、これはオプションではないと思います。
于 2010-05-31T15:27:28.973 に答える
0
ZZ Coder がすでに言及しているように、ロード バランサーは特に大規模な展開に適したソリューションです。私自身のプロジェクトでは、nginx Web サーバーのリバース HTTP プロキシ機能を使用しています。指定された Web コンテキスト (インターネットから見たもの) からすべての http パケットをネットワーク内のサーバーにリダイレクトします。設定はとても簡単です:
location /best-app-ever/ {
proxy_pass host-address:8080/some-app-1.1
root /home/www/some-app-1.1
}
バージョンの切り替えもスムーズです。アプリケーションの新しいバージョンをすでにデプロイしていると仮定すると、nginx 構成ファイルを変更して変更を適用するだけです。
location /best-app-ever/ {
proxy_pass host-address:8080/some-app-1.2
root /home/www/some-app-1.2
}
sudo nginx -t
sudo service nginx restart
Web アプリケーションがステートフルな場合や、実行中またはスケジュール済みのプロセスが含まれている場合は、デプロイとアンデプロイがスムーズに行われない可能性があることに注意してください。
于 2014-07-30T08:44:49.923 に答える