简介
随着组织开始了解如何最佳地利用流程来帮助运行和改善其业务，业务流程管 理应用程序不断变得越来越任务关键型。这意味着这些应用程序的可用性需求常 常会达到 24/7。BPM 还鼓励持续流程改进，这意味着对应用程序的更改会更快地 以各种不同的形式完成。需要采用一些机制和技术来最大程度地减少宕机时间， 从而实现连续可用性。这些技术需要尽可能自动化，以便提高一致性和速度，并 减少指纹检查或人为错误。
本文提供了在 WebSphere Process Server V7.0 中实现连续可用性的背景知 识、见解和一些实用技术。
首先让我们来回顾一下 WebSphere Process Server 的拓扑结构。本文将重点 详细介绍准备和设置本文所建议方法的应用阶段的特殊考虑因素。因为在 WebSphere Process Server 上运行的 IBM BPM 解决方案中涉及到许多不同类型 的工件，所以需要使用不同的技术来实现想要的结果。还需要在解决方案和应用 程序级别上执行一些限制和特殊设置。每个场景都提供了详细的解释，包括执行 这些场景所涉及的步骤。本文将对所执行的场景和应用的基本技术进行重点描述 ，并以此为基准探索与 store-and-forward 和替代的拓扑结构配置相关的 变化。本文还将枚举对所执行场景和一些影响的更多见解。最后，将会总结如何 对产品修复程序包应用某种类似方法。
在生产环境中尝试这里列出的任何过程之前，强烈建议您先全面测试它们。除 了拓扑结构之外，应用程序必须以有助于实现连续可用性的方式来创建。本文提 供了一些具体的信息，但假设应用程序会适当地处理界面变化、数据库中需要的 表和其他资源需求。换一种说法，要认识到一些应用程序更改可能破坏兼容性， 进而导致宕机。本文关注的重点是兼容的更改。例如，我们会执行添加操作，而 不是删除或更改操作。特定于应用程序的数据库不会发射更改。删除操作和更改 数据库等操作不属于本文的讨论范围。
Process Server 拓扑结构的背景
图 1 给出了一个典型的 WebSphere Process Server 配置的可能形式。为了 简单起见，本文通篇都会假设采用了一种与此类似的单细胞拓扑结构。我们不可 能介绍每一个配置场景，但我们希望提供一些可应用于绝大多数配置的通用实践 。
图 1. 一个包含 IBM HTTP Server 的由两节点和 4 个集群组成的拓扑结构
所有 WebSphere Process Server 拓扑结构都会利用 4 个关键功能：应用程 序部署目标、消息基础架构、支持基础架构和 Web 基础架构。集群 是一组执行 这 4 个功能中的一个或多个功能的服务器。可以让一个集群执行所有 4 个关键 功能。但是，如果将这些功能分散在多个集群上来提高恢复能力，则有机会获得 更高的连续可用性。
在图 1 中所示的拓扑结构中，4 个功能中的每一个功能都有一个专门的集群 。应用程序部署目标集群 (AppTarget) 由安装了您的应用程序的服务器组成。这 些应用程序可能包括业务流程、服务、人工任务和中介。远程消息集群 (Messaging) 为您应用程序的异步消息和内部 Process Server 组件的需求提供 支持。支持基础架构集群 (Support) 提供的功能为部署目标提供补充，作为一个 独立集群，它实现了隔离，并从部署目标解除了一些特定的工作负载。最后，Web 组件集群 (WebApp) 托管了基于 Web 的客户端应用程序，比如 Business Space 、Business Process Choreographer 工具和 REST API 服务。
此拓扑结构包含一个部署管理器和 2 个 Process Server 节点。部署管理器 的职责是管理该单元，提供一个界面来配置该单元中的各种组件。部署管理器还 负责安装和更新应用程序，因此它对我们实现连续可用性至关重要。
一个节点 托管着一个或多个应用服务器；在此拓扑结构中，每个节点托管了 每个集群的一个成员。每个节点由部署管理器通过节点代理 远程管理。部署管理 器与一个节点的节点代理进行通信，该节点代理进而与该节点的应用服务器进行 通信。
在 WebSphere Process Server 中，应用程序通过部署管理器使用 Integrated Solutions Console 或 wsadmin 命令行脚本工具来安装。在安装或 更新一个应用程序时，新应用程序的工件首先被存储在该单元主存储库 中。然后 部署管理器将新应用程序的工件传递到每个节点的节点代理。随后，每个节点代 理更新该节点的应用服务器上的应用程序。
IBM HTTP Server 通常用于处理 IBM BPM 环境中的 HTTP 流量。IBM HTTP Server 支持使用一个名为 plugin-cfg.xml 的文件配置路由到应用服务器的流量 。一个客户端连接到 HTTP 服务器，并依据每个应用服务器配置来处理的负载， 这个 HTTP 服务器将客户端的请求路由到该单元的应用服务器。在讨论更新异步 应用程序时，我们将更详细地介绍 IBM HTTP Server 配置。
在对 WebSphere Process Server 拓扑结构的基本概述中，我们大体介绍了理 解和成功使用后面介绍的过程所需的知识。
连续可用性场景中的拓扑结构角色
在 WebSphere Process Server 中实现连续可用性的关键是最大程度地减少应 用程序更新期间的宕机时间。我们的目标是在更新应用程序时，让客户端不会体 验到任何宕机时间，最好完全注意不到任何变化。对于某些类型的应用程序，这 很简单，无需特殊的准备。但对于大多数 Process Server 应用程序，一次零宕 机时间的更新需要精心规划，还需要采用一个涉及到在各个节点间路由传入应用 程序流量的特殊过程。稍后我们会详细介绍此过程，但我们首先会概述使此目标 变为可能的 Process Server 拓扑结构。
实现连续可用性的一个前提条件是我们实现所谓的 “高可用性” 。要实现连续可用性，建议采用某种与图 1 类似的拓扑结构：由一个 2 节点和 4 个集群组成的拓扑结构，每个节点上拥有每个集群的一个节点。在最低限度下 ，您必须有一个与消息集群分开的应用程序目标集群。这可以确保消息引擎可与 应用程序目标服务器独立地进行故障转移。还必须有至少两个独立的节点，用于 托管应用程序目标和消息集群的成员。这使您能够停止一个节点上的服务器并更 新一个应用程序，同时让另一个节点处理所有应用程序流量。这些建议不仅为实 现连续可用性提供了基础，还为高可用性奠定了牢固的基础。