JBoss企业级应用服务平台群集指南(三)

1.1.3    负载均衡政策

JBoss 客户端拦截器（stub）和负载平衡系统都使用了负载平衡策略来决定把新请求发送给哪个节点。让我们来看看 JBoss AS 里的负载平衡策略。

1.1.3.1 JBoss AS 3.0.x

在JBoss 3.0.x中, 有以下两种负载均衡选项。

 

u  Round-Robin (org.jboss.ha.framework.interfaces.RoundRobin): 每次调用都分派给新节点。第一个目标节点从列表里随机选择。

u  First Available (org.jboss.ha.framework.interfaces.FirstAvailable): 选择其中一个可用目标节点作为主目标节点，用于每次调用：这个节点是在群集里的节点列表里随机选取的。当目标节点的列表改变时（因为有节点启动或退出），除非当前选用的节点仍然可用，这个策略会重新选择一个目标节点。每个客户端拦截器或者负载平衡系统都会根据自己的策略独立地选择目标节点。

1.1.3.2  JBoss AS 3.2+

在 JBoss 3.2+ 里，有三个负载平衡策略可用。其中 Round-Robin 和 First Available 选项和 JBoss AS 3.0.x 里的一样。

 

JBoss 3.2 里的新的负载平衡选项是 "First AvailableIdenticalAllProxies" (org.jboss.ha.framework.interfaces.FirstAvailableIdenticalAllProxies)。它与 "First Available" 有相同的行为，但选取的目标节点由所有同一 "family" 的客户端拦截器共享。

在 JBoss 3.2（或更新的版本）里定义了 "Proxy Family" 标识。代理族（Proxy Family）是所有对同一被复制目标调用的 stub interceptors 的集合。拿 EJB 来说，在给定群集里所有以同一 EJB 为目标的 stubs 属于同一代理族。给定族里拦截器共享相同的目标节点的列表。每个拦截器也能够与同一族里的其他拦截器共享任何信息。在图 3.1, “在 EJB 2.x 中的Stateless Session Bean”里给出了代理族的一个用例。

1.1.4    Farming部署

把应用程序部署到群集里最简单的方法就是使用 farming 服务。那就是在任何群集节点的 all/farm/ 目录下热部署（hot-deploy）应用程序档案文件（如 EAR，WAR 或 SAR 文件），而且应用程序自动地在同一群集里的节点间复制。如果节点后来才加入到群集里，它会引入群集里所有用 farm 部署的应用程序并在启动时把它们部署在本地。如果你从某一正运行的群集节点的 farm/ 文件夹里把应用程序删除，这个应用程序将从本地移除并从所有其他群集服务器节点 farm 文件夹移走（触发移除）。对于当前未与群集系统相连的服务器节点，你应该手工地从 farm 文件夹里把应用程序删除。

 

在 JBoss AS 发行版本里，Farming 在 all 配置里是缺省被启用的，所以你不需要自己来设置它。配置文件放在 deploy/deploy.last 目录下。如果你想在自定义的配置文件里启用 farming，只需要建立如下所示的 XML 文件（farm-service.xml）并把它拷贝到 JBoss 的 $JBOSS_HOME/server/your_own_config/deploy 目录下。请确保你的自定义配置文件启用了群集系统。

 

在部署了 farm-service.xml 之后，下面所列是配置 farm 所需的 FarmMemberService MBean 属性。

 

u  PartitionName 指定了部署这个farm的群集的名字。它的缺省值是 DefaultPartition。

u  URLs 指向部署者（deployer）用来观察文件部署的目录。如果这个目录不存在，MBean 将创建它。而且，"." 指向配置目录（也就是：$JBOSS_HOME/server/all/）。

u  ScanPeriod 指定了扫描文件夹变化的时间间隔。它的缺省值是 5000 。

 

Farming 服务是 URLDeploymentScanner 的扩展，它扫描 deploy/ 目录下的热部署（hot deployment）。所以，你能够使用 FarmMemberService MBean 里的 URLDeploymentScanner MBean 定义的所有属性。实际上，上列 URLs 和 ScanPeriod 属性都是从 URLDeploymentScanner MBean 继承过来的。

1.1.5    分布式状态复制服务

在群集服务器环境里，分布式状态管理（distributed state management）是群集系统必须提供的一个关键服务。例如，在 stateful session bean 应用程序里，会话状态（session state）必须在所有节点的 bean 实例中同步，这可以使客户应用程序获得相同的会话状态，而不用管是哪个节点处理请求。在 entity bean 应用程序里，bean 对象有时候需要跨群集地缓存来减少数据库负载。目前，JBoss AS 里的状态复制（state replication）和分布式缓存服务（distributed cache service）由两个途径提供：HASessionState MBean 和 JBoss Cache framework。

 

u  HASessionState MBean 为 EJB 2.x 的 stateful session beans 和 JBoss 3.x 和 4.x 里的 HTTP 负载平衡提供会话复制（session replication）和分布式缓存服务（distributed cache service）。all/deploy/cluster-service.xml 文件里定义了这个 MBean。我们会在后面的 EJB 2.x stateful session bean 部分展示它的配置选项。

JBoss Cache 是个一个能用在任何应用程序和独立服务器环境里的分布式缓存框架。它逐渐地代替了 HASessionState 服务。JBoss AS 集成了 JBoss Cache 来为 HTTP 会话，EJB 3.0，entity beans 和 Hibernate 持久化对象 （persistence objects）提供缓存服务，每个缓存服务都在不同的 MBean 里定义。我们将在后面讨论特定服务时介绍这些 MBean。