EJB应用服务器集群技术分析

 

J2EE平台提供了一个基于组件的方法，用来设计、开发、装配及部署企业应用程序。而且提供了一个多层的分布式的应用模型、组件的复用、一致化的安全模型以及灵活的事务控制模型。近年来在企业系统中得到了大量使用。随着J2EE应用服务器的大量部署和客户访问量的猛增。企业对于J2EE系统的可伸缩性和高可用性要求越来越高，特别是在电子商务和金融领域，这个问题越显的突出。如何设计和构建一个具有可伸缩的，高可用性的J2EE集群应用服务器，成为设计J2EE应用服务器设计必须考虑的问题。但J2EE应用服务器的集群是基于EJB组件的集群，和普通Web Server集群技术有很大的不同。实现的方法也根本不相同。

1 集群系统特点

       一个集群系统是一群松散结合的服务器组，形成一个虚拟的服务器，为客户端用户提供统一的服务。对于这个客户端来说，通常在访问集群系统时不会意识到它的服务是由具体的哪一台服务器提供。集群系统一般应具高可用性、可伸缩性、负载均衡、故障恢复和可维护性等特殊性能。

       高可用性是集群系统最基本的要求，它是对整个系统运行稳定性的一个评价。可伸缩性是指整个系统在随着客户端用户数量的增加而继续保持有效响应时间的能力。在一个可伸缩性系统中，随着用户数量的增加，有效响应时间变长，成线性变化关系，这也体现一个系统的峰值负载处理能力，但随着越来越多的系统处于Internet上，用户访问的峰值负载有效预测已变的不可能。用户访问量的猛增，使系统的有效响应时间成非线性变化，响应时间急剧变长，知道系统不堪重负而停机。一般的解决方法就是通过提升系统硬件系统，或通过增加服务器。但是不合理的增加服务器只能使整个集群系统变的越来越庞大，系统的这种复杂化就意味系统故障率变高，随之整个系统可靠性、可维护性都会降低。

       所以，一个系统的可用性和可伸缩性是一对矛盾的关系，而且和整个集群系统的实现方法有很大的关系。

2         EJB技术

EJB是J2EE应用平台的核心。Sun在EJB2.0规范中对EJB定义如下：EJB是用于开发和部署具多层结构的、分布式的、面向对象的Java应用系统跨平台的构件体系结构。EJB组件有三中类型：会话bean、实体bean、消息驱动bean。其中会话bean分为有状态和无状态两种。

EJB服务器的核心是提供EJB使用的一个或者多个EJB容器（Container）。EJB容器管理它所包含的EJB，为EJB组件的生存和执行提供了运行环境，同时也负责EJB的事务管理，安全管理，资源访问控制和一些异常处理。EJB容器不允许J2EE的客户端程序直接访问容器中EJB对象，当一个客户端用户想访问一个EJB， EJB规范中要求客户使用Java名字和目录接口JNDI（Java Naming and Directory Interface）API来定位Bean的home接口。 要访问EJB一般需要经过以下三步（见图1）（下面只列举Remote的调用）：

1）    从JNDI中查找Bean的home接口。首先客户需要获得一个JNDI的初始化上下文，然后，客户就可以使用上下文的lookup方法从一个名字对应到它的home接口；

2）    使用home接口中的Create（）方法获得Bean的Remote接口引用；

3）    通过Remote接口中的方法使用Bean中定义的方法；

一个简单访问例子如下：

// 获得JNDI初始化上下文

Context mycontext  =  new InitialContext( );

// 查找MyEJB，获得Home对象的引用

Object homeref =  mycontext.lookup(“MyEJB”);

// Home对象造型为RMI-IIOP对象

MyBeanHome home =

(MyBeanHome)PortableRemoteObject(homeref, MyBeanHome.Class);

          // 创建EJB对象，返回Remote接口

MyBeanRemote  myref = home.create( );

//通过Remote接口调用EJB中实现的方法

System.out.println ( myref.getname( ));

3 EJB服务器集群

