基于WebLogic的集群Web服务器的实现

摘  要  为了提高Web访问的实时性和吞吐量，本文提出了一种基于WebLogic的负载均衡集群系统的构建方案。应用于我们的Internet网络服务器上，将负载分给多个服务器分担，能够解决Internet服务器面临的大量并发访问造成的CPU或I/O的高负载问题。本文对系统进行了压力测试，实验结果表明该系统能够适应大型商业网站的需求。

    关键词 负载均衡；集群；可伸缩性；可用性

 

 

0  引言

    互联网的出现使信息访问产生了质的飞跃，但随之而来的是Web流量的激增（高并发访问），由于涉及信息量十分庞大，用户访问的频率也高，许多基于Web的大型公共信息系统（如 电子图书馆、 BBS、搜索引擎和远程 教育等）需要在实时性和吞吐量方面都具有较高性能的Web服务器支持。一些热门的Web站点由于负荷过重而变的反应迟缓。如何提高Web服务器的性能和效率成为一个亟待解决的问题。

    实际上，服务器的处理能力和I/O已经成为提高Web服务的瓶颈。如果客户的增多导致通信量超出了服务器能承受的范围，那么其结果必然是服务质量下降。显然单台服务器有限的性能不可能解决这个问题，一台普通服务器的处理能力只能达到每秒几万个到几十万个请求，无法在一秒内处理上百万个甚至更多的请求。显然，采用高性能的主机系统（小型机或大型机）是可行的，但是除了价格十分昂贵外，这种高速、高性能的主机系统，很多情况下也不能解决同时处理几万个并发，因为，高速主机系统只是对于复杂的单一任务和有限的并发处理显得高性能，而Internet中的Web服务器大多数处理是“简单任务”、高强度并发处理，因此即便有大资金投入高性能、高价格的主机系统，也不能很好的满足Web应用的需要。这就是利用Web服务器集群实现负载均衡的最初基本设计思想 ^[1]。

1 负载均衡集群

    高扩展型集群，即负载均衡集群技术 ^[2]，就是带均衡策略（算法）的服务器集群。负载均衡集群在多节点之间按照一定的策略（算法）分发网络或 计算处理负载。负载均衡建立在现有网络结构之上，它提供了一种廉价有效的方法来扩展服务器带宽，增加吞吐量，提高数据处理能力，同时又可以避免单点故障 ^[3]。

    以Web访问为例，后台的多个Web服务器上面有相同的Web内容，Internet客户端的访问请求首先进入一台服务器，由它根据负载均衡策略（算法）合理地分配给某个服务器 ^[4]。

1.1 基于WebLogic的负载均衡集群

    WebLogic支持集群技术，即让一组Server指向同一域名一起工作从而提供一个更强大、更可靠的应用平台。对于客户端而言，无论Cluster中有几个Server在工作，看上去都是一个 ^[5]。集群技术有两个最明显的特色：

    (1)可伸缩性：Cluster对加入其中的Server在性能上没有限制（如普通的PC机），为了提高性能，当客户端的请求大幅增加时，可以动态地向Cluster中添加Server。并且，配置Cluster当一台机器的资源没有被完全利用时，可以在同一机器上启动多个Server，但要求每一个Server使用不同的IP，而不能用同一IP的不同端口。

    (2)高可用性：由于在Cluster中同一service在多个Server上同时存放或放在一个共享文件系统中，因此相同的请求可以有多个Server提供，并且Server间还可以复制状态信息。这样，当其中某一Server宕机或无法响应请求时，其它的Server会立即接管它的任务，从而把应用和客户端完全隔离开来。

