Sha*_*man 5 java deployment ear scalability java-ee
我们正在开发基于JavaEE 6的应用程序,以部署在JBoss EAP 6.1上.该应用程序有2个主要的表示机制:Web管理控制台和RESTful服务API.在后端,管理控制台和RESTful服务API都依赖于一系列EJB来执行事务逻辑和POJO服务来检索数据.
完全可能的是,所有这些不同层的性能和资源需求可能不同.RESTful服务相当薄,完全没有状态,而管理控制台是有状态的,具有更多的交互功能(因此需要更多的内存和处理).由于我们的EJB执行主要的事务性业务逻辑,因此它们需要比仅查询数据库的POJO数据服务更多的处理能力.
在这样的设置下,使用所有这些组件部署单个EAR(在群集配置中的多个应用程序服务器中)或将单个组件分解为单独的EAR会更有意义吗？我对单独的EAR的想法是,例如,如果我发现它们存在可扩展性问题,我可以部署更多EJB服务实例,即使Web控制台(例如)正在扩展就好了.
鉴于每个层/组件的可扩展性不同,我应该采取什么方法？是否必须在EAR之间进行远程EJB调用的开销太高而无法考虑这样的模型？任何意见是极大的赞赏!
"Java EE"方式是将应用程序部署为群集上的单个EAR.我假设您正在使用从REST /管理控制台到EJB-s的本地接口调用.部署很简单,如果您不需要会话复制(可以使用粘性会话),那么可伸缩性将非常好.
您需要的唯一额外元素是Web应用程序的负载均衡器(例如,Apache服务器也会负责SSL解码,静态资源服务以及可能缓存的缓存请求).
这种设置的唯一问题可能是重负载,例如EJB可能会占用大量服务器资源,因此Web应用程序的吞吐量将难以控制,并且可能受到EJB的严重影响.如果您使用粘性会话,则用户始终会被重定向到同一服务器,因此只要用户会话持续,就没有机会将某些用户移动到负载较小的服务器.
因此,如果您计划高负载,那么将Web应用程序和EJB保存在单独的盒子(或虚拟机)上是有意义的,这样就可以更容易地识别瓶颈并更容易扩展需要它的层.
对此的处罚将是: