超级集群解决方案，第 1 部分: 实现应用程序的最大可伸缩性的技巧

从该文章可以学到：
1）、核心组
2）、HTTP插件
3）、代理服务器集群
如果您的应用程序的客户机负载压力非常大，该怎么办？面对大量的客户机或客户机请求，需要使用大量的应用服务器来处理负载。这类 问题的常见解决方案就是利用 IBM® WebSphere® Application Server Network Deployment 集群，但是，如果普通规模的集群仍然无法处理所需的应用程序负载，那又该怎么办？

来自 IBM WebSphere Developer Technical Journal。

简介

对于大多数企业软件拓扑结构，应用程序可伸缩性是一项重要的服务品质。为了实现可伸缩性，企业级 Java™ EE 应用程序通常被部署到 IBM WebSphere Application Server Network Deployment 集群 中，并在其中执行。然而，集群的实际大小是有限制的。如果集群的规模还不足以处理所需的应用程序负载，该怎么办？

这个共分 2 部分的系列文章介绍了一种有用的技巧，可以在 WebSphere Application Server 中实现最大程度的应用程序可伸缩性，我们将之称为超级集群。 本系列的第一部分介绍了将应用于 HTTP 插件和 WebSphere Proxy Server 的 “超级集群” 技巧。第 2 部分将讨论 DMZ Secure Proxy Server for WebSphere Application Server、IBM WebSphere Virtual Enterprise 随需应变路由器（ODR），以及 IBM WebSphere eXtreme Scale。

回页首

集群

为 了实现可伸缩性，企业级 Java EE 应用程序通常被部署到 WebSphere Application Server Network Deployment（此后简称为 Network Deployment）集群，并在其中执行。客户机请求跨越集群进行路由，因此将在所有应用服务器进程之间分配工作负载。

图 1. 分布在集群成员之间的客户机请求

您可以点击如下链接，马上下载 WebSphere Application Server 软件 v7 版本，体验其为您带来的新特性及新功能。 WebSphere Application Server for Developers v7（完全免费） WebSphere Application Server v7 试用版 WebSphere Application Server Express v7 试用版 WebSphere Application Server Hypervisor Edition 试用版（虚拟映像） 更多关于 WebSphere Application Server 的技术资源，请参考： WebSphere Application Server 产品专题：为您提供了 WebSphere Application Server 相关的文章、教程、多媒体课堂等最新技术资源。 WebSphere Application Server V7 专题：为您总结了与 WAS V7 相关最新的内容和资源，其中包括入门介绍及开发技巧、配置与管理、迁移、监控与测试等。

• 亲缘性（affinity）

  如 果应用程序使用无状态的方式进行设计，那么请求将被路由到包含已部署应用程序的任意 Network Depoloyment 集群成员中（无请求亲缘性）。然而，根据协议和应用程序设计，客户机请求可以与特定的 Network Deployment 集群成员具有一种亲缘性。例如，一个 HTTP 会话可能会在处理第一个请求的集群成员中创建，因此该客户机的所有后续请求应当发送到相同的集群成员。亲缘性例子包括 HTTP 会话与 HTTP 协议的亲缘性、SIP 会话与 SIP 协议的亲缘性、IIOP 的事务亲缘性，等等。大多数路由器组件在向集群成员（应用服务器）转发请求时都可以维护相应的亲缘性。

• 故障转移

  除 可伸缩性以外，将应用程序部署到 Network Deployment 集群可以提供高可用性。如果其中一个集群成员失败，那么路由器可以将客户机请求传递到其他集群成员上的应用程序中。使用会话故障转移机制将在出现 HTTP 或 SIP 会话时提供透明的故障转移机制。

• 管理

  尽 管理论上可以使用非集群式的 Network Deployment 实例在上文提到的模式中获得可伸缩性，但是使用 Network Deployment 集群将提供巨大的管理优势。与部署在非集群式 Network Deployment 实例中的应用程序相比，集群式 Network Deployment 实例中的应用程序在启动、停止、安装、卸载或更新方面得到了简化。事实上，部署在非集群式 Network Deployment 实例中的应用程序的管理是一个容易出错的过程。

集群规模限制

IBM WebSphere Application Server V6.0 引入了一个称为高可用性管理器（HAM）的组件。该组件同时提供了称为核心组（core group）的新配置属性。虽然对高可用性管理器和所有相关功能的讨论超出了本文的范围，但是核心组构建规则会对集群规模的限制产生影响，因此需要对核心组有一个基本的了解：

• 核心组

  核 心组指一个静态的高可用性域，其中包含一组紧密耦合的 WebSphere Application Server 进程。WebSphere Application Server cell 中的每个进程都是核心组的一员。核心组进程建立通向彼此的网络连接，并使用这些连接监视和判断某个进程是否正在运行，或者发生故障。核心组的所有成员以网 状拓扑结构彼此连接，如图 2 所示。

  
  
  图 2. 核心组中的 WebSphere Application Server 进程
  
  超级集群解决方案，第 1 部分: 实现应用程序的最大可伸缩性的技巧
  

  JVM 之间的紧密耦合提供了较低的消息延迟（任何成员之间只有一个网络跳转）和快速的故障检测。然而，充分互联的拓扑结构也较大地限制了核心组的可伸缩性。因 此，核心组不能像 cell 那样进行同等程度的伸缩，并且较大的 cell 需要划分为多个核心组。根据特定 WebSphere Application Server 环境在核心组之间的通信需求，各个核心组需要使用 核心组桥接服务（core group bridge service，CGBS）连接在一起。

  
  
  图 3. 大型 WebSphere cell 中的多个核心组
  
  
  
• 核心组构建规则

  良好构建的核心组应当遵循核心组构建规则进行创建，如 WebSphere Application Server Information Center（参考 参考资料）中所述。其中一条构建规则表明，一个 WebSphere Application Server 集群不能超出一个核心组。换言之，集群中的所有成员必须是同一核心组中的成员。这条规则意味着 WebSphere Application Server 集群的最大大小潜在地受到核心组最大大小的限制。

  
  
  图 4. 集群必须是核心组的子集
  
  
  
• 核心组大小限制

  如果包含有过多成员的话，核心组可能无法正常工作。核心组成员的精确数量限制取决于多个因素，包括可用的 CPU 资源、内存资源、网络带宽、应用程序数量、应用程序类型，等等。因此，无法定义一个精确的限制。然而，如果要制定计划，IBM 提供了以下指导原则：

  • WebSphere Application Server V6.0.2：当接近 50 个成员时，考虑使用多个核心组。
  • WebSphere Application Server V6.1 或 V7.0：当接近 100 个成员时，考虑使用多个核心组。

  注意，以上仅仅是一些指导原则，并且只有对您自己的拓扑结构进行了测试才能确定具体的限制。但是，这些指导原则表示一个 Network Deployment 集群的最大大小应当被限制为 50 到 100 个成员之间。

挑战

您 已经看到，Network Deployment 集群的最大大小受到核心组的最大大小的限制，这意味着集群的最大大小被限制为 50 到 100 个成员之间，具体取决于硬件、拓扑结构、应用程序等因素。这是一个可伸缩的数量，可为大多数应用程序提供足够的伸缩性。然而，如果应用程序需要极端的可伸 缩性，该怎么办？如果应用程序的可伸缩性需求要求部署到超过隐含限制的集群中，又该怎么办？如何将应用程序部署到大量 Network Deployment 实例中，同时又能尽量保留单一集群部署的管理优势？

答案就是超级集群。

回页首

超级集群

虽 然应用程序的可伸缩性需求很少会超过单个 WebSphere Application Server 集群的处理能力，但是确实存在这样的情况。对于这些场景，可以使用一种技巧来解决这种隐含的集群大小限制，那就是定义一个超级集群或 “集群式集群” 的拓扑结构。超级集群就是指一种具有层次结构的集群，您可以将其看作是典型 WebSphere Application Server 集群的一般化。

