WebSphere Process Server 集群的基本步骤

核心提示：引言提高系统可用性和能力以便适应增加的工作负荷是服务器或进程集群的主要目标，服务器或进程集群可以：提高系统的可用性，WebSphere Process Server 集群的基本步骤，即通过提供冗余进程或硬件组件，确保在发生故障时保持某个级别的服务连续性，您必须知道，可能有各种用于 WebSphere Process S

引言

提高系统可用性和能力以便适应增加的工作负荷是服务器或进程集群的主要目标。服务器或进程集群可以：

提高系统的可用性，即通过提供冗余进程或硬件组件，确保在发生故障时保持某个级别的服务连续性。

提供一种机制，以适应增加的工作负荷（可伸缩性）。

故障转移和可伸缩性这两个概念在很大程度上相互独立；您会发现可以确保可伸缩性的拓朴在保证可用性方面可能不够好，反之亦然。IBM WebSphere Process Server 提供了许多使用集群技术解决可用性和可伸缩性的不同方法。

本文的第一个目标是简要介绍一些 WebSphere Process Server 集群拓朴解决方案，并讨论各种方法的优缺点。然后，将逐步了解设置可能成为最常采用的 WebSphere Process Server 集群拓朴的过程。

WebSphere Process Server 集群的关键拓朴

在较高级别中，每个 WebSphere Process Server 环境都包含三个基本层：WebSphere Process Server 应用程序、消息传递基础结构以及一个或多个关系数据库，如图 1 所示。

图 1. 要集群的组件

WebSphere Process Server 应用程序。WebSphere Process Server 应用程序包括进程服务器基础结构代码，如 Business Process Choreographer 以及利用进程服务器功能的任何用户应用程序。WebSphere Process Server 应用服务器必须随这些应用程序一起安装。在概念上，集群 WebSphere Process Server 应用程序与在 IBM WebSphere Application Server V6 环境中集群普通 J2EE™ 应用程序没有太大区别。

一个或多个关系数据库。WebSphere Process Server 要求在关系数据库表中存储特定应用程序配置信息和运行时信息。为了保证持久性，下文将要讨论的消息传递基础结构也使用了关系数据库表。集群关系数据库以获得可伸缩性和可用性是一种业已建立的良好规程，因此我们不再花费时间讨论集群关系数据库的技术。不过，我们将讨论如何设置必需的数据库和模式，以便支持 WebSphere Process Server 集群。

消息传递基础结构。WebSphere Process Server 还要求使用消息传递基础结构。有些消息传递基础结构必须使用 WebSphere Application Server 服务集成总线（SI 总线）和 WebSphere Default Messaging Java™ 消息服务 (JMS) 提供程序。在本文中，对于 WebSphere Process Server 的任何消息传递需求，我们不考虑使用其他消息传递提供程序。我们假定您将完全依赖于 SI 总线，此时，它是推荐的做法。

集群消息传递基础结构也许是整个关于集群的讨论中最复杂的部分。一般情况下，我们可以这样说，由于我们使用的是 SI 总线，它要求运行 WebSphere Application Server，因此还可以使用 WebSphere 集群技术来集群消息传递基础结构。不过，在选择要采用的拓朴时，需要了解许多注意事项。下面几部分将讨论其中的一些注意事项。

集群消息传递基础结构

WebSphere Application Server SI 总线除提供其他功能以外，还允许您定义应用程序用于发送或检索消息的目的地（如队列或主题）。为了使这些目的地实际可用，可指定一个消息传递基础结构可以运行的应用服务器进程（或进程集群）。可以通过向 SI 总线添加成员 做到这一点。

成员 可以是单个 WebSphere Application Server Network Deployment 单元服务器，也可以是服务器集群。在向总线添加成员时，在该成员上还将创建消息传递引擎。消息传递引擎是实现消息传递基础结构本身逻辑的应用服务器进程中的组成部分。

在作为 SI 总线的成员添加集群之后，每个集群成员都能够运行消息传递引擎。不过，在任何给定时间仅有一个集群成员拥有活动的消息传递引擎。适用于消息传递引擎的高可用性策略是一种 One-of-N 策略。

集群消息传递引擎时存在两个主要选项：

在作为 SI 总线的成员添加集群时，自动创建单个消息传递引擎。刚才已经提到，此操作将创建一个消息传递引擎，该引擎使用 One-of-N 策略实现高可用性，从而激活消息传递引擎的单个实例。

在此情况下，与目的地关联的消息只有一个物理存储库。这种情况可以确保可用性；但是，只有为服务器提供了附加的计算能力（从本质上说，是通过在功能更强大的硬件上配置应用服务器）才能实现可伸缩性。

图 2. 消息传递的活动/备用集群拓朴

多个消息传递引擎同时处于活动状态。将集群添加到 SI 总线时会导致创建第一个消息传递引擎。您也可以在该集群上为 SI 总线手动创建附加的消息传递引擎。每个消息传递引擎按照 One-of-N 策略操作，但是，由于有多个引擎，因此现在可以有多个活动实例。您可以创建自己的高可用性策略，以定义在缺省情况下应在何处运行每个活动实例，从而跨各个集群成员均匀地分布活动引擎。

不过，此解决方案意味着 SI 总线上的目的地是分区的。换句话说，消息传递引擎的每个实例控制整个队列的一个部分并与之协作。此类拓朴确实可以确保可伸缩性和一定程度的可用性。但是，由于不存在用于队列中所有消息的单个存储库，因此此配置可能会发生与工作负载平衡、消息处理顺序和孤立消息相关的潜在问题。对于那些被证实不能以其他方式达到可接受吞吐量的情形，应限制此选项（图 3）。

图 3. 具有分区队列的活动/活动集群拓朴

您已经了解到集群消息传递引擎的两个基本选项，现在我们讨论对于 WebSphere Process Server 应用程序，消息传递引擎可以位于何处。有以下两个选项：

消息传递引擎与 WebSphere Process Server 应用程序共存。换句话说，消息传递引擎与 WebSphere Process Server 应用程序在同一集群中运行。

消息传递引擎位于自己的集群中，与 WebSphere Process Server 应用程序分离。

这两个选项有四种可能的组合：

消息传递引擎与 WebSphere Process Server 应用程序共存。此选项将意味着对解决方案的整体可伸缩性有严重的限制。不过，这些拓朴比较简单，易于设置和管理。通常，应避免以下特定拓朴：

无分区队列、活动/备用拓朴。此拓朴的设置比较简单，仅需要少数服务器和单个集群。但是，它有一个很大的弊端。一次只能有一个消息驱动的 Bean (MDB) 处于活动状态和使用消息。这大大限制了此配置的可伸缩性因素。

图 4. 最简单的集群拓朴：活动/备用

分区队列、活动/活动拓朴。与前一拓朴相比，此拓朴的优点是提供了一个可伸缩的环境，其中多个 MDB 同时处于活动状态（尽管它们在同一队列的不同分区上）。不过，为确保故障转移，您需要为每个消息传递引擎配置单独的集群。由于存在分区，因此可能会发生与工作负载平衡、消息处理顺序和孤立消息相关的潜在问题。

图 5. 具有分区队列的活动/活动拓朴

消息传递引擎与 WebSphere Process Server 应用程序分别位于不同的集群。只要实际上可行，请采取此技术。

无分区队列、活动/备用拓朴。此拓朴可让您真正实现 WebSphere Process Server 应用程序的可伸缩性，因为它可以同时让多个 MDB 处于活动状态。

图 6. 将消息传递引擎隔离在单独的集群中

另外，由于队列是不分区的，因此不存在工作负荷平衡和孤立消息方面的特殊考虑。它还可以让您单独优化和配置消息传递引擎集群的 WebSphere Process Server 集群。仅需要注意的一点是消息传递引擎的可伸缩性，只有将其置于功能较为强大的系统上才能实现其可伸缩性。

分区队列、活动/活动拓朴。此拓朴可以实现完全的可扩展性，并允许单独管理 WebSphere Process Server 集群和消息传递引擎集群。但是，由于目的地是分区的，因此可能会发生与工作负载平衡、消息处理顺序和孤立消息相关的潜在问题。设置此类拓朴的任务也非常复杂。

图 7. 实现消息传递的最大可伸缩性的分区队列

图片看不清楚？请点击这里查看原图（大图）。

尽管该解决方案在可伸缩性和故障转移方面最具灵活性，但仅应在证明消息传递引擎是吞吐量的主要限制因素，并在完全了解对应用程序的限制时，才采取此解决方案。

集群关系数据库

我们在上文已简要提到，可以通过许多已知和经证实的技术来实现关系数据库平台的高可用性和伸缩性。但是，该主题已超出本文讨论的范围。

目标拓朴

对于本文的示例场景，我们采取了具有两个单独集群的拓朴，一个集群用于 WebSphere Process Server 应用程序，另一个用于消息传递引擎。对于消息传递引擎，我们选择了活动/备用 (1/N) 缺省策略（无分区目的地）。图 8 中的示意图说明了目标拓朴的概况。

图 8. 本文描述的拓朴

在 ISSW 框中，我们安装了部署管理器和 WebSphere Process Server 集群。

在 ISSW2 框中，我们安装了消息传递引擎集群。

在第三个框 DBSrv 中，我们具有拓朴所需的 IBM DB2® 和数据库。

为简明起见，我们选择说明了如何设置此拓朴。需要注意的重要一点是，ISSW 或 ISSW2 系统任何一个发生故障都会导致停机。对下面的说明稍加更改，就可以设置一个更具可用性的类似拓朴，如图 9 所示。

图 9. 示例拓朴的变体

此拓朴使用相同的硬件，但它消除了创建位于单个物理框中的集群时所导致的单点故障。

安装 WebSphere Process Server

对于本项目，我们在 ISSW 和 ISSW2 系统上同时安装了 WebSphere Process Server V6.0.1.0。版本 6.0.1 是整个 WebSphere Process Server 产品的全新版本，并将其包装为完全可安装的映像。WebSphere Process Server V6.0.1 的安装过程中还将安装必备的 WebSphere Application Server Network Deployment V6.0.2.3。我们选择了自定义安装 (Custom Install) 路径，并选择了不安装示例（图 10）。

图 10. 安装 WebSphere Process Server

图片看不清楚？请点击这里查看原图（大图）。

在安装完成后，我们选择了不运行概要创建向导，该向导在后续步骤中手动运行。

当然，这不是完成目标结构的唯一方法。事实上，在 ISSW2 上并不需要 WebSphere Process Server 代码，因为该系统的唯一用途是运行消息传递基础结构。您可以安装 WebSphere Application Server Network Deployment V6.0.2.3 进行消息传递，然后联合指向 WebSphere Process Server 单元的任何此类节点。还可以在需要的节点上向 WebSphere Process Server 增加 WebSphere Application Server 的现有安装。

为 WebSphere Process Server 创建数据库

对于 WebSphere Process Server，需要使用许多数据库表。您可以自由创建一个或多个数据库来承载包含这些表的多种模式。但需要掌握创建许多单独的数据库和在单个数据库中创建所有模式和表之间的合理平衡。建议不要使用后一种方式，因为您无法单独优化各个数据库。不过，在大型安装中，可能有多个独立环境（具有多个业务进程容器等）。如果选择为每个需要的组件创建单独的数据库，那么结果可能会产生数量极大的数据库。

建议的做法是为消息传递引擎创建一个数据库，为其他 WebSphere Process Server 组件（WebSphere Process Server 表和 BPEL 等）创建另一个数据库。然后，可以在这些数据库中创建不同的模式。

通常情况下，您需要在安装和配置 WebSphere Process Server 之前手动创建数据库。

对于数据库中的对象（如模式和表），共有两个选项：

让 WebSphere Process Server 管理功能为您自动创建对象。这意味着您的数据库管理员同意负责配置 WebSphere Process Server 的人员创建数据库对象。在实际的生产环境中，很少出现这种情况。

让数据库管理员为您创建数据库、模式、表和其他对象。您需要为其提供脚本。

我们将采取混合方法。手动创建一些模式，并通过系统创建其他模式。不过，如果完全采用手动方法，则需要指明如何获取执行创建任务的脚本。

WebSphere Process Server 需要下面的模式：

对于 WPS 存储库。此数据库的缺省名称为 WPRCSDB。这里，我们新建一个空的 DB2 数据库 (ISSWWPS)，然后让概要向导在其中为我们创建模式和表。在创建部署管理器概要时可以创建表（将在下文阐述）。

作为一种备选方法，您可以使用处于以下位置的 SQL 脚本：\WebSphere\ProcServer\profileTemplates\dmgr.wbiserver\actions\scripts。

