5

我们正在开发一个基于 JavaEE 6 的应用程序以部署在 JBoss EAP 6.1 上。该应用程序有 2 个主要的呈现机制：一个 Web 管理控制台和一个 RESTful 服务 API。在后端，管理控制台和 RESTful 服务 API 都依赖于一系列 EJB 来执行事务逻辑和 POJO 服务来检索数据。

所有这些不同层的性能和资源需求完全有可能不同。RESTful 服务相当精简且完全无状态，而管理控制台是有状态的并且具有更多交互功能（因此需要更多内存和处理）。由于我们的 EJB 执行我们的主要事务性业务逻辑，因此它们需要比我们简单查询数据库的 POJO 数据服务更多的处理能力。

考虑到这样的设置，部署一个包含所有这些组件的 EAR（在集群配置中的多个应用服务器中）或者将各个组件分解为单独的 EAR 是否更有意义？我对单独 EAR 的想法是，例如，如果我发现 EJB 服务存在可伸缩性问题，我可以部署更多实例，即使 Web 控制台（例如）的伸缩性很好。

鉴于每个层/组件的可扩展性不同，我应该采取什么方法？跨 EAR 进行远程 EJB 调用的开销是否太高而无法考虑这种模型？任何意见是极大的赞赏！

4

2 回答 2

5

“Java EE”方式是将应用程序部署为集群上的单个 EAR。我假设您正在使用从 REST/管理控制台到 EJB-s 的本地接口调用。部署会很简单，如果您不需要会话复制（您可以使用粘性会话），那么可扩展性将非常好。

您需要的唯一额外元素是 Web 应用程序的负载平衡器（例如，Apache 服务器也将负责 SSL 解码、静态资源服务以及可能缓存可以缓存的请求）。

这种设置的唯一问题可能是负载过重，例如 EJB 可能会占用大量服务器资源，因此 Web 应用程序的吞吐量将难以控制，并且可能会受到 EJB 的严重影响。如果您使用粘性会话，用户总是被重定向到同一台服务器，因此只要用户会话持续，就没有机会将一些用户移动到负载较少的服务器。

因此，如果您计划高负载，那么将 Web 应用程序和 EJB 保留在单独的盒子（或虚拟机）上是有意义的，这样更容易识别瓶颈并更容易扩展需要它的层。

对此的处罚是：

  1. 远程调用 EJB。然而，JBoss 6 有相当先进的 EJB 池配置，所以它可能不是一个可怕的问题。
  2. 这些远程调用引起的网络流量（因此，如果您在 EJB 和 Web 层之间传递大量数据，这可能是一个问题）。
于 2013-05-21T16:16:37.543 回答
2

为了支持 Piotr 的精彩评论：

现在将它们捆绑在一起，只有在将来真正需要时才分开。

考虑一下 Martin Fowler 的分布式对象设计第一定律：不要分发您的对象！作为一个很好的指导方针 - 如果你要打破它，至少有意识地这样做并满足真正的业务需求。

于 2013-05-22T01:52:51.467 回答