图 5. 具有层次结构的超级集群

对于具有某种抽象程度的集群式拓扑结构，某些类型的路由器组件将把客户机请求转发给部署在集群中的应用程序。考虑将应用程序部署到多个集群中，这样每个集群将具备以下特征：

• 每个集群都属于它自身的核心组。
• 包含数量适中的成员。

如果路由器可被配置为将客户机请求转发给每个集群中的成员，那么就可以有效地解决集群大小受限的问题。理想情况下，您希望路由器执行一个合理的负载平衡策略，同时维护必要的服务器亲缘性。因此，典型的超级集群将执行如下操作：

• 将一个应用程序部署到多个集群（或集群式集群）。
• 使用相应的路由器分发客户机请求，这样，从客户机的角度来看，具有两层结构的集群看上去就像是一个扁平结构的单层传统 WebSphere Application Server 集群。

正如您所料，超级集群受到以下几个限制：

• 目前，超级集群化技术只能应用于 HTTP 协议，而对于 IIOP 或 SIP 等其他协议是无效的。
• 对于 HTTP 协议，某些路由器将自动把请求转发给部署在多个集群的应用程序，而其他路由器则需要手动修改路由数据，才能够将客户机请求分发到部署在多个集群中的应用程序。
• 与传统集群中的应用程序部署不同，超级集群中的应用程序部署并不是一个单步过程，而是涉及到多个步骤。

为 了演示超级集群的使用，现在假设一个应用程序需要运行在包含 120 个成员的集群中，从而满足客户机负载需求。对于这个例子，可以创建三个新的核心组，在每个核心组中创建一个包含 40 个成员的集群，然后将应用程序部署到这三个集群中。假设使用的是熟悉的 HTTP 插件路由器，生成的超级集群拓扑结构类似于图 6。

图 6. 包含 120 个成员的超级集群

如前所述，在超级集群拓扑结构中可以使用各种各样的路由器。下一小节将具体介绍如何配置和使用各种不同的路由器，以及它们的限制和局限性。所有示例都基于 WebSphere Application Server V7。

回页首

HTTP 插件

本节介绍了如何设置和配置超级集群，使用的路由器为 WebSphere Application Server HTTP 插件。考虑到本文的目的，请参考图 7 所示的包含两个集群的示例。

图 7. 使用 HTTP 插件的超级集群

为了将样例数据保持在一个合理的范围内，对样例拓扑结构故意施加了限制。然而，这里介绍的技巧可以很容易进行扩展，从而能够应用到更大型的拓扑结构中。

配置使用 HTTP 插件路由器的超级集群拓扑结构的基本步骤包括：

1. 创建一个 WebSphere Application Server 集群。
2. 将应用程序安装到集群中。
3. 测试和检验应用程序。
4. 创建额外的 WebSphere Application Server 集群。
5. 将应用程序模块映射到每个集群。
6. 生成 HTTP 插件文件（plugin-cfg.xml）。
7. 编辑 plugin-cfg.xml 文件，以将请求路由到多个集群中。
8. 将修改后的 plugin-cfg.xml 文件复制到相应的 Web 服务器位置。

这些步骤中的大部分都属于标准 WebSphere Application Server 管理任务（创建集群、安装应用程序、生成插件等等），并且执行这些任务的说明已经被很好地归档到 WebSphere Application Server Information Center 中。然而，其中两个步骤 —— 即步骤 5 和步骤 7 —— 需要进行一些解释。让我们仔细查看这些 “有些陌生” 的步骤，看看这个简单示例涉及了哪些内容。

将应用程序模块映射到多个集群

考虑两个 WebSphere Application Server 集群，称为 Cluster1 和 Cluster2：

• 每个集群包含两个成员（图 8）。
  
  图 8. 包含两个集群的拓扑结构
  
  
  
