利用 WebSphere Extended Deployment 实现应用程序的无缝在线更新

前言

WebSphere Extended Deployment 产品对 WebSphere Application Server 网络部署版（以下简称 WAS ND）和其他中间件平台进行了扩展。它主要着眼于对服务质量的保证、性能的提高以及弹性和可管理性等方面。WebSphere Extended Deployment V6.1（以下简称 WebSphere XD ）版本有 3 个产品包。2008 年 4 月，每个产品包被独立成一个产品： Operations Optimization 产品包的新名称为：WebSphere Virtual Enterprise（以下称为 WVE）；Data Grid 产品包的新名称为：WebSphere eXtreme Scale；Compute Grid 产品包的名称为：WebSphere Compute Grid。

WebSphere Virtual Enterprise 产品通过在应用程序级别实现虚拟化，能够让企业的应用更好地实现 Service Level Agreement（SLA）。SLA 是网络服务供应商跟客户之间的协议，客户通常用可度量、可证明的方式指定网络服务供应商提供的服务。WVE 的一个重要特性就是对应用程序的版本管理功能。WVE 使得企业可以在 WAS ND 的一个单元中管理同一应用程序的多个版本。您可以方便地通过管理控制台上的版本控制中心发布新版本，在发布期间不会中断用户的继续使用，即实现无缝在线更新；而且如果发现新发布的新版本存在错误，也能够方便地回退到之前的某个稳定版本。

在阅读本文之前，如果您了解 WebSphere Application Server Network Deployment V6.1 及 WebSphere Extended Deployment V6.1 概述 的功能，那么将会很有帮助。

WAS ND 中的应用程序更新功能

WAS ND 产品本身具有可以对应用程序进行更新的功能。下面我们为您介绍如何使用 WAS ND 中的应用程序更新功能。

在WAS ND V6.1 中，管理员可以对应用程序的整个程序包、单个模块、单个文件等进行更新。如果一个应用程序安装在集群上，当应用程序的文件或配置被更新后，点击管理控制台上的“激活更新”（Rollout Update）按钮，那些被更新的文件或配置将会被依次安装到集群中的各个成员服务器上。“激活更新”会在各个集群的成员服务器上依次完成下面的步骤：

1. 保存更新后的应用程序的配置。
2. 停止一个节点上的所有成员服务器。
3. 通过同步配置更新该节点上的应用程序。
4. 重启该节点上被停止的成员服务器。
5. 在集群所在的其他节点上重复步骤 2 到 4。

由于每个节点上的成员服务器有停止-启动的操作，因此，那些正在进行中的 HTTP 和JMS 事务有可能丢失。另外，Web Server Plug-in 只有在检测到一个成员服务器停止服务后（如响应超时）才会选择向集群中其他成员服务器发送请求。这时，必须通过额外的努力缩减对客户请求产生的影响。文章 WebSphere Application Server V6 的系统管理，第 5 部分 中讲到了如何使用一种通用的模式来尽量解决这个问题：

1. 创建冗余应用程序目标，以进行工作负载管理和保证持续可用性。
2. 从某些目标子集将请求路由到别处。
3. 当所有工作已从该目标子集转移后，更新部署在其上的应用程序。
4. 使已更新的目标子集重新联机。
5. 将工作路由回已更新的子集。
6. 对于剩余的应用程序目标重复以上步骤。

本节向您讲述了WAS ND 中的应用程序更新功能。接下来我们看 WebSphere XD 是怎样实现应用程序版本的无缝更新的。

WebSphere XD 版本管理的应用场景

WebSphere XD 中的版本控制中心具有如下的功能：

• 在线无缝版本更新
• 回退到旧版本
• 部分测试人员使用“验证”模式对即将上线的新版本在线进行最后的测试。

下面我们对这些功能进行一一介绍。

在线无缝版本更新

WebSphere XD 可以对应用程序进行在线的无缝版本更新，用一个新的版本取代当前的活动版本。新版本可以是对当前版本的简单修改，也可以包含比较复杂的修改，只要新版本是向后兼容的，那么更新时当前访问应用程序的客户将不会受到影响。

更新应用程序时有 3 个配置选项：

1.转出策略。

在进行版本转出时，将一个版本替换为另一个版本，WebSphere XD 在替换过程中不会中断当前正在运行的应用程序。这点是通过下列步骤实现的：先停止当前应用程序请求，然后将新请求重新传递给其他服务器或者对请求进行临时排队，直到新版本可以使用为止。

