{$PageTitle=}
【IT168分析评论】 
    一般来说,为一个Java应用程序瘦身并不容易,有很多技术可以让你分发数据跨多个JVMs,但是这些技术中的大多数都是笨重的,较高的维护费用,让我们讨论使用三种不同的方法也就是EJBs, JMS and POJOs相关的缺点. 

    作为一个主要的服务公司的服务器管理者,我已经工作三年了,这篇文章我将以我这三年的经验为轮廓,主要集中的讨论了我们在以一种有效的方式努力群集我们的应用程序时所面对的缺点. 

    当我着手工作时,对我来说,重新设计一个现有系统的架构是显而易见的,典型的消费者面对应用程序服务于Web和移动客户端,整个应用程序是用Java(JSE和JEE)写的典型的三层架构,该应用程序部署在两个应用服务器上,所有的临时的和持久的数据将被放入到数据库中专注于高的实用性,随着用户的增长,数据库在RAS(Reliability, Availability, Serviceability即可靠性,实用性,适用性)和性能方面是主要瓶颈,这种情况,我们有两个可选方案:一个是从数据库厂商中花巨大的资金来买他们的群集解决方案,另一种方案就是重新设计架构使之成为一个RAS系统.选择第一种方案是诱人的,这也就意味着我们正逐渐掩盖我们架构的缺点,另外,我们还花费了大量的资金.于是,我们选择了后者. 

    随着应用程序的进一步发展,我们对临时数据和持久数据做了一个清晰的划分,使用数据库来存储记录系统信息,为了分发所有的临时性信息(sessions, caches等),我们采用EJB+JNDI这种途径.下图就是我们看起来要部署的.

    我们知道EJB的缺点就是它属于重量级的,因此不得不依靠一个重量级容器,EJb3有某种程度的改进.就群集方面来讲,我们发现主要的缺点是JNDI.