1.2  WebLogic 集群的工作机制

    每一个Clustered service,在每一个server上都会有一个instance，即一个replica，这些replicas集合在一起形成一个replica-aware stub。这些stubs负责客户端与相关的服务器段对象的通信，当客户端请求该service时，实际上是向stub发出请求，stub根据不同的算法调用集合中某一replica，如果调用失败，stub会检测到错误并重新调用其它的replica。Cluster支持多种算法：随机、轮循、基于性能的负载均衡的轮循(Weight-based round-robin)、根据参数值调用(Parameter-based routing)。

    WebLogic Cluster通过负载均衡和容错最大程度的实现了它的可伸缩性和可用性。 ^[6] 为了提高Cluster的可伸缩性，必须保证充分利用每一个Server。WebLogic可以在不同平台、不同性能的机器上安装Server并进行Cluster,然后采用Weight-based round-robin算法达到负载均衡，从而使每一个Server都得到充分的利用。

    为了使Cluster具有高可用性，必须具备故障恢复的能力，这一点可以通过replica-aware stub的容错功能来实现。Stub 主要是通过在检测到错误信息时重新进行调用的方式实现容错。当重新调用不会导致错误的结果时(如stub确认failed server不能接收到请求)，容错功能自动实现。而有些情况下，重新调用可能会导致某一service被请求了多次的错误结果。例如：客户端C请求Clustered购物车服务中的additem()方法，replica-aware stub接收到请求，根据算法调用Server1上的service,Server1响应请求并返回结果，但在结果成功到达客户端之前，Server1出现错误。此时stub接收到错误信息，因此重新调用Server2上的这一方法，但实际上Server1已经将item加入购物车，这样就造成重复。为了解决这种问题，可以为服务添加一个唯一标识，如上述的additem()方法中可添加一个参数——序列号。每一个item有一个唯一的sequence,相同sequence的item不能被重复添加。

2 构建WebLogic集群

2.1  Domain和Server

    Domain是WebLogic Server实例的基本管理单元。所谓Domain就是，由配置为Administrator Server的WebLogic Server实例管理的逻辑单元，这个单元是有所有相关资源的集合。

    Server是一个相对独立的，为实现某些特定功能而结合在一起的单元。 ^[7]

    一个Domain 可以包含一个或多个WebLogic Server实例，甚至是Server集群。一个Domain中有一个且只能有一个Server 担任管理Server的功能，其它的Server具体实现一个特定的逻辑功能。

2.2  系统实现方案

    在此，操作系统平台使用Windows 2000，软件使用Bea WebLogic Server 8.1 SP2，程序基于J2EE架构，有以下两种方案：

    a．单层混合型的集群架构（Cluster）

    这种架构将所有的Web应用以及相关的服务应用全部置于集群中的单一WLS实例中，这种架构的优势在于：　　

    易于管理；

    灵活的负载平衡机制；

    更强的安全控制；

    b．多层结构的集群架构（Cluster）

    这种架构使用两个WLS集群，一个放置表静态内容和集群Servlet，另一个放置集群EJB。一般应用于下面这些情况：

　　(1)在负载平衡机制需要调用集群EJB中的方法时；

　　(2)在提供内容与提供对象的服务之间需要更大的机动性时；

　　(3)在需要更高的系统稳定性时；

2.3 集群应用的必要条件

    集群中的所有Server必须位于同一网段，并且必须是IP广播(UDP)可到达的。 ^[8]

    集群中的所有Server必须使用相同的版本,包括Service Pack。

    集群中的Server必须使用永久的静态IP地址。动态IP地址分配不能用于集群环境。如果服务器位于防火墙后面，而客户机位于防火墙外面，那么服务器必须有公共的静态IP地址，只有这样，客户端才能访问服务器。

要以Cluster方式运行，必须有包含Cluster许可的License。

3 系统实现及压力测试

    在配置集群应用前要对集群的配置信息有一个良好的设计，下面就是我们配置的集群信息。如图1：

图1 集群配置信息