有两种转出策略可供选择：分组更新策略和原子更新策略。

• 分组更新策略。将目标集群上的成员分为多个组，然后一组一组地替换这些成员上的版本。分组更新是最典型的选项，对于大型集群很有用。当新版本在分组更新期间变为可用时，所有请求都将定向至该新版本。
• 原子更新策略。在集群的一半成员上，使用原子更新将一个版本一次性地替换为另一个版本。此更新策略将使用一致的应用程序版本来处理所有用户请求。由于使用一致的版本来处理所有用户请求，因此集群将以一半成员服务器的容量运行。如果集群很大，那么考虑使用分组更新将您的转出划分为较小的组。另外，原子方式还可以与单个服务器部署目标配合使用。在单个服务器部署目标中，对集群的另一半成员执行的操作将被忽略。

分组更新策略模式适合于集群，并对由分组大小给定的集群成员数目执行并发替换，使得同一组内的 server 上的应用同时被更新到新版本并被激活。原子更新策略同时适合于集群单个服务器，它保证在同一个时刻更新半数的 server，被更新的版本先处在未激活状态，并在随需应变路由器（ODR）的帮助下保证客户请求在更新应用版本的时候不丢失。

2.复位策略。

复位策略将管理如何从内存中卸装旧版本以及如何装入新版本。复位策略将与转出策略一起工作。在进行版本转出时，每个服务器上的新版本都将被启动，有两种启动策略：软复位或者硬复位。执行软复位时，停止旧版本的应用程序，并启动新版本的应用程序。在执行这些操作的期间，服务器保持运行。执行硬复位时，停止正在运行旧版本应用程序的服务器，然后使用新版本替代旧版本来重新启动该服务器。软复位通常适合于大多数应用程序。而对于依赖于由底层操作系统装入的工件（例如，本机库）的版本来说，则需要进行硬复位。

3.消耗时间间隔。

消耗时间间隔是一个时间量，由用户指定。当 WebSphere XD 准备更新一个服务器上的应用时，首先不再转发新请求过来，等待一定时间，然后再开始执行复位策略操作（新旧版本更替），这个等待的时间就是消耗时间间隔。在此时间间隔内，与服务器具有会话亲缘关系的请求仍会路由到该服务器，其他请求将不会被转发过来。此时间间隔内允许有一段时间，以便完成现有 HTTP 会话和进行任何自动驱动的应用程序清除工作。消耗时间间隔的存在避免了那些正在进行中的 HTTP 和 JMS 事务的丢失。

版本更新时的这 3 个配置选项保证了更新的渐进性及无间断性。

回退到旧版本

如果一个应用程序的版本（如：版本2）被更新后在运行中发现存在问题，那么管理员可以很容易地回退到以前的一个稳定运行的版本（如：版本1）。回退的步骤和更新的步骤是一样的，只是回退时是用旧版本取代新版本。

版本验证

使用应用程序版本验证功能可以在生产环境中安装和测试一个新版本，同时运行应用程序的当前版本。例如：一个应用程序的版本 1.0 已被安装，激活，并在一个动态集群上运行着。版本 2.0 是候选版本，等待验证，被安装到同一个部署目标-动态集群上，处于未激活状态。当验证版本 2.0 时，验证动作会复制当前集群，成为一个新的动态集群，并把版本 2.0 映射到这个新的动态集群上。复制出来的集群使用既存的集群成员作为新的服务器模板来复制出新的集群的成员服务器。

在开始验证前，必须为版本 2.0 定义唯一的路由规则。路由规则使得不同版本的应用同时存在成为可能，它规定客户的请求仍然被路由到原来的动态集群上，而那些用于验证版本 2.0 的 HTTP 请求将被路由到复制出来的动态集群上，不影响版本 1.0 的工作。

对应用程序进行在线无缝更新时需要注意 WVE 版本兼容的标准。如果不符合兼容标准，可能不会达到无缝更新。下面是版本兼容的标准：

• 应用程序接口或语义：如果对现有接口进行更改，其中包括修改或除去现有接口，那么将破坏应用程序的现有用户。类似，假如接口先前允许参数为 NULL，但所作更改要求该参数不为 NULL，那么对接口的语义行为进行更改时，也会破坏现有用户。如果所作更改会影响现有客户机，那么视这些更改不能向后兼容，因此，不能通过无缝升级予以解决。如果对现有客户机的影响不会造成任何问题，那么可以使用 WAS 转出更新。
• HTTP 会话状态：如果 HTTP 会话状态是持久或复制的，那么诸如对会话添加数据类型或更改存储在会话中的数据类型这样的应用程序更改也意味着所作更改不兼容。当前版本可能无法使用先前版本创建的会话状态。
• 数据库：诸如对表添加字段或更改数据类型这样的应用程序更改也意味着所作更改不兼容。

