JBOSS的集群策略分析

来源：yesky 作者：罗小虎出处：巧巧读书 2006-03-10 进入讨论组

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、我们希望为客户端代理对像设计一个比较合适的服务器结点的拓扑图，以便我们做出好的集群策略。

保留：： http://www.qqread.com/java/w502767600.html