EJB服务器的集群是基于组件的一种集群方式，和普通Web Server集群技术有很大的不同。实现的方法也不相同。又由于EJB规范中没有提供任何有关支持集群的标准，即使有的厂商在EJB服务器中提供了集群特性，但如何具体实现集群也是由厂商自己确定。实现的方法也各不相同。目前，大多数J2EE应用服务器都提供了集群功能，如Bea WebLogic应用服务器，开放源码的JBoss应用服务器，Sybase公司提供的J2EE应用服务器等都提供了集群功能。在EJB服务器集群设计中，负载均衡（Load Balance），EJB集群和HttpSession集群技术是设计中涉及到的主要技术。其中EJB集群的实现是整个系统实现的核心。

 

3.1负载均衡(Load Balance)

Load Balance 主要的目的在于将访问系统的负荷分散在不同的机器上，使整个系统吞吐量和并发性得到提高, 它能让多台服务器共同承担一些繁重的计算或I/O任务，从而消除网络瓶颈，提高网络的灵活性和可靠性。常见的方法如下：

l         循环DNS

DNS负载均衡是一种简单而有效的方法，该方法使用简单的域名查询IP地址来实现一种简单的负载均衡。任意给出一个地址，DNS服务器都有一个IP地址池与之对应。每次请求将域名转换成IP地址时，循环返回IP地址池中的下一个地址。故被称作DNS round-robin。当一个Client访问时，给请求JNDI的InitialContext客户端传递一个DNS名，作为命名服务器的URL，每个DNS名字被转换成一个不同的地址，使用这个技术，每个客户端InitailContext请求就被直接发送到不同的服务器上。 负载均衡的一大缺点是：一旦某个服务器出现故障，即使及时修改了DNS设置，还是要等待足够的时间（因为DNS需要一定的刷新时间）才能发挥作用，在此期间，有些客户端用户访问仍旧将发送故障服务器上。

l         软件Proxy

软件Proxy维护连接到一系列服务器上的打开连接。当一个Client访问服务器时，先要经过这个软件代理，这个代理能通过一些负载均衡的算法（如采用类似DNS Round-robin、随机方法、访问权衡算法 ）把一个用户的访问重新定向到一个服务器。这个软件代理方法能够及时发现服务器死机或没有响应，有效地避免了DNS round-robin方法中出现地故障访问。

l         硬件均衡器

这种硬件均衡器一般采用地址转换技术，将一个外部IP地址映射为多个内部IP地址，对每次TCP连接请求动态使用其中一个内部地址，达到负载均衡的目的。一般可采用第四层（或4层以上）的交换机来实现，这种交换机是按照IP地址和TCP端口进行虚拟连接的交换，直接将数据包发送到目的计算机的相应端口。通过交换机就能将来自外部的初始连接请求，分别与内部的多个地址相联系，从而建立虚拟连接实现负载均衡。这种第四层交换基于硬件芯片，因此网络传输速度和交换速度远远超过普通软件代理方式。如采用Cisco CSS 11150（一种L4 Switch）可以实现硬件均衡。

 

3.2 EJB 集群技术

Client端要访问EJB容器中EJB都是先要先访问JNDI命名服务器[见2节EJB技术]。所以J2EE的EJB服务器的实现集群（ Cluster）核心也就围绕着JNDI。根据集群对于JNDI命名树在系统中管理和组织的不同，一般EJB集群可以分为下面三种：

1）  JNDI树代理（Proxy）

Cluster中每个J2EE Application Server都维护一个自己的本地私有JNDI树，Cluster中的每个服务器不知道其它服务器的状态和存在情况，只有Proxy服务知道Cluster中每个服务器的状态，并且可以访问Cluster中任何一个服务器上的JNDI树，这就要求每个服务器在启动和启动后要不断地和Proxy服务保持联系，以便Proxy知道它们的工作情况和Cluster所有的EJB对象。Client访问EJB对象，首先要访问JNDI Proxy，通过Proxy,可以重新定向访问到Cluster中所有的EJB对象（见图2）。这种方法的优点是实现简单，只需要设计一个JNDI Proxy代理。对于每个应用服务器不做复杂要求；而且系统的伸缩性好，要升级系统，只是简单增加服务器就可以。但这种方法有一个致命的缺点，就是Proxy服务要是失败，整个Cluster系统将无法正常工作，可靠性差。

2) 集中式JNDI树