• “Ping”（图 9）是一个简单的 Java EE 应用程序，它被部署到 Cluster1 中。
  
  图 9. Ping 应用程序
  
  
  
• 这里的目的是从 Ping 应用程序中将应用程序模块映射到 Cluster1 和 Cluster2。具体做法是通过使用管理控制台访问 Ping 应用程序的配置页面。要管理应用程序模块，从 Ping 应用程序配置页面（图 10）中选择 Manage Modules 链接。
  
  图 10. Ping 应用程序配置
  
  
  
• 从 Manage Modules 配置模板（图 11）中，您应当能够将应用程序模块映射到部分或所有已配置的集群和服务器。要将应用程序模块映射到多个目标：
  1. 选择需要映射的模块。
  2. 选择一个或多个集群或服务器（提示：按住 CTRL 键以选择多个目标）。
  3. 单击 Apply 按钮。
  4. 查看映射，如果满意的话就单击 OK。
  5. 保存并同步修改。
  
  
  图 11. Ping 应用程序 – 管理模块
  
  
  

注意，除了这两个集群外，应用程序的 Web 模块也被映射到一个 Web 服务器。这是因为在这个例子中，Web 服务器被配置为一个未管理的节点，并且 WebSphere Application Server 被用于管理 Web 服务器。

图 11 描述了 Ping 应用程序的模块被映射到全部两个已配置集群 Cluster1 和 Cluster2。应用程序模块被映射到多个集群后，可以继续生成并编辑 plugin-cfg.xml 文件，下面将进行介绍。

编辑 plugin-cfg.xml 文件

一 旦将应用程序模块映射到多个集群后，下一步就是生成插件配置文件（plugin-cfg.xml），该文件供 HTTP 插件代码用于路由 HTTP 请求。如果您曾经使用过 HTTP 插件，那么应该对生成 HTTP 插件配置文件的过程很熟悉。这个过程已有大量详细解释，因此这里不再累述。实际上，可以在 WebSphere Application Server 管理控制台中使用多种选项来根据已配置的拓扑结构生成该文件。图 12 描述了根据应用程序部署拓扑结构生成的 plugin-cfg.xml 文件的有关片段，其中 Ping 应用程序被映射到已配置的两个集群。注意，plugin-cfg.xml 文件包含两个集群的定义，每个集群包含两个成员。

图 12. 包含 ServerCluster 定义的 plugin-cfg.xml

HTTP 插件路由器将根据客户机请求（URL）和 plugin-cfg.xml 文件中包含的信息作出路由决策。客户机请求为 HTTP 插件路由器提供以下信息：

• 主机名
• 端口
• URI

HTTP 插件实现将解析 plugin-cfg.xml 文件的内容，查看可以适当处理客户机请求的相应目标。HTTP 路由器将请求发送给它所找到的第一个匹配目标。对于集群，HTTP 路由器将客户机请求发送给 ServerCluster 元素中内嵌的所有 Server 因素。路由器并不会检查 Server(s) 是否确实来自于已配置的 WebSphere Application Server 集群。在路由请求时，HTT 路由器将对负载分配使用指定的 LoadBalance 策略，同时维护会话亲缘性。

编辑 plugin-cfg.xml 文件的主要目的是使 HTTP 插件路由器相信，分层（超级）集群中的所有成员都属于一个传统的（扁平式）集群。因此，编辑过程包含以下步骤：

1. 确定默认情况下将对应用程序请求使用哪一个集群。
2. 将另一个集群的服务器条目复制到 plugin-cfg.xml 文件中默认处理客户机请求的集群中。

判 断目标集群的最简单方法就是对应用程序进行测试。即使您的应用程序模块被映射到多个集群，默认情况下只有一个集群被用来处理应用程序请求。通常情况下，这 个集群是 plugin-cfg.xml 文件中最后定义的集群。一旦确定了默认的目标集群，您需要将另一个集群中的服务器条目复制到默认集群中。

