我们有一个产品，其中UI打包为单独的WAR，服务器打包为单独的WAR文件。现在，这两个WAR都部署在同一个应用程序容器中。以下是我发现的这种方法的优缺点：
进行不同战争的优点： 1.我觉得有两个不同的WAR允许我灵活地重构UI或服务器端代码而不影响另一个。 2.为了最大化内存使用量，我可以将它部署在两个不同的容器中。所以，如果我早些时候使用2 GB用于整个jboss（比如说我使用的是jboss），现在我可以使用4 GB，如果部署在两个 不同的jboss app服务器（当然不同的端口号） 我可以扩展我的申请。如果明天，我看到服务器是我的瓶颈，那么我可以创建一个服务器场，（仅限我的服务器模块），因为服务器本身是一个不同的WAR，没有打扰UI WAR。 4.松散耦合并给我各种积分点
缺点： 1.对于UI，我使用primefaces。我没有看到一个用例，我可以看到一个集成框架，如seam添加值。有人可以告诉我，如果有一个集成框架是有意义的 为我的UI战争？基本上，seam的整体乐趣，是它提供UI，EJB等其他东西的精彩集成。因此，我在这里看不到太多价值，因为我的表单会要求其余的API进行所有处理。
有人可以告诉我，如果多次战争实际上有助于扩展和维护。例如，我看到的一个好处是，如果我有两场战争，我需要升级服务器平台，我不需要关闭我的UI。除了我上面列出的内容之外的任何其他好处？
此外，我想了解如果所有内容都打包为EAR，您将如何扩展我们架构的特定层。如上所述，如果我认为服务器层是瓶颈，在一个WAR / EAR的情况下，我将如何扩展我的应用程序？
我仍然不确定是否需要在不同的应用程序服务器中继续使用我的不同WAR模型，或者我的整个应用程序只需要一个WAR？请指导......
答案 0 :(得分：0)
如果您是独立的后端，并且您使用某些REST或SOAP Web服务与客户端通信 - 这很好。试着想象一下tommorow你用java删除你的客户端并用.NET创建另一个。后端是否需要进行一些更改？如果不是 - 这很好。如果是的话 - 我认为它不会发生2次战争。