为服务器和客户端使用不同的 WAR 并将它们部署在不同的应用程序服务器中的优点和缺点

Question

我们有一个产品，其中 UI 打包为单独的 WAR，而服务器打包为单独的 WAR 文件。现在这两个 WAR 都部署在同一个应用程序容器中。以下是我发现的这种方法的优缺点：

进行不同战争的优点： 1. 我觉得拥有两个不同的 WAR 让我可以灵活地重构 UI 或服务器端代码，而不会影响另一个。 2. 为了最大限度地利用内存，我可以将它部署在两个不同的容器中。所以如果早些时候我为整个 jboss 使用 2 GB（比如我正在使用 jboss），现在如果部署在两个中，我可能会使用 4 GB 不同的 jboss 应用服务器（当然不同的端口号） 3. 我可以扩展我的应用程序。如果明天，我看到该服务器是我的瓶颈，那么我可以创建一个服务器场，（仅适用于我的服务器模块），因为服务器本身是一个不同的 WAR，而无需担心 UI WAR。 4. 松耦合并给我各种集成点

缺点： 1. 对于 UI，我使用 primefaces。我没有看到一个用例，我可以看到像缝附加值这样的集成框架。有人能告诉我有一个集成框架是否有意义吗 为了我的 UI 战争？基本上，seam 的全部乐趣在于它提供的与 UI、EJB 等的完美集成。因此，我在这里看不到太多价值，因为我的表单会要求其余 API 完成所有处理。

有人能告诉我，多场战争是否真的有助于可扩展性和维护。例如，我看到的一个好处是，如果我有两场战争并且我需要升级服务器平台，我不需要关闭我的 UI。除了我上面列出的还有其他好处吗？

另外，我想了解如果所有内容都打包为 EAR，您将如何扩展我们架构的特定层。如上所述，如果我觉得服务器层是瓶颈，如果是一个 WAR/EAR，我将如何扩展我的应用程序？

我仍然不确定我是否需要在不同的应用程序服务器中继续使用我的不同 WAR 模型，还是应该为我的整个应用程序只使用一个 WAR？请指导...

Answer 1

如果您的后端是独立的，并且您使用一些 REST 或 SOAP Web 服务与客户端通信 - 这很好。试着想象明天你用 java 放弃你的客户端并用 .NET 创建另一个客户端。后端是否需要一些更改？如果没有 - 这很好。如果是 - 我认为两场战争不会顺风顺水。