3. 从所有其他 ServerCluster 元素中将 Server 元素复制并粘贴到默认目标集群中的相对应的 ServerCluster 元素。
4. 从所有其他 PrimaryServers 元素中将 Server Name 元素复制并粘贴到默认目标集群中的相对应的 PrimaryServers 元素。

图 13 展示了更新后的 plugin-cfg.xml 文件中的有关部分，它将来自 Cluster1 和 Cluster2 的成员合并在一起来创建一个超级集群。

图 13. plugin-cfg.xml - 超级集群 – Cluster2

在 上例中，默认的目标集群为 Cluster2。因此，Server 和 ServerName 元素被从 Cluster1 复制到 Cluster2 中。由于修改后的 plugin-cfg.xml 文件被放在合适的位置，因此 HTTP 插件路由器将跨越超级集群的所有四个成员分发请求。

要在超级集群的所有成员之间实现均衡的负载平衡，可以修改 超级集群成员的 LoadBalanceWeight 属性。对于这个特定的例子 —— 假设所有超级集群成员都具有类似的容量 —— 您可以使用 1000、999、998 和 997 作为 LoadBalanceWeight 属性的值，从而实现循环（round robin）负载平衡。

限制

任何超级集群拓扑结构都具有局限性。在使用 HTTP 插件作为路由器时，您应当注意以下这些限制：

• 目前的 WebSphere Application Server 实现只支持对 HTTP 协议实现超级集群。
• 模式只提供了可伸缩性，而没有提供会话故障转移：
  • 没有会话复制报告。
  • 可以对会话故障转移使用 WebSphere eXtreme Scale 或会话持久性。
• 该技巧需要人为地管理 plugin-cfg.xml 文件：
  • 必须手动地编辑 plugin-cfg.xml 文件。
  • 必须禁用插件文件自动生成和传播功能。
  • 必须手动地同步 plugin-cfg.xml 文件与拓扑结构变更。

下一节将继续讨论同一个样例场景，但是将使用 WebSphere Proxy Server 在超级集群间分发请求，而不是 HTTP 插件路由器。

回页首

代理服务器

让我们看看在使用 WebSphere Proxy Server 作为路由器时如何设置和配置超级集群，将继续使用上文中包含两个集群的样例，如图 14 所示。

图 14. 使用代理服务器的超级集群

除了其他重要的功能外，代理服务器还可以将 HTTP 或 SIP 请求转发给 WebSphere Application Servers。代理服务器只不过是众多服务器类型中的一种，可以使用 WebSphere Application Server 管理控制台创建。

图 15. 代理服务器

要配置使用 WebSphere Proxy Server 的超级集群拓扑结构，执行以下步骤：

1. 创建一个 WebSphere Application Server 集群。
2. 将应用程序安装到集群中。
3. 测试和检验应用程序。
4. 创建额外的 WebSphere Application Server 集群。
5. 将应用程序模块映射到每个集群。
6. 将所有包含集群的核心组与包含代理服务器的核心组建立连接。

您 将注意到这些步骤中并没有提及生成或手动编辑任何类型的路由器配置文件。这是因为代理服务器的路由信息是动态获得并更新的。对于超级集群，与使用 HTTP 插件路由器相比，使用代理服务器的优势在于不需要手动编辑任何静态路由信息。权衡点在于所有包含代理服务器的核心组和任何接收请求的集群必须被连接起来。

请求路由

在 前面的 HTTP 插件讨论中已经详细介绍了将应用程序模块映射到多个集群中的步骤，因此这里不再重复。对于本例，如果您已经完成了映射任务，那么现在就可以开始在超级集群 间分发客户机请求了。这里不需要进行额外的配置，因为这个简单示例只有一个单一的核心组。祝贺您，您现在已经可以使用代理服务器在超级集群间分发请求了。