采用集中式集群时，整个集群系统中仅有一个主命名服务器，它负责管理和维护集群中一个全局、集中的JNDI树，集群中所有的EJB服务器在启动后，都要把要发布的对象绑定在这台命名服务器上，每个EJB服务器不需要维护自己的私有JNDI树，由这台主命名服务器来维护。假如在集群中一个EJB要在多个服务器上部署，那么每个服务器可以把同一个home对象绑定到命名服务器上，当一个客户从命名服务器请求访问这个EJB的home对象，可以将所有的home对象引用都返回给客户端，或者可以按一种均衡算法返回一个服务器的home对象引用(见图3)。这种集中式方法要提高整个系统可靠性，必须考虑命名服务器的备份问题，往往在大系统同时采用多台命名服务器，命名服务器间可以采用JNDI树复制方式，或者采用EJB服务器在多台服务器上绑定方式。例如Sybase公司的EJB应用服务器就是采用这种方式，它采用采用CORBA Cos Naming Service集中的管理Cluster中所有应用服务器的JNDI树。采用这种集中式的设计模型，系统设计简单，但同时为系统带来了集中式所固有的缺陷。首先，当系统设计中要考虑到命名服务器备份问题，而且随着集群系统越来越大，命名服务器在整个系统种瓶颈问题越显突出。

 

3) 分布式JNDI树

在这种模型中，Cluster中每台应用服务器都有自己的命名服务器，命名服务器不仅维护私有的本地JNDI树，同时维护一个全局共享JNDI树。本地JNDI树只绑定本地应用服务器中部署的对象，而全局JNDI树保存了Cluster中其他应用服务器上的本地JNDI树副本。这样Client访问任何一台命名服务器，通过它的本地私有和全局共享JNDI树就能定位整个系统中部署EJB对象。一般都是采用多播形式，当Cluster中一个应用服务器启动后，加入这个Cluster的多播组，然后再采用IP 多播技术复制它的本地JNDI树到Cluster中其他服务器上全局共享JNDI树，这样Cluster中其他服务器就拥有它的JNDI树副本。同时，这台应用服务器和Cluster中其它服务器之间一直要保持HeartBeats(心跳)检测，以随时检测其它服务器的活动状态，假如有一台服务器死机异常后，这台应用服务器就要从它的全局共享JNDI树中删除这台异常服务器JNDI副本，其它活动的服务器都要做类似的操作。这种分布式模型系统最大的优点是具有很强的伸缩性，系统中再添加一台服务器，其它的服务器可以不作任何的变动。而且整个系统采用分布式体系可用性增强，系统中任何一台服务器死机，都不会影响到整个系统的正常工作。这种方法也是目前采用最多的一种设计方法。BEA公司WebLogic应用服务器和JBoss应用服务器就采用这种设计方法。

 

3.3 HttpSession Cluster

在J2EE的Web程序Jsp/Servlet中经常用到Session对象，它的主要功能是记录访问端客户会话中有关信息。在一般的Web系统中，在Client访问阶段，假设系统中Server端死机后，这次Client访问中Session中保留的相关信息将全部丢失。用户下次访问就又需要重新开始建立新的Session。HttpSession Cluster的目的就是即使服务器端系统死机重新启动，上次未完成访问中的Session在系统中仍旧保存，Client可以接着完成上次未完成的访问。

在一些大型的系统中，同时又成千上万的用户同时访问，要时实的保存所有Client端的Session信息，而且以保证一旦系统失效，系统会重新载入自己的Session状态，用户能够继续操作。一般的实现HttpSession Cluster有下面两种方法：

1）  采用内存复制：

在这个方法中，当某台J2EE Server 中的某个HttpSession某个Object被修改后，或是新增一个Object后，这台Server可以采用某种通讯方式（如IP Broadcast ）将这个Object传送到其它备份的J2EE Server上，让其它 J2EE Server上相同的HttpSession同步变化。

2）  集中式：

所谓的集中式处理，与上面的内存复制方法非常相似，不同的是在集中式中，Session中的Object不是送到其它的Server上，而是送到一台特定的机器上，在这台机器上Object中的信息可以采用对象序列化后文件保存，或者抽象成数据后，保存到关系数据库中。这台机器集中管理所有Cluster中的所有Session状态和信息。

4 结语

       本文在对于集群系统的方法分析侧重于JNDI树的实现问题，在实际的设计中还应该具体的考虑到两种会话Bean，实体Bean和消息驱动Bean对于集群方法实现的差异性以及它们的故障恢复技术。

 

参考文献：