2

我对 Java 领域有些陌生，并且对构建 Web 门户的最佳实践有一些疑问。所以我的问题是将一个巨大的战争文件分解成更小的战争文件真的有什么好处。我唯一能想到的：

  • 模块化：它允许单独的开发人员在站点的单独部分上工作并单独部署它们。

  • 组织：如果站点的某些部分不在同一个代码库中，则更容易找到它们。

  • 可扩展性：只有当您要在不同的 Web 服务器上部署站点的某些部分时，这对我才有意义。如果它们都被部署到相同的前端服务器有什么优势吗？

根据我的阅读，似乎大多数人似乎认为一个大的战争文件是最好的方法：避免冗余、一步部署等。那么有理由分解它吗？也许网站的匿名/小册子版本与经过身份验证的？

4

3 回答 3

1

操作人员更喜欢一个 big .war，因为这意味着只需部署一件事。

但是，如果您可以轻松地将您的网站分解为单独.war的 s，并且诚实地部署和取消部署它们而不影响其他已部署的工件，并且确定您需要这种粒度（请参阅YAGNI），那么将其分解。

于 2012-09-24T19:09:07.143 回答
1

如果某些模块有单独的可扩展性、安全性和可靠性要求，那么您可以将它们分解。理想情况下，如果需要，您的安全性可以分开。

于 2012-09-24T19:14:09.797 回答
0

您需要考虑的几件事会极大地影响您的决定：

  1. 不同的依赖项——假设 A 类需要 v1 的库 L，而 B 类需要相同的依赖项，只是版本不同——v2。如果您将两者部署在同一个战争中，它们将获得相同的类路径，并且您必须对齐所有依赖版本。如果将它们拆分，您可以在一场战争中拥有 v1，而在另一场战争中拥有 v2。这也意味着如果你想从 v1 升级到 v3，你只需要测试 class A 的行为，因为 class B 将保留在旧版本中。所以这里的模块化非常强大。
  2. 服务器的加载时间 - 您拥有的战争文件越多，服务器启动所需的时间就越多。
  3. 维护 - 战争文件往往是臃肿的，除非您密切关注大小并删除多余的依赖项 - 这不是一件容易的事！一些是运行时依赖项，一些是编译，一些是测试，一些是生产。这是很多工作，人们倾向于推迟它。如果你有一个臃肿的 war 文件，有 X 个冗余依赖项，那就是 X 大小的问题（加载时间、保存每个版本所浪费的存储空间等）。如果您有 Y 个战争文件，那么您的问题是 X*Y 大小。
    换句话说 - 清理 1 居室公寓比 7 居室别墅更容易。
于 2016-11-10T14:47:43.530 回答