机器类型	操作系统	硬件配置	角色
DELL PC	Windows 2000	IP:10.16.92.7 PORT:7080	Administrat or Server
DELL PC	Windows 2000	IP:10.16.92.7 PORT:8080	Proxy Server
DELL PC	Windows 2000	IP:10.16.92.7 PORT:7082	Managed Server
DELL PC	Windows 2000	IP:10.16.92.31 PORT:7084	Managed Server
DELL PC	Windows 2000	IP:10.16.92.32 PORT:7086	Managed Server
DELL PC	Windows 2000	IP:10.16.92.33 PORT:7088	Managed Server

    我们使用了四台DELL-PC机器，其中每个机器都作Managed Server，而选择其中一台机器兼作Administrator Server和Proxy Server。

    管理服务器（Administration Server）是一个WebLogic 服务器实例，它负责配置与管理同一个域里的其它WebLogic Server 实例。管理服务器实例的意外中止对整个域的运行没有什么影响。当一个管理服务停止了，它所管理的其它服务实例(集群的或未集群的)都能正常运行。如果在这个域里存在有集群，集群提供的Failover和负载均衡服务也能够继续而不受影响。 ^[9]

    代理服务器（Proxy Server）是整个网站系统的总入口（和网站的域名对应），它接受web server上所有请求，并转给集群中的某一个Managed Server。Proxy对cluster的所有请求进行负载均衡，并且当请求失败时会进行恢复处理。Proxy还可以在cluster中特别是Server没有正常完成请求响应时保持session状态。当session初始化时，proxy按照负载均衡算法选择一台Server保存session，此后，所有与此session相关的请求都由这同一台Server处理。为了避免当此Server出错时，无法保存客户端状态信息，所以session会被复制下来，并且session的所有变化都会在备份中进行及时更新，这样，当原有Server在响应请求过程中失败时，proxy会立即获取session的备份，并由此继续响应客户端请求，同时做新的复制。

    Managed Server上部署了网站的应用程序，用于执行Proxy Server分发过来的用户请求。

我们对以上的集群系统进行了测试，编写了一个简单的WEB应用，它会在控制台和浏览器上同时打印出“OK”字样，然后将这个WEB应用部署到集群中所有Managed Server上面。在这里我们将通过Apache中所带的ab包来进行并发访问的模拟测试，使用如下的命令进行压力测试。

ab -n 100 -c 10 http://10.16.92.7:8080/index.jsp

    ab是测试程序的名称

    参数n代表请求的总数量

    参数c代表并发的请求数

    url为要测试压力的页面

    使用这个命令时，一定要在系统路径中能够找到该程序，否则不能执行。我们取请求的总数量n等于100，压力测试完成后，我们从Managed Server的控制台上可以看到，nodeA，nodeB，nodeC，nodeD（即四个Managed Server）分别打印出了27、23、24、26个“OK”字样，这说明，在并发请求的情况下，集群能够将请求进行分发，达到了负载平衡的目的。

    另外，我们编写了一个简单的购物车程序，该系统能够在某一台机器宕机后把seesion转交给其他机器，达到了故障接管的目的，增加了Web系统的高可用性。

4 系统故障分析

    我们经常会遇到HTTP 请求在 WebLogic 集群节点之间的负载平衡不均，即，集群中一个或多个节点接收和执行的 HTTP 请求比同一集群中的其它节点多。

    发生这种情况的原因是由于 HTTP 会话分配不均。代理将不包含会话 cookie 的请求转发到基于 round-robin 负载平衡模式的集群节点，并在该节点上创建新会话。 ^[8]理想状态下，所有集群节点应当接收等量的 HTTP 会话。如果没有出现这种情况，则由于负载平衡策略的“粘性”特点，接收较多会话的节点将得到比其它节点数量更多的请求。最终结果是造成集群节点之间负载分配不均。遇到这种问题，可以查看代理插件的有关信息是否正常。

    另一个经常遇到的问题是会话复制失败。会话复制失败通常是因为 网络组播问题引起的。有时候，配置问题也会导致失败。此外，确保输入到会话中的数据必须是可序列化的，否则复制可能会失败。编码的时候也应该注意，比如不要使用 http 会话的 putValue 和removeValue 方法，因为它们不受支持，并且当您在应用程序中使用这些方法时，可能会出现会话数据复制问题。相反，仅使用 HttpSession 的setAttribute和removeAttribute 方法。 ^[10]

    此外，还需要注意静态变量的使用，缓存同步，EJB、Servlet、JSP同步等，在单机环境下不会发生变化的值在集群环境下有可能会发生变化。

5 结束语

    本文提出了一种基于WebLogic的集群Web服务器的设计方案，通过压力测试，系统能够达到负载均衡的目的，该方案已经在某个大型商业网站中使用并取得了很好的效果。