对于业务流程容器和人工任务容器。您必须手动创建此模式。脚本位于 \WebSphere\ProcServer\ProcessChoreographer 目录下。

本示例创建一个名为 ISSWBPE 的新数据库，并使用脚本 createDatabseDb2.ddl 创建表。我们编辑了该文件，并更改了前两个 SQL 语句，以指明期望的数据库名称：

--　create　the　database　
CREATE　DATABASE　ISSWBPE　USING　CODESET　UTF-8　TERRITORY　en-us;　
--　Use　CONNECT　TO　BPEDB　USER　xxx　when　another　user　should　become　owner　of　the　schema　
CONNECT　TO　ISSWBPE;　
　
type=websphere.taskmanagement.taskstatechange　...userData={task.id=n,　task.state=1　
|--10--------20--------30--------40--------50--------60--------70--------80--------9|　
|--------　XML　error:　The　previous　line　is　longer　than　the　max　of　90　characters　---------|　

对于每个消息传递引擎。这些模式可以在配置消息传递引擎时自动创建。不过，您还可以手动创建它们。在手动创建时，需要使用 WebSphere/ProcServer/bin 目录下的 sibDDLGenerator 命令生成脚本。 例如，要在数据库 ISSWMEDB（用户 MICHELE 对该数据库具有全部权限）中生成将要创建名为 ISSWME 的模式的脚本，可以使用下面的命令：

sibDDLGenerator.bat　-system　db2　-schema　ISSWME　–user　MICHELE　-create　–statementend　;　>　ME.ddl　
|--10--------20--------30--------40--------50--------60--------70--------80--------9|　
|--------　XML　error:　The　previous　line　is　longer　than　the　max　of　90　characters　---------|　

这时将创建一个数据库和四个模式（每个消息传递引擎一个）。我们编辑了在上一步骤中得到的 ME.ddl 文件，并更改了模式名称，以便匹配所需的值。

WebSphere Process Server 可能需要 Common Event Infrastructure (CEI) 数据库。不过，在创建概要之前，此数据库的脚本不可用。您可以在下文配置 CEI 部分中创建此数据库。

表 1 列出了在创建概要之前创建的数据库和模式。

表 1. 数据库、模式及其功能

数据库	模式	功能
ISSWWPS	此时没有任何内容，概要创建向导将创建模式和表。	这是 WPS 存储库。
ISSWBPE	与连接数据库所使用的用户 ID 相同。	保存流程编排和人工任务管理器信息。
ISSWMEDB	每个消息传递引擎一个： 用于编排的 MEBPE 用于 Common Event Infrastructure 的 MECEI 用于 SCA 应用程序消息传递引擎的 MESCAAPP 用于 SCA 系统消息传递引擎的 MESCASYS	保存消息传递引擎的永久性信息。

创建部署管理器概要

创建 WebSphere Process Server 部署管理器概要：

从以下目录启动概要创建向导：C:\WebSphere\ProcServer\bin\ProfileCreator_wbi。确保选择了此目录，而不是 ProfileCreator 目录，否则将创建错误的部署管理器。

在概要类型选项中选择 Deployment manager profile（图 11），然后单击 Next。

图 11. 创建部署管理器概要

图片看不清楚？请点击这里查看原图（大图）。

命名您的概要（例如，ISSWDmgr），然后单击 Next。（图 12）

图 12. 命名部署管理器概要

图片看不清楚？请点击这里查看原图（大图）。

选择缺省概要目录（图 13）。单击 Next。

图 13. 指定部署管理器目录

图片看不清楚？请点击这里查看原图（大图）。

指定主机、节点和单元名称（我们保留了缺省值），然后单击 Next。（图 14）

图 14. 指定节点、主机和单元名称

图片看不清楚？请点击这里查看原图（大图）。

后续步骤非常重要。将询问您 Service Component Architecture (SCA) 基础结构连接系统和应用程序 SI 总线（图 15）所使用的用户 ID 和密码。在对话框中指定的用户 ID 和密码必须是有效的 WebSphere Application Server 用户 ID 和密码。这些凭据通常完全独立于连接各种数据库所需指定的凭据。就本文而言，我们假定对于 SI 总线和关系数据库使用了相同的凭据。

图 15. 为 SCA SI 总线指定安全凭据

单击 Next。现在，将询问您是需要创建新数据库，还是使用现有数据库。由于我们已经创建了一个空数据库，因此选择 Use an existing database。还需要注意的重要一点是，只有在数据库为本地数据库时才允许自动创建数据库。该向导的智能设计足以识别数据库为空数据库的情况，并在需要时创建模式。如果数据库已经包含模式，则该向导将跳过创建步骤（图 16）。

图 16. 为 WebSphere Process Server 选择数据库

图片看不清楚？请点击这里查看原图（大图）。

单击 Next。查看摘要，然后单击 Finish。

图 17. 查看部署管理器创建选项

图片看不清楚？请点击这里查看原图（大图）。

在创建概要之后，您需要检查是否还创建了模式和表。我们的检查方法是，通过连接到数据库服务器，并验证 ISSWWPS 数据库中是否存在以下各表（图 18）：

图 18. 为部署管理器创建的表

通过发出以下命令也可以做到这一点：

db2cmd　
db2　connect　to　ISSWWPS　user　<...>　using　<...>　
db2　list　tables　for　schema　<user　name>

还可以使用脚本来填充数据库。这些脚本位于以下目录中：<安装根目录>/profileTemplates/dmgr.wbiserver/actions/scripts。

验证您已经为 SCA 创建了两个 SI 总线。启动部署管理器，打开控制台，并选择 Service Integration => Buses。您将看到两个 SI 总线（SCA.APPLICATION.<单元名称>.Bus 和 SCA.SYSTEM.<单元名称>.Bus）。

图 19. 为 SCA 创建的 SI 总线

图片看不清楚？请点击这里查看原图（大图）。

验证 J2C 身份验证别名是否存在。以下用于数据源和连接工厂：

选择 Global security => J2C authentication data entries。

您应该具有 SCA_Auth_Alias（在连接消息传递引擎时使用）和 WPSDBAlias（用于 WebSphere Process Server 数据库）。

图 20. 为部署管理器概要创建的身份验证别名

图片看不清楚？请点击这里查看原图（大图）。

创建 WebSphere Process Server 自定义概要

既然您已经有了部署管理器概要，就可以为节点创建概要了。我们从 WebSphere Process Server 节点开始。在我们的示例中，WebSphere Process Server 节点与部署管理器共存。在您的拓朴中，单独的计算机上可以有多个节点。在我们的场景中，WebSphere Process Server 只有一个节点，还有一个节点用于消息传递引擎，但在概念上，这些步骤也适用于较大的配置。

从以下目录启动 WebSphere Process Server 概要创建向导：C:\WebSphere\ProcServer\bin\ProfileCreator_wbi。

选择 Custom profile，然后单击 Next。

图 21. 创建自定义 WebSphere Process Server 概要

图片看不清楚？请点击这里查看原图（大图）。

选择 Federate this node later，然后单击 Next（图 22）。

图 22. 自定义 WebSphere Process Server 概要的选项

图片看不清楚？请点击这里查看原图（大图）。

要立即联合节点，部署管理器进程必须启动并且正在运行。

命名此概要，并将其设置为缺省值（图 23）。单击 Next。

图 23. 命名自定义 WebSphere Process Server 概要

图片看不清楚？请点击这里查看原图（大图）。

选择安装目录，然后单击 Next。

选择一个节点名，并输入系统名（通常使用缺省名较好），然后单击 Next。

选择数据库类型和驱动程序位置。对于 DB2，驱动程序随产品一起提供，通常不需要更改。

图 24. 为自定义 WebSphere Process Server 概要选择数据库选项

图片看不清楚？请点击这里查看原图（大图）。

查看摘要，然后单击 Finish 完成概要的创建。

不执行其他操作退出向导。

创建 WebSphere Application Server 自定义概要

在我们拓朴中，存在单个用于消息传递的 WebSphere Application Server 节点（系统 ISSW2）。在该节点上，我们需要创建基本 WebSphere Application Server 概要。在创建 WebSphere Process Server 概要时，仅运行消息传递基础结构没有什么作用。

从以下目录启动 WebSphere Application Server 概要创建向导：C:\WebSphere\ProcServer\bin\ProfileCreator。请注意，该向导与我们创建 WebSphere Process Server 概要所使用的向导不同。

选择 Custom Profile。将该屏幕与 WebSphere Process Server 的屏幕相比较，可以看出概要类型的显示顺序不同。单击 Next。

图 25. 创建普通 WebSphere Application Server 概要

图片看不清楚？请点击这里查看原图（大图）。

选择选项 Federate this node later（要立即联合概要，需要使部署管理器处于运行状态），然后单击 Next。（图 26）

图 26. WebSphere Application Server 概要的选项

图片看不清楚？请点击这里查看原图（大图）。

为您的概要提供一个名称。单击 Next。

验证（或更改）主机名和节点名。单击 Next。

检查摘要，然后单击 Finish 完成创建。

不执行其他操作退出向导。

向部署管理器添加节点

现在，您可以使用 addNode 命令将节点与单元联合在一起。

启动部署管理器。在创建部署管理器概要的系统 (ISSW) 上，从 \WebSphere\ProcServer\profles\ISSWDmgr\bin 运行 startManager 命令。

在部署管理器启动并运行之后，在同一 DM 系统 (ISSW) 上，向单元添加 WebSphere Process Server 节点：

将目录更改为：\WebSphere\ProcServer\profiles\ISSW01\bin。

运行 addNode issw.rchland.ibm.com。

等待运行完成。此时还将启动节点代理。

在需要添加多个节点时，请确保一次添加一个节点。等待每个 addNode 命令完成，然后再发出后续 addNode 命令。

切换至创建 WebSphere Application Server 概要的系统 (ISSW2) 并联合该节点：

将目录更改为 \WebSphere\ProcServer\profiles\ISSWWAS\bin。

运行 addNode issw.rchland.ibm.com。

等待运行完成。此时还将启动节点代理。

启动管理控制台，并验证两个节点已经联合。选择 System administration => Nodes。您应该看到这两个节点。

为消息传递引擎创建集群

为消息传递引擎创建 WebSphere Application Server 集群。此集群不需要 WebSphere Process Server 功能，因为它只运行消息传递基础结构。

选择 Servers => Clusters => New。命名您的集群 MECluster。（图 27）。

图 27. 为消息传递配置集群

图片看不清楚？请点击这里查看原图（大图）。

单击 Next。创建初始集群成员。将其命名为 MEMbr01，并选择要让成员驻留的节点。将服务器模板保留为 default。通过使用缺省模板，可以创建一个“普通”的 WebSphere Application Server 服务器，而不是支持 WebSphere Process Server 的服务器（图 28）。

图 28. 选择正确的服务器模板

图片看不清楚？请点击这里查看原图（大图）。

提示：可以现在或者在以后创建更多成员，但在开始时请只创建一个成员，然后根据需要通过添加成员来增长集群。

单击 Next。查看摘要并完成创建过程。

为消息传递引擎创建提供程序和数据源：

在集群级别创建 JDBC 提供程序。导航到 Resources => JDBC Providers，然后选择一个集群范围（图 29）。

图 29. 在集群级别为消息传递创建数据源

图片看不清楚？请点击这里查看原图（大图）。

单击 New 创建一个新提供程序。选择数据库类型、提供程序类型和实现（图 30）。

图 30. 为消息传递配置数据源

完成概要的创建。

对于 DB2，更新 DB2 驱动程序环境变量。一般情况下，最好在节点级别创建这些变量，因为这样可以独立自定义每个节点。在我们的场景中，所使用的系统对于磁盘驱动器、目录结构、数据库驱动程序位置等都是相同的。因此，我们可以在单元级别定义这些变量，这样，单元中的每个框都将继承这些定义（图 31）。

图 31. 为数据源定义 WebSphere 变量

图片看不清楚？请点击这里查看原图（大图）。

如果您在单元级别定义变量，则请确保不在节点和服务器级别定义同一变量。较低级别的定义会覆盖单元级别的定义。

创建实际的数据源。由于我们决定为所有消息传递引擎创建单一数据库，并在此数据库中创建多个模式，所以一个数据源就足够了。

选择 Resources => JDBC Providers，然后单击 JDBC 提供程序（我们在集群级别创建的提供程序）。

单击 Data Sources，然后单击 New。

为数据源指定一个名称（如 MEDataSource）和一个 JNDI 名称（如 jdbc/MEDataSource）。

指定组件管理身份验证别名（在这里，我们对所有的数据库使用单一别名，假定所有数据库共享相同的身份验证信息）。对于 DB2，还要指定数据库名称和端口号。在本例中，将驱动器类型设置为 4，应将它设置为与提供程序中使用的驱动器一致（图 32）。

图 32. 为消息传递数据源配置安全和数据库设置

图片看不清楚？请点击这里查看原图（大图）。

单击 OK 并保存。

将集群添加到 SCA 使用的 SI 总线：

导航到 Service Integration => Buses。

选择 SCA.SYSTEM.<单元名称>.Bus，然后选择 Bus members。

图 33. 向 SCA SYSTEM SI 总线添加成员

图片看不清楚？请点击这里查看原图（大图）。

单击 Add。指定 MECluster 作为您创建的数据源的成员和 JNDI 名称（图 34）。

图 34. 选择 MECluster 作为 SI 总线成员

单击 Next，并确认将集群添加到总线。

以上步骤在集群上创建了一个消息传递引擎。现在，对它进行更改，以便指向数据库中正确的数据库模式：

选择 Service Integration => Buses，然后单击 SCA.SYSTEM.<单元名称>.Bus。

选择 Messaging Engines，并在出现的屏幕上选择消息传递引擎，然后单击 Data Store。

将该模式更改为正确的模式（在本例中，它是 MESCASYS，因为该模式是您为 SCA 系统总线创建的模式）。取消选中 Create tables，因为您已经创建了模式和表——但是会自动创建（如果适用）。单击 OK并保存。（图 35）

图 35. 为消息传递设置正确的数据库模式名称

图片看不清楚？请点击这里查看原图（大图）。

对 SCA.APPLICATION.<单元名称>.Bus 重复上述步骤，并确保为数据存储定义指定一个不同的模式名称（如 MESCAAPP）。

启动集群，确保消息传递引擎能够工作（它们应处于“启动”状态，还应检查集群中服务器的 SystemOut.log）。

如果需要重新创建总线，请确保取消并重新创建模式，否则在启动消息传递引擎时会遇到困难，原因是数据库模式本身存在现有数据。

创建 WebSphere Process Server 集群

消息传递的基础结构准备就绪后，我们就能够创建可以安装 WebSphere Process Server 应用程序的 WebSphere Process Server 集群。

创建集群：

选择 Servers => Clusters，然后选择 New。对于步骤 1，为集群分配一个名称。

创建一个 defaultProcessServer 类型的成员（确保更改了缺省值，以避免创建不支持 WebSphere Process Server 应用程序的集群）。另外，还要确保选择一个安装了 WebSphere Process Server 的节点。在我们的场景中，仅在 isswNode01 上为 WebSphere Process Server 创建概要。

图 36. 为 WebSphere Process Server 应用程序创建集群

图片看不清楚？请点击这里查看原图（大图）。

查看摘要，并完成集群的创建。

为 SCA 支持配置集群。WebSphere Process Server 集群需要进一步配置为指向 SCA SI 总线、业务规则管理安装等。

导航到 Server => Clusters，并单击刚才创建的 WebSphere Process Server 集群。

选择 Advanced Configuration。

在下一个屏幕中，选中 Install Business Rules Manager。现在，保留 CEI 发射器工厂的 JNDI 名称为缺省值。

通过选择 Remote Destination Location 并指定消息传递引擎集群 (MECluster)，指定您要承载 SCA 应用程序。请参阅图 37，了解屏幕显示的情况。

图 37. WPS 集群配置的选项

图片看不清楚？请点击这里查看原图（大图）。

单击 OK并保存您的工作。该集群现在已配置为承载 SCA 应用程序。

每个启用 SCA 的服务器或集群在系统 SCA SI 总线上都需要一个用于失败事件的目的地。

导航到 Service Integration =>Buses。

选择 SCA.SYSTEM.<单元名称>.Bus。

选择 Destinations。确保存在一个名为 WBI.FailedEvent.<您的 WPS 集群名称>的目的地。如果看不到目的地，则需要创建一个，方法是选择 New，然后选择 Queue，然后创建一个名为 WBI.FailedEvent.<your cluster name> 的目的地。

图 38. 创建失败事件 SI 总线目的地

保存工作。

为流程容器和人工任务创建 JMS 资源

业务流程容器和人工任务容器需要一组队列连接工厂、队列和激活规范才能工作。这些资源需要存在于消息传递基础结构上。您可以将 WebSphere MQ 用作外部 JMS 提供程序，或者用作 WebSphere 缺省消息传递和 SI 总线支持。我们正在使用的是后者。

有两种可能的方法：

使用向导。您可以依赖于业流程容器和人工任务容器安装向导来创建 JMS 资源和物理目的地。如果选择此方法，您可以跳过此部分，并转到下一部分。

事先创建它们，然后在安装业务流程和人工任务容器时重新使用。这会让您完全控制您创建的资源名称，但是也强制您执行多个配置步骤。

出于演示目的，我们使用手动创建方法：

为业务流程和人工任务容器创建 SI 总线：

选择 Service Integration => Buses。

单击 New。

命名总线，并为安全连接指定身份验证别名。您可以使用用于 SCA 的同一别名。

图 39. 为流程编排创建 SI 总线

警告：如果选择的名称不是 BPC.<您的单元名称>.Bus，则可能会遇到问题。如果 BPC 和 HTM 安装向导没有找到该名称的总线，则它们会创建新的总线和资源。如果您需要其他名称，您仍可以遵循本文中的步骤进行创建，然后删除冗余定义。

将消息传递引擎集群添加到总线，并将数据库模式设置为正确值：

选择 Service integration => Buses。

打开刚才创建的总线，然后单击 Bus Members。单击 Add，然后将消息传递引擎集群添加到总线。此操作会创建另一个消息传递引擎。

在同一总线上，单击 Messaging Engines => MECluster.000-BPC.isswCell01.Bus => Data Store。

将模式设置为 MEBPE，并取消选中 Create Tables。

单击 OK 并保存更改。

图 40. 为流程编排 SI 总线定义数据存储

图片看不清楚？请点击这里查看原图（大图）。

重新启动消息传递引擎集群，并确保启动了新的消息传递引擎。

为 BPC 和 HTM 创建物理队列。在刚才创建的总线上需要六个队列目的地：

导航到 Service integration => Buses，单击 BPC 和 HTM 的总线。

单击 Destinations。

单击 New。在后续屏幕上选择 Queue。

单击 Next。为标识符指定 BPEApiQueue_WPSCluster。最好通过引用将要使用这些目的地的服务器或集群对物理资源进行命名。在不同的集群或服务器上配置多个独立业务流程容器时，此技巧可以避免名称冲突。如果允许向导为您创建资源，则会自动采用此命名约定。

单击 Next。选择消息传递引擎成员 MECluster。

单击 Next 并确认创建。

为以下队列重复该步骤：

BPEIntQueue_WPSCluster

BPERetQueue_WPSCluster

BPEHldQueue_WPSCluster

HMTIntQueue_WPSCluster

HTMHldQueue_WPSCluster。

完成时，您应在 BPC.<您的单元名称>.Bus 上看到以下目的地（图 41）。

图 41： 在编排 SI 总线上创建的目的地

保存所有更改。

为业务流程容器和人工任务容器创建 JMS 资源。拥有目的地和总线后，您可以创建连接工厂、JMS 队列和激活规范。

转到 Resources => Default messaging，并设置集群级别的范围。选择 WPSCluster（而不是 MECluster）作为范围。

图 42. 为 JMS 目的地选择 WPSCluster

图片看不清楚？请点击这里查看原图（大图）。

首先创建连接工厂。选择 JMS Queue Connection Factories，并单击 New。

将名称设置为 BPECF，将 JNDI 名称设置为 jms/BPECF。

将总线名称设置为 BPC.<your cell name>.Bus（或者您为 BPC 和 HTM 创建的任何总线名称）。

图 43. 为流程编排创建 JMS 连接工厂

将组件管理的身份验证别名设置为我们用于验证数据库的 J2C 身份验证别名 WPSDBAlias。

图 44. 为 JMS 连接工厂设置身份验证参数

单击 OK。

对 BPECFC (jndi: jms/BPECFC) 和 HTMCF (jndi: jms/HTMCF) 重复这些步骤。

您现在应该有三个队列连接工厂（图 45）。

图 45. 您创建的三个 JMS 连接工厂

保存工作。

创建 JMS 队列。再次选择 Resources => Default Messaging，并且确保范围仍为 WPSCluster 级别。我们从业务流程容器队列开始。

选择目的地下的 JMS queue。

单击 New。为该名称指定 BPEApiQueue，为 JNDI 名称指定 jms/BPEApiQueue。

选择我们从下拉列表创建的总线，然后选择对应的目的地 BPEApiQueue_WPSCluster。

图 46. 为流程编排创建 JMS 队列

单击 OK。

为其余队列重复上述步骤，并从总线选择匹配的物理目的地。当完成时，会配置好图 47 所示的队列。

图 47. 流程编排和人工任务所需的所有队列

保存配置。

创建激活规范。流管理器需要两个激活规范，人工任务需要一个激活规范。再次导航到 Resources => JMS Providers => Default Messaging，并确保将范围设置为 WPSCluster 级别。

单击 JMS Activation Specification。

单击 New，并为名称指定 BPEApiActivationSpec，为 JNDI 名称指定 eis/BPEApiActivationSpec。

将目的地类型设置为 Queue，将目的地 JNDI 名称设置为 jms/BPEApiQueue。选择您希望创建激活规范的总线（必须为 BPC.<您的单元名称>.Bus。）为您的消息传递引擎选择身份验证别名。

图 48. 为流程编排创建激活规范

单击 OK。

使用类似步骤再创建两个激活规范：BPEInternalActicationSpec 和 HTMInternalActivationSpec。

保存配置。

业务流程容器设置

现在您已准备好使用向导设置业务流程容器。

运行业务流程容器安装向导：

选择 Servers => Clusters => WPSCluster => Business Process Container => Business Process Container Installation Wizard。

在首页选择数据库类型。确保为驱动器选择了 Type 4，并确保将数据库名称更改为实际的数据库名称（在我们的示例中是 ISSWBPE）。单击 Next。

图 50. BPC 容器的数据库设置

图片看不清楚？请点击这里查看原图（大图）。

将 JMS 提供程序保留为缺省消息传递提供程序，并指定访问它的用户 ID 和密码。还要为 JMS API 指定有效的 WebSphere 用户 ID 和密码。为 Administrator 角色和 System Monitor 角色 (BPCsetup02) 指定一个有效的 WebSphere 组或用户。请注意，如果您使用 SI 总线，则与队列管理器名称无关。

图 51. BPC 容器的 JMS 设置

单击 Next。在后续屏幕上，选中 Select Existing JMS Resources。确保正确地选择了资源。还要选中与安装 BPC Web 客户端相关的复选框，且暂时不选中 CEI 的复选框。

图 52. 为流程编排选择 JMS 资源

图片看不清楚？请点击这里查看原图（大图）。

单击 Next，查看摘要，并单击 Finish。确保安装过程成功完成（图 53），并保存更改。

图 53. BPC 容器安装成功完成

图片看不清楚？请点击这里查看原图（大图）。

对自动为业务流程容器消息传递引擎创建的数据源进行少量配置更改。该向导假设用于流程容器的消息传递引擎使用与业务流程容器本身相同的数据库。由于这不是我们场景中的情况（我们有一个用于所有消息传递引擎的独立数据库），我们需要更新对数据库的引用：

在控制台中，导航到 Resources => JDBC Providers，然后将范围设置为单元级别。

单击 WPSDefaultDatasource_DB2_Universal，然后单击 Data sources。

单击 BPC.T40MC2Cell02.Bus_WPSCluster_datasource。向下滚动到定义数据库的部分，并将其设置为 ISSWMEDB（图 54）。

图 54. 为 Process Choreographer 消息传递配置正确的数据库

单击 OK 保存配置更改。

人工任务管理器设置

现在，安装人工任务管理器。过程与业务流程非常相似 容器：

通过选择 Servers => Clusters => WPSCluster => Human Task Container => Human Task Container => Human Task Container Installation Wizard 运行 HTM 安装向导。

对于步骤 1，请指定与用于业务流程容器 <HTMSetup01> 相同的 JMS 选项。

图 55. 用于人工任务的数据库配置

图片看不清楚？请点击这里查看原图（大图）。

对于步骤 2，请选择 Existing JMS Resources，并选择是否需要邮件会话。

对步骤 3，查看摘要，并单击 Finish。

确保 HTM 容器安装成功完成，并保存配置。

在集群上配置 CEI

现在，您可以在 WebSphere Process Server 集群上配置和安装 Common Event Infrastructure。在这个简单的拓扑中，我们可以在与其余 WebSphere Process Server 组件相同的集群上安装 CEI。在较大环境中，您可以在单独集群中配置 CEI。

通过生成并执行一些脚本来创建 Common Event Infrastructure 数据库：

打开命令提示符，并将当前目录更改为 <WPS_INSTALL_ROOT>\profiles\<WPS Profile directory>\event\dbconfig。

此处有许多脚本；由于您正在使用 DB2，因此请使用与 DB2 对应的脚本。制作 DB2ResponseFile.txt 文件的副本。使用文本编辑器打开该文件，并进行以下更改（您可以具有驱动器位置、类型和数据库实例端口的不同值，具体取决于 DB2 的配置方式）：

CLUSTER_NAME=WPSCluster　
SCOPE=cluster　
DB_NAME=EVENT　
DB_NODE_NAME=<your　remote　DB　node　name>　
JDBC_CLASSPATH="<WPS_INSTALL_ROOT>\universalDriver_wbi\lib"　
UNIVERSAL_JDBC_CLASSPATH="<WPS_INSTALL_ROOT>\\universalDriver_wbi\lib"　
JDBC_DRIVER_TYPE=4　
DB_HOST_NAME=<your　DB　host　name>　
DB_INSTANCE_PORT=50000　
EXECUTE_SCRIPTS=NO　

保存更改。

运行 config_event_database.bat DB2ResponseFile.txt

。

前面的命令将创建一组脚本，以便在下列目录中创建 CEI 数据库：< WPS_INSTALL_ROOT >\profiles\<WPS 概要目录>\event\dbscripts\db2。使该目录成为当前目录。

运行以下命令，以便在远程系统上创建 CEI 数据库：cr_event_db2.bat client <user> <password>。

成功地创建数据库后，将目录更改为 WPS_INSTALL_ROOT>\profiles\<WPS profile directory>\event\dsscripts\db2。找到脚本，在此处配置 CEI 所需的数据源。

运行以下命令，以便在集群上创建数据源（确保首先启动并运行了部署管理器）：cr_db2_jdbc_provider cluster WPSCluster。

当系统提示时，提供数据库用户 ID 和密码，并让脚本完成。

验证该命令是否创建了 JDBC 提供程序和数据源。

打开管理控制台。

导航到 Resources => JDBC Providers，并将范围设置为集群级别。您应看到名为“Event DB2 JDBC Provider”的 JDBC 提供程序。（图 56）

图 56. 为 CEI 定义的 JDBC 提供程序

图片看不清楚？请点击这里查看原图（大图）。

单击该提供程序，然后单击 Data Sources。您应看到两个数据源（图 57）。

图 57. 为 CEI 创建的数据源

图片看不清楚？请点击这里查看原图（大图）。

现在，您可以安装两个 CEI 应用程序：一个实现 CEI 引擎，另一个允许异步发布 CEI 事件。

首先安装 CEI 引擎。使 <WPS_INSTALL_ROOT>\profiles\<WPS Profile>\event\application 成为当前目录。

在一行上发布以下命令（此命令适用于 DB2 V8.2，并假设您的 WPS 集群名为 WPSCluster）：

..\..\bin\wsadmin　–p　profile　event-profile.jacl　-f　
event-application.jacl　-action　install　
-earfile　event-application.ear　
-backendid　DB2UDBNT_V82_1　-cluster　WPSCluster　

现在，让我们为异步发布安装 CEI 消息应用程序。在同一目录中，发布以下命令（在一行上）：

..\..\bin\wsadmin　-profile　event-profile.jacl　-f　
default-event-message.jacl　-action　install　
-earfile　event-message.ear　-cluster　WPSCluster　

这两个命令不仅可以安装应用程序，而且还可以为 CEI 创建一些资源定义。在集群环境中，您需要修改其中一些定义。

打开控制台，并选择 Service Integration => Buses。请注意，您创建了一个称为 CommonEventInfrastructure_Bus 的新总线。（图 58）

图 58. 为 CEI 创建的 SI 总线

图片看不清楚？请点击这里查看原图（大图）。

单击该总线。在后续屏幕上，单击 Bus Members。请注意，已将 WPSCluster 添加为总线成员。这不是我们需要的结果，因为我们已定义一个独立集群来承载消息传递引擎（图 59）。

图 59. CEI SI 总线的错误总线成员

选择总线成员，并单击 Remove。

随后，单击 Add，并将 MECluster 添加到总线。像以前我们对其他总线的操作一样，为数据源 JNDI 名称指定 jdbc/MEDataSource。（图 60）

图 60. 将正确的集群设置为 CEI SI 总线的成员

单击 Next，然后单击 Finish。

单击 CommonEventInfrastructure_Bus，并单击 Messaging Engines。

单击 MECluster.000-CommonEventInfrastructure_Bus，并单击 Data Store。

为模式指定 MECEI，为身份验证别名选择 WPSDBAlias，并取消选中 Create Tables（图 61）。

图 61. 为 CEI 消息传递引擎设置正确的数据库模式

单击 OK 并保存更改。

您现在需要在总线上为 CEI 创建两个物理目的地。

返回到 Service Integration => Buses and click the CommonEventInfrastructure_Bus。

单击 Destinations。

单击 New ，并选择 Queue。单击 Next。

为标识符键入 CommonEventInfrastructureQueueDestination。单击 Next。

确保将总线成员设置为 MECluster。

单击 Next，然后单击 Finish。

再次单击 New，这次选择 Topic space。

为标识符键入 CommonEventInfrastructure_AllEventsTopic。单击 Next。

单击 Next 和 Finish。

保存配置更改。

重新循环集群，使它们拾取新的更改。

停止 WPSCluster 和 MECluster。

启动 MECluster。

启动 WPSCluster。

确保通过检查两者的 SystemOut.log 文件干净启动应用服务器。

验证集群功能和增长的集群

我们建议您首先创建具有单个集群成员的集群。这样，在绑定集群时您能够更方便地测试配置。对配置满意后，便可以将新成员添加到集群。

要测试配置，您可能需要一个简单的测试应用程序，并且该程序包括一些 SCA 功能和员工的长期运行业务实践，以便您可以测试我们配置和安装的大多数组件。

在继续进行应用程序安装和测试之前，请按以下步骤操作：

验证没有重复的 SI 总线目的地和 JMS 资源。前文已经提到，如果您调用业务流程容器和 HTM SI 总线，而非业务流程 container.<单元名称>.Bus，则将获得一个新总线和一组冗余 JMS 资源。

选择 Service Integration => Buses。如果您注意到除了创建的总线外，还创建了 BPC.<单元名称>.Bus，则删除它。

选择 JMS Providers => Default messaging => JMS queue connection factory，并验证您仅有一组用于 BPC 和 HTM 的连接工厂（BPECF、BPECFC 和 HTMCF）。

选择 JMS 队列，并验证您仅有创建的队列。删除任何冗余队列定义。

导航到激活规范，并确保没有任何冗余定义。

验证为业务流程和人工任务容器创建的数据源。

选择 Resources => JDBC Providers。

将范围设置为单元级别。

验证存在 BPE 容器的数据源。请记下其 JNDI 名称（它应是 jdbc/BPEDB_<您的集群名称>；例如：jdbc/BPEDB_WPSCluster）。当在包含 BPEL 流程或人工任务的 WPSCluster 上安装应用程序时，您将使用此名称。

启动消息传递引擎集群，并随后启动 WebSphere Process Server 集群。通过检查每个成员的 SystemOut.log，验证每个集群是否正常启动。

验证 Business Process Explorer 应用程序是否正常工作。通过 http://<WPS 集群主机名称>:port number/bpc 可以访问该应用程序。例如，如果您在本地计算机上进行测试，并拥有 WebSphere Process Server 集群成员的缺省 HTTP 传输，则您可以尝试 http://localhost:9080/bpc。

如果传输不是缺省传输（例如，WebSphere Process Server 集群成员的 Web 容器在端口 9081 上工作），则需要将虚拟主机添加到该端口的单元：

打开控制台，并选择 Environment => Virtual Hosts。

单击 default_host，然后单击 Host Aliases。

单击 New。

为主机名指定 *，并为端口指定端口号（例如，9081）（图 62）。

图 62. 为 WebSphere Process Server 集群配置虚拟主机

单击 OK 并保存。

重新启动 WebSphere Process Server 集群，并重新测试业务流程浏览器。

安装并测试应用程序。验证 BPC 浏览器正常工作后，便可以安装和运行您准备的测试应用程序。您可以使用 BPC 浏览器启动这些应用程序中的任何业务流程。

要增长集群，请继续以下步骤：

使用控制台选择 Servers => Clusters，然后单击您要增长的集群的名称（例如 MECluster）。

单击 Cluster Members，然后单击 New。

指定成员名称，并选择承载新集群成员的节点。

如果要添加更多成员，则单击 Apply。最后，单击 Next。

查看摘要，并单击 Finish。

对 WebSphere Process Server 集群重复上述步骤。

添加与其他集群成员对应的虚拟主机（每个集群成员将在自已的端口上侦听 HTTP 和 HTTPs。您需要添加虚拟主机定义，以匹配这些端口。）

重新启动集群。

通过检查每个服务器的 ystemOut.log，确保每个集群成员正确启动。

在最后配置上测试应用程序。启动并运行最后的配置后，您可以执行一系列测试，以确保应用程序在每个集群成员上运行。第一个非常简单的测试是要确保业务流程容器浏览器在每个成员上运行。

随后，您可以运行长时间运行的 BPEL 流程，并验证它是否正确执行。如果该流程由大量的活动组成，您应验证这些活动是否可以在不同的集群成员上执行。测试故障转移也非常重要。您可以确保在从中启动长时间运行流程的服务器突然停止时，长时间运行的流程继续运行——并且可以验证短时间运行流程的故障转移行为。

更复杂的拓扑

本文介绍的拓扑是 WebSphere Process Server 集群拓扑的一个示例。不过，您需要记住，对于更大的环境会有许多变化形式。下面提供了两个其他拓扑主题，我们不再对它们进行详细讨论。

分区目的地

前面已讨论，对目的地分区的好处是，可以在同一时间为 SCA、BPC 和 CEI 活动提供消息传递引擎的多个实例。正如我们提到的，此选项是提高消息传递引擎可伸缩性的一个方法。

通常，最好避免使用此方法，因为它会带来很大的局限性。总的来说：

不能保证分区之间的真正平衡。因此，您最后得到的可能是使用率过低或过高的分区。

对于包括分区目的地的某些配置而言，搁置（或孤立）消息也是一个问题。在集群成员失败，消息传递引擎故障转移到另一个集群成员时，会出现这种问题。在某些情形中，不存在准备处理来自故障转移消息传递引擎的任何消息驱动的 Bean，并且不会处理受影响分区上的任何消息。

排序也是分区目的地的已知问题。不能保证按消息发送到目的地的顺序处理消息。对于某些应用程序，这可能是一个主要问题。

将“管理”应用程序与 SCA、BPEL 和 HTM 应用程序分开。

WebSphere Process Server 包括大量的辅助应用程序，可帮助对 WebSphere Process Server 应用程序进行管理和故障排除。这些应用程序为（管理控制台除外，它不是特定于 WebSphere Process Server 的）：

Failed Event Manager

Relationship Manager

Common Base Event Browser

Business Rules Manager

Business Process Observer

Business Process Choreographer Explorer。

此列表中的前三个应用程序由部署管理器托管。提高它们的可用性意味着提高部署管理器的可用性。这可以使用已知的方法实现，如在自已的系统上放置部署管理器和使用操作系统故障转移机制（例如，用于 AIX 的 HACMP）来保护系统。

可以在自已的集群上隔离 Business Rules Manager 和 Business Process Observer（如果需要），并解除与 WebSphere Process Server 应用程序的耦合。当然，此选择会使拓朴和管理更复杂，但是同时可以使整个解决方案具有更好的可伸缩性。

也可以考虑在独立集群上隔离 Common Event Infrastructure 服务器，并且使 WebSphere Process Server 应用程序将它们的事件异步发布到“远程”CEI，而不是在同一集群上托管 CEI。

结束语

WebSphere Process Server 为客户构建可伸缩和高可用的应用程序环境提供了坚实基础。客户和专业人员可以通过学习本文来开始设置基础集群 WebSphere Process Server 安装。

在本文中，您学习了如何设置相当简单而又非常可靠的集群拓朴。不过，您必须知道，可能有各种用于 WebSphere Process Server 的拓朴解决方案，以确保有不同级别的可伸缩性和可用性。