![关闭 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
开始之前
本教程将讨论在企业的 Web 基础设施中使用 IBM® WebSphere Extended Deployment（以下称为 WebSphere XD）作为服务质量扩展机制所涉及的各个概念。其中将给出动手示例，说明如何设置 WebSphere XD 多单元路由场景。本教程中的信息主要基于 WebSphere Application Server ND 6.0.2 上的 WebSphere XD 6.0.2。
本教程的目标读者是熟悉 WebSphere Application Server 并希望了解如何改进 WebSphere 的基础设施的 IT 架构师。本文针对需要配置 WebSphere XD 多单元路由场景的从业人员。
现在，客户要求公司的 Web 基础设施具有出色的可用性。很多业务关键性应用程序的承载都需要予以特别关注，如基于 Web 的银行股票交易应用程序或保险公司的索赔处理应用程序。这进一步增加了对灵活、安全且高度可伸缩的基础设施的需求，以实现当今客户所需的服务质量。
通常，各个公司都将其环境以结构方式划分（甚至以物理方式划分）为不同的层。在当今体系结构中，您很可能看到中间件驱动的方法。此方法让公司获得一个中央层，所有 Web 通信流量都位于其中并在其中进行处理，而其他企业信息系统都通过各种协议在其中集成。这些公司通常具有多个层次，如隔离区（也称为 DMZ）、客户端层（视为外部客户端驻留的区域）以及企业信息层（主机系统、数据库等）。
不过，本教程的重点是中间件层。更为仔细地观察这个层之后，您会发现 IBM WebSphere Application Server（以下称为 Application Server）堆栈驻留在其中。中间件层进一步划分为不同的逻辑域，称为“单元”。对于前面介绍的多层次方法，有多个充分的理由（技术和组织）将公司甚至企业集团的 WebSphere 基础设施划分为单元：
- 对于需要全天候服务的情况，WebSphere 基础设施划分为不同的可管理部分，以实现最高的可用性。
- 考虑到灾难恢复的问题，最好将两个地理位置不同的数据中心也划分到不同的逻辑域。
- 从操作的角度而言，最好对企业集团内的子公司进行分离。
在中间件层边缘（我们将边缘视为层次间转换发生的地点），很可能会存在其他组件，如代理服务器等。例如，IBM HTTP Server 及其包括的 Web 服务器插件可充当代理。它们负责缓存内容、保护应用服务器不受到太多工作负载平衡的影响。而正是由于这个原因，这些组件被视为服务质量（以下称为 QoS）推动因素，能帮助客户满足其 Web 应用程序的这些高可用性需求。在有些情况下，具备有限 QoS 功能的组件（如代理 Web 服务器）可能就足够了。不过，在很多其他情况下，公司可能会需要一组高级的 QoS 功能。
这个时候，WebSphere XD 就可以扮演服务质量扩展机制的角色。在充当这个角色的时候，WebSphere XD 引入了归入“动态操作”的很多新功能。其中之一为“随需应变路由器”（On Demand Router，ODR），可用于充当帮助实现性能目标的智能代理。
为了让您了解此功能，让我们假定公司为其客户提供三个应用程序：股票交易、账户管理和金融建议。让我们进一步假设，股票交易应用程序是最重要的应用程序，其用户需要最佳的性能。WebSphere XD 让您为其中每个应用程序定义具体的性能目标（遵循您正式定义的服务水平协议），并尝试通过基于内容的路由、请求流优化和用户请求重新排队来实现这些目标。
本教程将帮助您了解多层及多单元 WebSphere 基础设施中的 WebSphere XD 的高级 QoS 功能。本教程包括两个部分：
- 第一部分提供关于多单元路由、动态操作和核心组桥接服务。
- 第二部分提供逐步的详细说明，介绍如何设置两个 WebSphere XD 单元间的核心组桥接配置。
有关 WebSphere XD 的更多信息，请参见 WebSphere XD 6.1 Operations Optimization 文档。
下面部分将从技术的角度讨论 WebSphere XD 在多单元环境中的角色。将从较为抽象的角度对多单元路由场景进行描述。
图 1 显示了以真实的客户环境为基础的情况。
图 1. WebSphere XD 多单元场景
WebSphere XD 用例主要由三个层次组成，即客户端层、DMZ 层和中间件层。所有最终用户（使用基础设施的人）都可以视为客户端层的一部分（此时我们并不区分内部网和外部网应用程序）。他们访问公司的 Web 基础设施及其业务应用程序的唯一方法是通过安全代理（例如，IBM Tivoli® Access Manager 的 WebSEAL），安全代理负责对用户进行身份验证和控制对后端 ODR 单元（单元 A）的访问。如果不需要这个额外的安全性，则可以在 DMZ 中放置一个普通代理服务器。切勿在 DMZ 中放置任何 WebSphere XD 组件。尽管文档中认为可以，但我们强烈建议不要这样做，因为 WebSphere XD 组件尚不够成熟。最后，该场景定义了中间件层，公司的所有 WebSphere Application Server 和所有 WebSphere XD 组件都驻留在其中。
正如前面提到的，WebSphere XD 是这个层次的边缘，在该场景中具有重要的作用。由于 WebSphere XD 单元被视为安装在其他 WebSphere XD 单元中的各种业务应用程序的唯一入口点（通过相应的防火墙和安全代理配置实现），所有的 Web 通信都将通过随需应变路由器。因此，将使用整个 WebSphere XD 的 QoS 功能堆栈。为了设置到其他 WebSphere 单元的路由，必须配置“多单元路由”。通过这样，您的 ODR 就可以接收路由信息（服务策略、工作类等等），而且可以实现到外部单元的自动路由。为了建立这种跨单元的通信，要使用 WebSphere 的核心组桥接服务。
在前面的部分中，我们从较为抽象的角度描述了使用 WebSphere XD 的多单元路由真实场景。此部分将更为详细地讨论该场景的 WebSphere XD 配置。
多单元路由场景的核心组件是 ODR，该组件被视为智能路由器。该组件基于 WebSphere 代理服务器，负责控制 HTTP/HTTPS 通信流量。在我们的场景中，ODR 负责处理进入其他 WebSphere 单元的业务应用程序的所有 Web 通信。除了作为代理之外，ODR 还具有智能请求路由的特殊高级功能：
- 请求分类——ODR 根据现有路由策略（如以“/StockTradingApplication”开头的 URL）对传入请求进行分类。这就将 Web 通信归入不同的类别，其中每个类别都映射到您环境中特定的应用程序。这正是为何要将此功能视为以下功能的基础的原因。
- 流控制和队列——除了请求分类外，ODR 负责控制请求流，此功能允许根据所定义的标准更改请求流。
- 优先排序——与更改传入请求的顺序（由流控制进行描述）相对，优先排序允许 ODR 对请求流应用特定的逻辑或规则集。例如，可以说，相对于实现总体业务目标而言，请求 A 比请求 B 重要。将首先路由请求 A，即使在请求 B 早到达的情况下也是如此。
- 动态工作负载管理——WebSphere Application Server 提供了为后台应用程序集群定义权重的选项，从而让您决定每个集群成员处理多少通信流量（例如，50/50 或 20/20/60）。此类决策通常根据每个集群成员的基础硬件的硬件装置作出。不过，ODR 将不断从作为路由目标的所有服务器或集群成员获取运行状况信息，并最终动态地分配这些权重。由于这个原因，ODR 能更好地利用硬件资源，且保护服务器不会承担太多的工作负载。
- 动态应用程序布置——如果是典型的 WebSphere 环境，则可以将集群视为所属 WebSphere Application Server 数量固定的环境。但是，如果 X 台服务器不足以满足特定负载条件下的需求，该怎么处理呢？为了处理这个局限，WebSphere XD 提供了动态集群。与静态的“普通”WebSphere 集群（手动定义成员数和权重）相比，动态集群具有成员数量会动态变化的特征。其数目取决于位于 WebSphere 前的 ODR 的流入工作负载和信息。ODR 会辨认必须增加服务器实例数量的情况，并最终通过将信息提交给目标 WebSphere XD 单元来完成此任务。
正如前面提到的，ODR 需要定义其能够实现的目标的标准。此工作的起点是服务策略（与服务水平协议类似）。每个策略都设置了满足特定业务需求的性能目标（例如，平均响应时间 < 2 秒）。例如，可以定义三个服务策略来建立不同的 QoS 标准：黄金标准（平均响应时间 < 1 秒）、白银标准（平均响应时间 < 2 秒）和青铜标准（平均响应时间 < 3 秒）。总的来说，服务策略和请求分类结合，提供了 ODR 的路由决策基础。
为了建立对服务策略的映射，WebSphere XD 允许为每个 WebSphere 应用程序定义工作类。此配置选项可帮助 ODR 根据所定义的模式对请求进行分类（对于 HTTP 请求的情况，常见的模式为 /myStockTradingApplication/*），旨在对需要相同 QoS 的请求进行分组。最后，一个工作类通过名为事务类的中间组件绑定到特定的服务策略。
为了帮助了解所有组件一起工作的情况，图 2 给出了关于 ODR 如何使用服务策略和工作类以及如何进行路由的简单概述。
图 2. ODR 路由概述
请求流送达 ODR 后，将根据所定义的工作类对其进行分类。在多单元路由场景中，此配置甚至跨 WebSphere 单元边界共享。请求缓存在不同内部队列中。在下一步中，路由器会将排队的请求与可用的服务策略相关，并可能会更改请求流，以满足性能目标。进行了优先排序后，ODR 会动态地将请求路由到可用的目标应用服务器。请注意，图 2 中给出了最简单的示例，其中每台服务器权重相同。
正如前面讨论的，ODR 需要不同的配置部分（如服务策略和工作类）来完成其作为智能路由器的工作。WebSphere XD 配置通常通过 WebSphere 管理控制台进行，因此存储在单元的配置存储库中。WebSphere XD 提供了名为公告牌 (bulletin board) 的动态配置服务，允许将配置项目分散在整个单元内。其内部使用 WebSphere Distribution and Consistency Service（以下称为 DCS）进行基础通信。您可以将 DCS 设想为在给定 QoS 的情况下在组件间共享信息的机制。
在我们的多单元路由场景中，由于必须跨单元边界共享路由信息（而且还必须在外部公告牌发布），因此事情更为复杂。正如真实场景部分中所示，最好在企业级的环境中为 DOR 创建独立的单元。由于这个原因，您需要在单元之间建立链接，以便能够在其间共享配置项。此链接通过使用核心组桥接创建，后者允许 WebSphere 单元彼此进行通信。
为了帮助您了解核心组桥接的概念，需要对术语“核心组”进行澄清。核心组定义为 WebSphere 单元中的 Java™ Virtual Machine（以下称为 JVM）进程的物理分组。按照其定义，此类核心组也视为特定服务的高可用性域。缺省情况下，每个单元都存在一个名为 DefaultCoreGroup 的组，所有集群、服务器、节点代理和部署管理器都是该组的成员。核心组桥接让不同单元的 JVM 进程彼此通信和共享其配置。
图 3 给出了核心组桥接配置在连接两个单元时的概略情况。请注意，图中显示了单元 A 的角度的设置。
图 3. 核心组桥接配置示例
对于每个核心组桥接场景，需要在每个单元中配置访问点组。这是彼此通信的核心组的集合。缺省情况下，有一个名为 DefaultAccessPointGroup 的访问点组，该组也将在下面的部分中用于设置桥接。访问点组的目的是为了定义单元对外公开的接口（称为访问点）和定义外部单元的接口（称为对等访问点）。因此，访问点组配置被视为核心组桥接的基础。在真实场景中描述的示例中，从 ODR 单元的角度而言，我们有一个访问点和两个对等访问点。
正如前面提到的，访问点属于单元的访问点组，定义将会向其他单元公开哪些接口。更为准确一些，这些接口称为桥接接口。此类接口的配置包括特定的核心组成员。主机名和端口由 WebSphere XD 动态获取。由于高可用性的原因（核心组被视为高可用性域），至少必须为每个访问点配置两个桥接接口。这些一起形成了外部单元角度的入口点。
除了单元公开的接口外，还必须制定属于访问组的远程端点。由于这个原因，故而使用对等访问点（定义外部单元公开的端点）表示对等单元。这些是指定的对等端口，由主机名和端口对组成。对于桥接接口，由于高可用性的原因，您至少必须定义两个对等端口（每个对等访问点）。
在下一部分，您将设置多单元路由场景。
标签
使用 滑动条 调节标签的数量。
热门标签 显示了特定专区最受欢迎的标签（例如 Java technology，Linux，WebSphere）。
我的标签 显示了特定专区您标记的标签（例如 Java technology，Linux，WebSphere）。