我们正在开发基于JavaEE 6的应用程序，以部署在JBoss EAP 6.1上。该应用程序有2个主要的表示机制：Web管理控制台和RESTful服务API。在后端，管理控制台和RESTful服务API都依赖于一系列EJB来执行事务逻辑和POJO服务来检索数据。
所有这些不同层的性能和资源需求完全可能不同。 RESTful服务相当薄，完全没有状态，而管理控制台是有状态的，具有更多的交互功能（因此需要更多的内存和处理）。由于我们的EJB执行主要的事务性业务逻辑，因此它们需要比仅查询数据库的POJO数据服务更多的处理能力。
鉴于这样的设置，使用所有这些组件部署单个EAR（在群集配置中的多个应用程序服务器中）或将单个组件分解为单独的EAR会更有意义吗？我对单独的EAR的想法是，例如，如果我发现它们存在可伸缩性问题，我可以部署更多EJB服务实例，即使Web控制台（例如）正在扩展就好了。
鉴于每个层/组件的可扩展性不同，我应该采取什么方法？是否必须在EAR之间进行远程EJB调用的开销太高而无法考虑这样的模型？任何建议都非常感谢！
答案 0 :(得分：5)
“Java EE”方式是将应用程序部署为群集上的单个EAR。我假设您正在使用从REST /管理控制台到EJB-s的本地接口调用。部署很简单，如果您不需要会话复制（可以使用粘性会话），那么可伸缩性将非常好。
您需要的唯一额外元素是Web应用程序的负载均衡器（例如，Apache服务器也会负责SSL解码，静态资源服务以及可能缓存的缓存请求）。
这种设置的唯一问题可能是重负载，例如EJB可能会占用大量服务器资源，因此Web应用程序的吞吐量将难以控制，并且可能受到EJB的严重影响。如果您使用粘性会话，则用户始终会被重定向到同一服务器，因此只要用户会话持续，就没有机会将某些用户移动到负载较小的服务器上。
因此，如果您计划高负载，那么将Web应用程序和EJB保存在单独的盒子（或虚拟机）上是有意义的，这样就可以更容易地识别瓶颈并更容易扩展需要的层。
对此的惩罚是：
答案 1 :(得分：2)
支持Piotr的好评：
现在将它们捆绑在一起，如果将来真的有需要，只拆分 。
将Martin Fowler的First Law of Distributed Object Design: Don’t distribute your objects!视为一个很好的指导方针 - 如果你打算打破它，至少要有意识地去做，并满足真正的商业需求。