序言 在阅读本文前，请确定您有以下基础，否则您可能会是在浪费您的时间： 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对像发出如下调用：
这个调用实际上被JBOSS转换成了如下的系统级调用：
但这个invocation到底是什么呢？实际上它是类Invocation的一个实例，这里有它的一个简单的说明：
当应用级接口被转换成为了系统级接口之后，它将经过一系列的拦截器（⑥至⑦）。在这里我首先要说明一下什么是拦截器，实际上，它是JBOSS中独具特色的一个设计思路，一个拦截器就好像是一张过滤网，它用来对客户端的调用进行拦截，并对其进行一些处理，比如检查客户端调用的合法性、实现安全策略、对事务进行支持等。值得一提的是，JBOSS的集群管理也是通过拦截器来实现的，更令人欣慰的是，JBOSS的设计者并没有将这个拦截器固化在其核心内，而是采用一种插件式（plug-in）的方法来设计，因此你只要实现它的插件接口，你甚至可以写出自己的拦截器来，当然，这已不属于本文的讨论范围之内了。 值得注意的是最后一个拦截器，它有一些特殊，因为它才真正地执行对实际的EJB的调用⑧，它能检测到客户端是否和EJB对像在同一个Java虚拟机中，如果是的话，它只是简单地将这个调用直接传给EJB对像，这样做的原因是可以避免由于网络传输带来的不必要的开销，使用调用速度大大加快。 上图中的3种方案都有其利弊，但我们觉得最后一个方法要比前2个好，原因如下： 因此，我们选择了最后一种方案来做为JBOSS的集群策略。其实，只要大家再仔细回顾一下前面的部分，就会发现我们先前描述的方案不正是第3种方案吗？但我们现在必须对这个策略在以下几个方面做一些更深入的分析： 负载平衡的设计策略 前面已经说过，JBOSS的负载平衡与失效转发策略是由最后一个拦截器实现的（上图中的①），然而我们要考虑的是虽然客户端只发出一个调用，但针对于代理对像的调用可能包含多个可用的服务器结点，其个数等于集群中所有有效节点之和（参见上图中的②），那么到底是由谁来决定这个策略的呢？这个工作由一个叫插件式的负载平衡策略来实施的（在下一段中简称策略①,如下图）。  当客户端调用到达最后一个拦截器的时候，拦截器会请求策略①来为它选择一个服务器结点。如果此结点有效且调用成功，则结果会返回给代理对像，如果失败了，拦截器不会直接将错误返回给代理对像，而是将这个错误信息报告给策略①，并请求它再为客户端选择一个新节点。 但还有一个问题值得考虑的，就是对一些致命性错误的处理。例如某个数据库服务器突然崩溃了，那么最后一个拦截器将无法对此进行失效转发了，因为不管选择哪个服务器结点都不能解决这个问题了，在这里拦截器会将错误报告给客户端，并由其自已做出决定。 IT界里好像有这样一个原理，就是"越是可扩展性强，灵活的东西实施起来就越复杂"。在JBOSS中也不例外，但幸运的是这些工作并没为给客户端带来额外的编程负担，因为所有策略的配置都是在服务器完成的。 JBOSS的集群配置遵循XML规范，下面是的一个普通EJB对像的典型集群配置：
上述配置说明了一个名为MySessionBean的会话Bean的集群策略，它定义了名为DefaultPartion的缺省策略名称，并定义了2个具体的策略。当然，如果你觉得它比较复杂，而只想用JBOSS缺省的集群策略的话，可以将整个＜cluster-config＞标签去掉。 服务器结点拓扑图的刷新 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，并将结果返回客户端代码。 性能考虑 结论 |
