我们有一个产品，其中 UI 打包为单独的 WAR，服务器打包为单独的 WAR 文件。现在这两个 WAR 都部署在同一个应用程序容器中。以下是我发现的这种方法的优缺点：
不同战争的优点： 1. 我觉得有两个不同的战争让我可以灵活地重构 UI 或服务器端代码，而不会影响另一个。2. 为了最大限度地利用内存，我可以将它部署在两个不同的容器中。因此，如果早些时候我为整个 jboss 使用 2 GB（比如我正在使用 jboss），现在如果部署在两个不同的 jboss 应用程序服务器（当然不同的端口号）中，我可能会使用 4 GB。3. 我可以扩展我的应用程序。如果明天，我看到该服务器是我的瓶颈，那么我可以创建一个服务器场，（仅适用于我的服务器模块），因为服务器本身是一个不同的 WAR，而无需担心 UI WAR。4. 松耦合并给我各种集成点
缺点： 1. 对于 UI，我使用 primefaces。我没有看到一个用例，我可以看到像缝附加值这样的集成框架。有人能告诉我，如果有一个集成框架对我的 UI 战争有意义吗？基本上，seam 的全部乐趣在于它提供的与 UI、EJB 等的完美集成。因此，我在这里看不到太多价值，因为我的表单会要求其余 API 完成所有处理。
有人可以告诉我是否有多个战争实际上有助于可扩展性和维护。例如，我看到的一个好处是，如果我有两场战争并且我需要升级服务器平台，我不需要关闭我的 UI。除了我上面列出的还有其他好处吗？
另外，我想了解如果所有内容都打包为 EAR，您将如何扩展我们架构的特定层。如上所述，如果我觉得服务器层是瓶颈，在一个 WAR/EAR 的情况下，我将如何扩展我的应用程序？
我仍然不确定我是否需要在不同的应用程序服务器中继续使用我的不同 WAR 模型，还是应该为我的整个应用程序只使用一个 WAR？请指导...