下面我们将通过实例场景来向您说明在线版本更新的具体过程。

版本更新实例

我们使用示例应用程序 xddemo.war 的两个版本来演示。xddemo.war 里面包含两个简单的 jsp：page1.jsp 和 page2.jsp。从 page1.jsp 提交一个表单给 page2.jsp，两个 page 里面都含有版本标志信息。代码如下：

清单 1. page1.jsp V1.0

This is version 1.0! Input User Name :

清单 2. page2.jsp V1.0

This is version 1.0! User Name is :

各 jsp 的版本 V2.0 与 V1.0 的差别仅在于第三行代码，V2.0 为 ：

This is version 2.0!

创建一个动态集群 DC1，其中包含两个服务器实例。将动态集群 DC1 置成手工模式，如图 1。启动所有 Server 实例（图 2）。

图 1：动态集群列表


图 2：Server 实例列表

首先安装第一个应用程序版本。在管理控制台上点击应用程序->企业应用程序->安装，选定应用程序，指定上下文根为 /xddemo。点击下一步。

在安装新的应用程序页面，注意填写应用程序版本，如下图：

图 3：选择安装选项

在步骤 2 将应用程序映射到动态集群 DC1。安装完成后，启动应用程序，通过 ODR 访问 /xddemo/page1.jsp，验证 page1.jsp， page2.jsp 都显示版本 1.0，如图 4、5 所示。

图 4：page1.jsp V1.0


图 5：page2.jsp V1.0

下面打开一个新的浏览器页面，访问 /xddemo/page1.jsp，输入 User Name: NewUser，如图 6。不要关闭此浏览器，记住此时页面显示版本 V1.0。

图 6：版本更新前的 page1.jsp

下面我们安装版本 2。版本 2 的安装与版本 1 的安装是一样的，指定相同的上下文根：/xddemo，映射到相同的动态集群 DC1，只是在上图 3 填写的版本号为 V2.0。安装完成后，在应用程序->版本控制中心点击xddemo_war 应用程序，可以看到版本V1.0 处于活动状态，而版本 V2.0 处于不活动状态。

图 7：管理版本-1

选中 V2.0 版本，点击“转出”按钮，进入如图 8 所示的版本转出配置界面。

图 8：版本转出配置

在本例中我们使用默认的配置选项，读者可以尝试使用其他选项。转出策略选择分组策略，组大小为 1，即每次更新一组 Server，也就是一个 Server。复位策略选择软复位，即在一个 Server 上更新了版本后，只重启应用程序，而不是重启 Server。因为程序非常简单，没有事务处理，这里消耗时间间隔选择 3 秒，即在 Server 上停止接受新请求但继续处理正在执行中的现有 HTTP 会话和一些清除工作的时间为 3 秒。

配置好转出策略后点击确定。应用程序开始更新。在此期间可打开新的浏览器页面访问page1.jsp/page2.jsp，应用程序仍能访问，在开始阶段可能显示版本 V1.0 的页面，在后来阶段会显示版本 V2.0 的页面。这是因为，首先更新的是第一组 Server，第二组 Server 仍运行版本 V1.0 应用程序；第一组 Server 更新成功后，开始运行版本 V2.0，第二组Server再开始更新。

更新成功后，打开一个新的浏览器，访问应用程序，/xddemo/page1.jsp 显示如图 9 所示的 V2.0 页面，点击 Next，显示如图 10 所示的 V2.0 页面。

图 9：page1.jsp V2.0


图 10：page2.jsp V2.0

下面回到版本更新前打开的如上图 6 所示的那个浏览器，page1.jsp 显示的是版本 V1.0 的页面，点击 Next，可以看到，page2.jsp 显示的已是版本 V2.0 的页面，如图 11 所示。

图 11：版本更新后的 page2.jsp

更新完成后在版本控制中心可以看到 V1.0 变成不活动状态，而 V2.0 变成活动状态，如图 12。

图 12：管理版本-2

这样就完成了一个简单的版本更新（V1.0 到 V2.0）的过程。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-586922/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14789789/viewspace-586922/