代 理服务器将自动把 HTTP 请求路由到超级集群中的所有成员，同时维护会话的亲缘性。不需要手动编辑任何路由文件。代理服务器将通过高可用性管理器公告栏服务动态获得路由信息。相对 于 HTTP 插件的 “集群级” 路由，来自代理服务器的路由可以被看作是 “应用程序级别的”。代理服务器将路由到部署了应用程序的 cell 中的任意 WebSphere Application Servers。这同时包括集群成员和非集群式应用服务器。

核心组桥接服务

对 于这个简单的示例，您不需要处理任何核心组桥接配置。对于更加真实的场景，可能涉及多个核心组，并且需要配置核心组桥接，以将各个核心组连接起来。这使得 动态路由信息能够从各个集群流向制定路由决策的代理服务器。如果代理服务器和目标集群位于不同的核心组，那么必须设置核心组桥接配置。（参见 参考资料）。

限制

同样，任何超级集群拓扑结构都具有局限性。当使用代理服务器作为路由器时，您应当注意以下这些限制：

• 对于超级集群，代理只支持路由 HTTP 协议。
• 模式没有提供会话故障转移：
  • 没有会话复制报告。
  • 可以对会话故障转移使用 WebSphere eXtreme Scale 或会话持久性。
• 该技巧可能需要用到核心组桥接服务（CGBS）配置；如果代理服务器和集群（应用程序部署目标）位于不同的核心组，那么将需要使用 CGBS。

回页首

HTTP 插件和代理服务器

目前为止，您已经了解了在使用 HTTP 插件或代理服务器作为路由器时如何配置超级集群拓扑结构。现在，让我们看看在什么情况下需要对超级集群拓扑结构结合使用这两种路由器类型。

安全性

对 超级集群拓扑结构使用代理服务器将十分方便，因为不需要手动编辑或管理静态路由配置文件。然而，出于安全性考虑。一些用户可能不希望将代理服务器放到非保 护区（demilitarized zone，DMZ）以外。要解决这个问题，可以在 DMZ 中配置 Web 服务器（使用传统的 HTTP 插件路由器），从而能够将请求转发给位于协议防火墙内部的代理服务器（图 16）。

图 16. DMZ 中路由到代理服务器的 Web 服务器

通 过使用这种配置，DMZ 中的 Web 服务器将使用传统的 HTTP 插件路由器把请求转发给代理集群成员。默认情况下，发往代理服务器的请求分发严格遵守循环规则，并且 Web 服务器不会考虑 HTTP 会话亲缘性。代理集群的成员将把请求转发给超级集群的成员。代理服务器在需要时维护 HTTP 会话亲缘性。这里涉及了一个额外的网络跳转（从 Web 服务器跳转到代理服务器），但是大部分情况下，这算不上严重的问题。然而，对于这种拓扑结构需要特别注意 HTTP 插件配置文件的创建。

生成 plugin-cfg.xml 文件

要 支持通向代理服务器的路由，需要一个特殊的 HTTP 插件配置文件。传统的插件配置文件包含 cell 和应用程序拓扑结构。在这个场景中，插件配置文件只需要理解如何路由到代理服务器。代理服务器本身包含用于生成插件文件和自动分发的机制。要配置插件文件 的生成，必须从代理服务器配置页面访问 Proxy settings 链接，如图 17 所示。

图 17. 代理配置

这里显示的 Proxy settings 链接用于单一的代理服务器配置。如果您的代理集群中包含多个代理服务器，您将需要转到代理集群配置页面来查找相同的 Proxy settings 链接。

对 于本文而言，您需要考虑用来处理插件配置文件的生成和传播的设置。对于这些选项，向下翻滚代理服务器设置页面，知道发现名为 Proxy Plugin Configuration Policy 的区段（如图 18 所示）。您将在这里找到两个用于处理 HTTP 插件配置文件的设置：

