2

私は Java の世界に少し慣れていないので、Web ポータルを構築するためのベスト プラクティスについていくつか質問があります。だから私の質問は、巨大な戦争ファイルを小さな戦争ファイルに分割することに本当に利点があるということです。私が思いついた唯一のもの：

  • モジュール性: 別々の開発者がサイトの別々の部分で作業し、別々に展開することができます。

  • 整理: サイトの一部が同じコード ベースにない場合は、それらの部分を簡単に見つけることができます。

  • スケーラビリティ: これは、サイトの一部を異なる Web サーバーに展開する場合にのみ意味があります。それらがすべて同じフロントエンド サーバーに展開されている場合、利点はありますか?

私が読んだことによると、ほとんどの人は 1 つの大きな war ファイルが最善の方法であると考えているようです: 冗長性を避け、ワンステップ展開など. では、それを分割する理由はありますか? おそらく、サイトの匿名/パンフレット バージョンと認証済みのバージョンですか?

4

3 に答える 3

1

.war運用担当者は、展開するものが1つしかないことを意味するため、1つの大きなものを好みます。

ただし、Webサイトを快適に個別に分割し.war、他のデプロイされたアーティファクトに影響を与えることなく正直にデプロイおよびアンデプロイでき、この粒度が必要であると確信している場合（YAGNIを参照）、分割します。

于 2012-09-24T19:09:07.143 に答える
1

特定のモジュールに個別のスケーラビリティ、セキュリティ、および信頼性の要件がある場合は、それらを分割できます。理想的には、必要に応じてセキュリティを分離できます。

于 2012-09-24T19:14:09.797 に答える
0

決定に大きな影響を与える可能性のある考慮すべき事項は、次のとおりです。

  1. 異なる依存関係 - クラス A が v1 のライブラリ L を必要とし、クラス B が同じ依存関係を必要とし、異なるバージョン - v2 のみを必要とするとします。両方を同じ war にデプロイすると、それらは同じクラスパスを取得するため、すべての依存関係のバージョンを揃える必要があります。それらを分割すると、一方の戦争で v1 を使用し、もう一方の戦争で v2 を使用できます。また、v1 から v3 にアップグレードする場合、クラス B は古いバージョンのままであるため、クラス A の動作をテストするだけで済みます。したがって、ここでのモジュール性は非常に強力です。
  2. サーバーのロード時間 - war ファイルが多いほど、サーバーの起動に時間がかかります。
  3. メンテナンス - サイズを注意深く監視し、冗長な依存関係を削除しない限り、war ファイルは肥大化する傾向があります。これは簡単な作業ではありません。実行時の依存関係、コンパイル、テスト用、本番用などがあります。それは大変な作業であり、人々はそれを先延ばしにする傾向があります。X個の冗長な依存関係を持つ肥大化したwarファイルが1つある場合、それはXサイズの問題です（ロード時間、各バージョンを保持するために無駄なストレージなど）。Y war ファイルがある場合、問題は X*Y サイズです。
    言い換えれば、7ベッドルームのヴィラよりも1ベッドルームのアパートの方が片付けが簡単です。
于 2016-11-10T14:47:43.530 に答える