Huihoo - Enterprise Open Source


JBoss的集群策略分析


(来源:http://www.yesky.com)

序言

  在阅读本文前,请确定您有以下基础,否则您可能会是在浪费您的时间:

  1、 了解J2EE的一些基本概念

  2、 了解集群的基本概念

  3、 对JBOSS有一些大致的了解,可到http://www.jboss.org上下载它。 JBOSS是一个开放源码的、基于J2EE规范的应用服务器,它实现了大多数的J2EE规范,除此之外,它还提供了一些J2EE中所没有涉及到的企业级功能,例如集群。本文主要描述JBOSS采取的集群策略,并重点介绍它的负载平衡与失效转发机制。

  由于JBOSS是一个建立在J2EE规范上的应用服务器,因此在开始之前,我们还是简单地介绍一下J2EE规范:J2EE是一套针对于企业级分布式应用的计算环境,它定义了动态WEB页面功能(servlet和jsp),商业组件(EJB),异步消息传输机制(JMS),名称和目录定位服务(JNDI),数据库访问(JDBC),与子系统的连接器(JCA),安全服务等等。

  但美中不足的是J2EE并没有定义一些企业级应用所必须的规范,例如集群,所以集群的实现只能由各厂商自行来设计实现。要实现基于J2EE规范的集群,我们通常要做如下考虑:集群的管理、负载平衡、失效转发、服务端状态的复制(例如JSP中的session),还要考虑同步和异步的问题(例如JMS服务就是异步方式)。如果要对这些内容做一个全面的阐述的话,估计可以写成一本书了:) 因此本文主要探讨的是:怎样实现无状态EJB的负载平衡与失效转发机制?

  1999年,Marc Fleury建立了JBOSS开源项目,现在它有差不多100个活跃的开发者,30个核心开发者,每月高达35万次的下载量,它当前的最高稳定版是3.2版,4.0版正在稳定之中,自从JBOSS3.0开始就加入了集群技术,几乎能对任何J2EE规范进行集群管理,如JNDI、JSP中的session、EJB等等。更令人振奋的是,即将发行的JBOSS4.0将会对JMS也加入集群管理特色。




  EJB集群在JBOSS中的实现

  下面言归正传,上图大致描述了一个客户端调用JBOSS中的EJB的过程。在JBOSS中,客户端并不直接调用EJB对像,而采用了一个迂回的方法,更专业的说是一种设计模式――代理模式,真正与客户端交互的是一个代理对像①,这个代理对像一般由客户端通过JNDI技术来取得的。而具体的代理对像的实现就由各厂商自完成了,在JBOSS中,一个代理对像是一段精心设计的复杂代码。

  但在客户端看来,调用一个代理对像好像就是在调用那个实际的EJB对像,虽然事实并非如此。在这里JBOSS耍了一个小把戏,代理对像虽然实现了与EJB对像相同的接口,但它实际上是把客户端对它的调用转发到了它在服务端的另一个伙伴身上②,同时,这个伙伴同样定义了客户端所要求的一些EJB接口,当这些接口被调用时③,精彩的部分开始了,JBOSS把客户端发过来的各种各样不同的调用全部转换成为一个统一格式的接口④(在本文中我们暂且称客户端发出的调用为应用级接口,而JBOSS生成的统一格式的接口称为系统级接口)。当转换完成后,所有的应用级接口变成了系统级接口⑤。为了能更清楚地阐述这个问题,我们假设客户端向EJB对像发出如下调用:

myRemoteComponent.increaseSalary(100); 
//myRemoteComponent为代理对像

  这个调用实际上被JBOSS转换成了如下的系统级调用:

proxyClientContainer.invoke(invocation);
//proxyClientContainer为代理对像在服务端的另一个伙伴

  但这个invocation到底是什么呢?实际上它是类Invocation的一个实例,这里有它的一个简单的说明:

public class Invocation{
 Object[] args; //应用级接口中的一些参数
 Method method; //被调用的应用级接口
 Map payload; //JBOSS就是在这里采取的负载平衡策略的
 ……
}

  当应用级接口被转换成为了系统级接口之后,它将经过一系列的拦截器(⑥至⑦)。在这里我首先要说明一下什么是拦截器,实际上,它是JBOSS中独具特色的一个设计思路,一个拦截器就好像是一张过滤网,它用来对客户端的调用进行拦截,并对其进行一些处理,比如检查客户端调用的合法性、实现安全策略、对事务进行支持等。值得一提的是,JBOSS的集群管理也是通过拦截器来实现的,更令人欣慰的是,JBOSS的设计者并没有将这个拦截器固化在其核心内,而是采用一种插件式(plug-in)的方法来设计,因此你只要实现它的插件接口,你甚至可以写出自己的拦截器来,当然,这已不属于本文的讨论范围之内了。

  这里(⑥至⑦)的每个拦载器将顺序地拦截invocation,它们都具有如下的集群管理方面的能力:

  1、 分析invocation的内容和任务。

  2、 加入一些信息到invocation中的payload中,以优化集群策略。

  3、 读取出放在payload中的任何可用信息。

  4、 将invocation转发到下一个拦截器中。

  5、 如果发生错误,能够将错误报告给调用者,并返回到正确的地方去。

  值得注意的是最后一个拦截器,它有一些特殊,因为它才真正地执行对实际的EJB的调用⑧,它能检测到客户端是否和EJB对像在同一个Java虚拟机中,如果是的话,它只是简单地将这个调用直接传给EJB对像,这样做的原因是可以避免由于网络传输带来的不必要的开销,使用调用速度大大加快。

  另一方面,如果客户端与EJB不在同一个虚拟机中,那么它们就要通过网络传输了,在这里JBOSS提供了另一个有趣的策略,就是代理对像并不知道采取的是什么传输协议,只有最后那个拦截器才知道真正采用的传输协议是什么。就目前而言,它提供了RMI/JRMP、IIOP、HTTP、SOAP等协议来进行传输。
当我们设计JBOSS的集群策略时,我们还必须决定究竟要在哪儿将负载平衡以及失效转发行激活,为此,请先看下图:



  1、 在某个服务器结点上发生

  2、 在一个中介服务器上进行发生

  3、 在客户端上进行发生

  上图中的3种方案都有其利弊,但我们觉得最后一个方法要比前2个好,原因如下:

  1、 与第2种方案相比,它避免了由于中介服务器失效而引发的全线崩溃。

  2、 除非客户端崩溃,负载平衡和失效转发策略才会失败。而我想应该没有人会对此产生报怨的。这也没有什么好报怨的,不是吗?

  3、 从性能方面来考虑,这种方案也是最优的,因为所有的策略都是发生在客户端的,省去了第1、2种方案由服务器来管理带来的瓶颈。

  因此,我们选择了最后一种方案来做为JBOSS的集群策略。其实,只要大家再仔细回顾一下前面的部分,就会发现我们先前描述的方案不正是第3种方案吗?但我们现在必须对这个策略在以下几个方面做一些更深入的分析:

  1、 我们必须加入真正实现负载平衡的逻辑。

  2、 当客户端发出调用时,我们应该能够决定到底将它发送到哪个服务器节点上。

  3、 我们希望为客户端代理对像设计一个比较合适的服务器结点的拓扑图,以便我们做出好的集群策略。


  负载平衡的设计策略

  前面已经说过,JBOSS的负载平衡与失效转发策略是由最后一个拦截器实现的(上图中的①),然而我们要考虑的是虽然客户端只发出一个调用,但针对于代理对像的调用可能包含多个可用的服务器结点,其个数等于集群中所有有效节点之和(参见上图中的②),那么到底是由谁来决定这个策略的呢?这个工作由一个叫插件式的负载平衡策略来实施的(在下一段中简称策略①,如下图)。



  当客户端调用到达最后一个拦截器的时候,拦截器会请求策略①来为它选择一个服务器结点。如果此结点有效且调用成功,则结果会返回给代理对像,如果失败了,拦截器不会直接将错误返回给代理对像,而是将这个错误信息报告给策略①,并请求它再为客户端选择一个新节点。

  但还有一个问题值得考虑的,就是对一些致命性错误的处理。例如某个数据库服务器突然崩溃了,那么最后一个拦截器将无法对此进行失效转发了,因为不管选择哪个服务器结点都不能解决这个问题了,在这里拦截器会将错误报告给客户端,并由其自已做出决定。

  IT界里好像有这样一个原理,就是"越是可扩展性强,灵活的东西实施起来就越复杂"。在JBOSS中也不例外,但幸运的是这些工作并没为给客户端带来额外的编程负担,因为所有策略的配置都是在服务器完成的。
JBOSS的集群配置遵循XML规范,下面是的一个普通EJB对像的典型集群配置:

<jboss>
 <enterprise-beans>
  <session>
   <ejb-name>MySessionBean</ejb-name>
   <clustered>True</clustered>
   <cluster-config>
    <partition-name>DefaultPartition</partition-name>
    <home-load-balance-policy >
     org.jboss.ha.framework.interfaces.RoundRobin
    </home-load-balance-policy>
    <bean-load-balance-policy>
     org.jboss.ha.framework.interfaces.FirstAvailable
    </bean-load-balance-policy>
   </cluster-config>
  </session>
 </enterprise-beans>
</jboss>

  上述配置说明了一个名为MySessionBean的会话Bean的集群策略,它定义了名为DefaultPartion的缺省策略名称,并定义了2个具体的策略。当然,如果你觉得它比较复杂,而只想用JBOSS缺省的集群策略的话,可以将整个<cluster-config>标签去掉。

  最后还有一个小问题值得考虑:由于集群策略是发生在客户端的,当客户端发出调用请求时,它不得不下载它的代理对像、拦截器、负载平衡策略等等。如果要下载的内容过多,会影响客户端的调用速度,这里JBOSS采取了一种延迟下载的方法,就是每次只下载一个必须的类,而不是一次全部下载,这样就能使性能得到较大的改善。


  服务器结点拓扑图的刷新

  JBOSS的集群实现是动态的,也就是说你可以动态地往集群中加入一个新节点或关闭任意一个节点,而不用费力地维护一张静态的拓扑图,就好像是JBOSS自己有能力管理集群一样。这个思想够先进吧?但与此同时它也带来了一些令人头痛的问题,请先看下图:



  由于JBOSS的集群策略是在客户端进行的,那么客户端在调用EJB的时候会将所有必须的组件下载下来,然后由其进行集群决策。如果我们设T为时间,且t0<t1<t2,那么当处于t0时刻时,集群拓扑图中包含server1和server2两个节点,客户端的调用被转发到了结点2上。当处于t1时刻时,server1和server2全部都崩溃了。当处于t2时刻时,管理员增加了server3和server4两个节点,但客户端的拓扑图中还只是包含原先的server1和server2两节点的信息,因为它无法知道这新加入的2个节点。

  为了解决这个问题,JBOSS是这样设计的,在客户端的每次对某个节点调用后,服务器节点自动检查客户的拓扑图是不是最新的,如果不是,则向客户端发送新的拓扑图,如下图所示:



  当客户端进行调用时,代理对像对其进行了一个小小的包装,它将系统级调用invocation和自已现在的拓扑图(JBOSS开发者称它为view ID)发送到服务端,而服务端则检查它自己的view ID是否与代理对像中的view ID吻合。这里我们先简单介绍一下view ID,它实际上就是包含所有服务器节点的一个哈希表,至于为什么要用哈希表是因为它生成方便(java编译器自带)、存取快速,无须考虑排序问题。

  下面接着讲述,如果代理对像的view ID与服务端节点的view ID相吻合的话,服务端将直接把结果传给EJB对像,并将结果返回。

  如果服务器集群拓扑产生了变化,则会导致它们不吻合。这时服务器节点同样也将调用EJB对像,但此时返回的结果有所不同,它除了返回客户端的结果外,还要为代理对像返回一个最新的view ID,并通知代理对像:"喂,你的拓扑图太旧了,我发了份新的,你赶快更新一下吧!" 当代理对像收到这个消息后会更新自己的view ID,并将结果返回客户端代码。

  性能考虑

  对于JBOSS来说,实现负载平衡与失效转发所带来的性能上的损失是很难计算的,因为它只发生在客户端上,而每个客户端不管从硬件配置、操作系统来说都是不一样的。

  由于本文讲的主要是对于无状态的EJB对像的集群,但如果是有状态的EJB或实体EJB,那情况会怎样呢?答案是:情况只会更糟!为此服务器节点不得不进行状态复制,而这个开销通常是很大的,取决于状态中上下文的内容和状态更新的频率。所幸的是,对于大多数应用而言,它们主要是进行无状态的EJB调用,这样就不服务器节点就不需进行大量状态复制了。

  结论

  JBOSS为J2EE应用提供了一个非常灵活有效的集群机制。它能使得在保持服务端性能损失最小的情况下进行失效转发,并能动态地对集群节点进行配置。更令人振奋的是,在JBOSS4.0中,集群机制将会发挥到极致,到时候就不仅仅是J2EE应用能够进行集群管理了,连普通的J2SE应用都能进行集群了,到那时高可用性的计算并不只是一句口号了,而是JBOSS的一个简单实现!