• Generate Plugin Configuration

  该值将控制您是否希望让代理服务器生成一个 plugin-cfg.xml 文件以及文件生成的范围。

  
  
  图 18. Proxy Plugin Configuration Policy
  
  
  

  对于插件配置的生成范围，可以指定为 none、All、Cell、Node 和 Server。可以在 <profile home>/etc 目录中找到生成的插件配置文件。

• Plugin config change script

  在 Plugin config change script 字段中，可以输入您希望在完成生成后运行的脚本文件的名称。您可以使用这个选项自动将插件文件传播到所需的 Web 服务器。图 19 展示了代理设置面板中的相同区段，该字段显示的文本为 fly over help。

  
  
  图 19. Proxy Plugin Configuration Policy
  
  
  

本节的关键在于，要将 Web 服务器配置为通过 HTTP 插件向代理服务器路由请求，必须将代理服务器配置为生成插件配置文件。

其他注意事项

目前，生成的 plugin-cfg.xml 仅包含在生成文件时启动并运行的代理服务器。如果对代理服务器进行了配置，但未运行，那么它们将不会出现在生成的 plugin-cfg.xml 文件内。因此，您需要确保使用的是在所有代理服务器启动后生成的文件。

在使用代理服务器生成插件配置文件时，如果对环境做出任何将影响文件内容的修改，那么将自动重新生成 plugin-cfg.xml 文件。这类修改的例子包括：

• 启动新的代理服务器。
• 安装或卸载应用程序。
• 修改虚拟主机定义。
• 修改上下文根。

如果要在生成插件路由文件期间执行恢复或类似操作，可能会在 <profile home>/etc 目录中观察到两个不同版本的路由文件：plugin-cfg.xml 和 plugin-cfg-<member name>.xml。后者是一个临时文件，通常不应用于实际的路由。如果发现多个版本的插件路由文件，那么可以在删除 plugin-cfg-<member name>.xml 文件后重新生成插件路由文件。

代理集群

如 果需要使用多个代理服务器实现高可用性和可伸缩性，建议创建一个代理集群。代理集群最初被用来简化配置：创建一个包含所有必需工件（比如重定向规则等等） 的代理服务器，然后从模板中创建额外的代理服务器（集群成员）。这使您避免了在多个代理服务器中重新配置相同的规则以及其他内容。

回页首

结束语

在 这个共分两部分的系列文章的第一部分中，我们描述了在将 Java EE 应用程序部署到大型集群以进行扩展时遇到的挑战。同时讨论了超级集群（一个分为两层的 WebSphere Application Server 集群）的一般法则，如何将一些用于 HTTP 客户机的应用程序部署到超级集群中，从而实现最大程度的应用程序可伸缩性。

超级集群的原理主要依赖于拓扑结构中涉及的各种路由器的请求转发能力。本文使用涉及传统 Web Server 插件、WebSphere Application Server 典型代理服务器的拓扑结构以及同时使用这两种路由器的拓扑结构作为示例。某些情况下，必须手动修改自动生成的静态路由信息。本文还解释了在多个集群中部署应用程序的技巧。

对超级集群的需求并不会出现在日常的实践中，但是它会出现在 HTTP 客户机中，这种需求可以得到满足。所有超级集群选项都存在某些限制，但是对于给定的场景，这些限制可能是必要的。

对于以下情况，可以考虑使用超级集群：

• 您当前需要超过 100 个成员集群，或者
• 您的部署架构需要足够灵活，从而可以在未来的集群中容纳超过 100 个应用服务器。

尽 管在理论上并没有限制超级集群可以容纳的 WebSphere Application Server 实例的数量，但是不应该将超级集群视为实现可伸缩性的万能解决方案。特定 Java EE 应用程序使用的资源会对这些应用程序的可伸缩性施加限制。例如，对于与数据库有关的应用程序，底层数据库服务器可以承受的数据库连接的最大数量会限制 WebSphere Application Server 实例的数量，而在 WebSphere Application Server 实例中可以同步部署应用程序，因而最终会影响应用程序的可伸缩性。