智能管理中包括了应用程序版本管、动态集群、健康管理和智能路由。本文主要向您介绍应用程序版本管理。
IBM 在 2012 年 6 月 15 日发布的 WebSphere Application Server （以下简称为 WAS）V8.5。WAS V8.5 中的一个重大变化，就是将之前独立的产品 WebSphere Virtual Enterprise （以下简称为 WVE）的功能完全并入到了 WAS 中。之前由 WVE 提供的相关功能，在 WAS V8.5 中，我们称之为智能管理。智能管理中包括了应用程序版本管理、动态集群、健康管理和智能路由。本文主要向您介绍应用程序版本管理这个功能。
应用程序版本管理的目标就是在不间断对外服务的情况下，部署和管理应用程序版本。
应用程序版本管理器
不间断的生产应用程序部署是由 应用程序版本管理器来控制的，它是应用程序版本管理中的核心组件。在此类环境中安装应用程序更新时，能够使应用程序不间断对外提供服务。
应用程序版本管理器提供了应用程序版本控制模型，访模型支持在智能管理单元中对同一应用程序进行多次布署。每次部署都使用唯一版本名。通过应用程序版本管理器，可以选择要在智能管理集群上进行激活的版本，这样，您可以执行转出应用程序更新或还原为先前的级别。
应用程序版本管理器与智能管理完全集成在一起，从而与随需应变路由器（ODR）、动态工作负载均衡和应用程序布置管理器进行交互。此集成确保在对应用程序进行更新时可预测应用程序的行为，并在系统继续管理应用程序性能目标的同时，确保从一个应用程序版本平滑地转移至另一个应用程序版本。可以使用管理控制台访问应用程序更新过程，其中包括在应用程序服务器之间进行的版本激活操作。对应用程序编程接口进行脚本编制使版本管理功能能够与自动执行的应用程序部署集成在一起。
Java EE 应用程序支持应用程序版本，包括 EAR 文件和符合批处理编程模型的批处理应用程序。
WAS 本身提供了一个称为转出更新的管理功能。转出更新提供了基本的应用程序升级，但是它间断的。应用程序版本管理器是升级应用程序的首选方式。应用程序版本管理器支持应用程序的整个生命周期，并支持对生产环境中运行的应用程序的更新和无缝的的不间断的应用程序部署。
运行环境
应用程序版本管理器运行的环境就是一个智能管理单元。如下图所示，应用程序版本管理器管理部署到动态集群中的应用程序，这些集群通过随需应变路由器（ODR）接受工作请求。
图 1. 带有 ODR 和动态集群的应用程序版本管理器示意图
智能管理也支持 SIP 协议
应用程序版本管理器提供不间断的应用程序更新，但仅限于通过 HTTP 和 HTTPS 经由 ODR 来访问应用程序。在应用程序升级期间，如果不是借助 HTTP 和 HTTPS 并通过另一个 ODR 层来实现应用程序间访问，那么不能确保访问的服务的连续性，例如，不能确保一个 Java EE 应用程序对另一个应用程序所进行的调用的服务连续性。
版本兼容性
该应用程序版本管理器仅支持版本转出兼容的应用程序升级，这表示无中断升级仅用于与以前版本兼容的版本。当您部署包含具有不兼容更改的版本时，您可能需要采用并行激活模式并使用路由规则来分离先前版本的用户与当前版本的用户之间的请求流量。借助并行激活，可以同时主管同一应用程序的多个版本，同时每个版本支持载然不同且不交叉的用户集。但是并行激活可能不提供不间断升级。
在部署应用程序版本的时候，要考虑如下的兼容性问题：
应用程序接口或语义：在尝试版本切换的时候，如果应用程序版本之间的接口或是语义发生的变化，那么正在使用应用程序的活动用户就会受到影响。更改的例子包括对现有接口的改变，其中包括修改或移除现有接口。另外，对接口语义的行为的变化也会影响到现有的活动用。例如，如果某一接口原来允许某一参数为 null，然后又修改为要求同一参数不能为 null。对于现在用户有有影响的变化被认为是不向后兼容的，也不能是做为不间断更新的一部分。如果对现有用户的影响不是问题的话，那么就可以考虑使用 WAS 的转出更新。 HTTP 会话状态：如果 HTTP 会话状态是可持久化或者可复制的，那么应用程序中添加或改变存储在会话中数据的类型也被视为是不兼容的变化。当前版本可能没办法使用之前版本创建的会话状态信息。 Web 内容高速缓存：如果新版本的应用程序包含了对于静态 Web 内容的缓存，而您正使用 ODR 缓存内容的，那么您可能需要在做版本转出的时候，手动的清除一下缓存。
Version 与 Edition
术语 Version 和 Edition 对开和构建环境与部署和操作环境进行了区分。Version 是连续分代的界面、功能、实现或整个应用程序等的集合。Version 是一个开发和构建的概念。Edition 是连续部署分代，例如，对一组受版本控制的特定工件进行的部署。Edition 是一个部署和运营的概念。
应用程序版本是指对特定应用程序的唯一部署。在 WAS 管理环境中，应用程序版本由应用程序名和版本名组合进行唯一标识的应用程序。虽然同一应用程序的多个版本具有相同的应用程序名，但是具有不同的版本名。版本名可以是数字，例如 1.0 或 2.0；名称也可是描述性的，例如 first edition 或 blue edition。
版本转出算法
许多业务应用程序都需要稳定的可用性。应用程序可用性的标准主张将应用程序部署在应用服务器集群上。集群的冗余对于能否提供持续可用性至关重要。不间断的应用程序更新指的是在维持应用程序可用性的同时进行更新的能力。换句话说，在进行应用程序更新期间，应用程序的用户不会遇到服务中断的情况。
对某个版本执行转出时，会将活动版本替换为新版本。要提供无中断应用程序更新，对版本执行转出操作包含以下项：
阻止服务器接收新的请求。 在特定的服务器上停止应用程序的请求。 停止当前活动版本。 启动新版本。 恢复发向新版本应用程序的请求流。
不间断更新有两种基本模式：组转出或原子转出。转出新版本时所执行的步根据选择的不同而有所不同。
注意：在转出期间会将动态集群的模式置为手动方式。如果在转出期间负载变重，那么智能管理也不会进行负载均衡之类的操作，所以要避免在业务高峰期，进行转出。当转出结束之后，动态集群又会回复到原来的模式。
分组转出
分组转出是将集群中的服务器分成若干个组，并定义组的大小，这是指定一次要处理的节点数量。对某个组执行转出，可以使该组中的服务器同时更新到新版本。在管理控制台中一次仅可在一个组上执行转出操作。当新版本中的任何成员变为可用时，所有的请求都将路由至该新版本。
在您对版本执行转出时，集群中的某些服务器会已经从旧版本切换到新版本，某些服务器正在进行切换，而其他服务器尚未开始切换。如果有任何服务器上的应用程序是最新版本，其实例处理活动状态并且正在运行，那么所有应用程序请求都将发送到该服务器。例如，当您执行版本 1.0 到 2.0 的转出操作时，一旦版本 2.0 在某个服务器中变为可用，那么所有应用程序请求都将由版本 2.0 进行处理。任何仍在运行版本 1.0 的服务器都不会对请求进行处理，直到此服务器更新为版本 2.0。以下是组转出示意图：
图 2. 组转出示例
执行组转出时，会在服务器组中跨集群转出。每个服务器都会执行以下步骤：
停顿向服务器发送请求。 停止应用程序或停止服务器。 更新服务器配置。 重新启动应用程序或服务器。 服务器就绪，可使用新版本应用程序。
原子转出
对某个版本执行原子转出就是一次替换半个集群上的版本，以使用一致的应用程序版本处理所有用户请求。所有用户请求都由旧版本或新版本进行处理，而不是由两个版本同时处理。
原子转出确保所有应用程序请求都由一致的版本进行处理，例如，由版本 1.0 或 2.0 进行处理，而不是由两者同时进行处理。当前版本可用的版本从组成集群一半的服务器上脱机。虽然新版本在那些服务器中激活并启动，但那些服务器保持脱机直到下一步完成为止。下一步是使剩下一半集群中的服务器上当前处于活动状态的版本脱机。此时任何务器上都没有旧版本或新版本的实例可用于处理应用程序请求。ODR 将临时对到达应用程序的任何请求进行排队。在后一半集群上的应用程序完脱机后，前一半集群将返回到联机状态。集群的后半部分将从先前版本切换到新版本，并返回联机状态。以下示例是原子转出示意图：
图 3. 原子转出示意图
在您执行原子转出前，需要确定目标服务器集群的负载能力。执行原子转出时实际上只有一半集群有服务请求。所以选择原子转出方式时，最好事先验证一半集群是否能在转出期间能否处理整个负载。
选择执行原子转出时，会执行下列步骤：
停顿向一半服务器发送请求。 停止前一半服务器中应用程序或服务器。 更新配置，激活新版本的应用程序。 启动前一半应用服务器中应用程序或服务器。 停顿向后一半服务器发送请求。 开始将请求路由到前一半服务器运的新版本。 在后一半服务器上，停止应用程序或服务器，更新配置，然后启动应用程序或服务器。 转出完成。
两种典型使用场景
接下来，我将通过示例给您讲解应用程序版本管理的两种典型使用场景：并行激活和版本验证
并行激活
并行激活是指同时激活并启用同一应用程序的多个版本。并行处于活动状态的版本可以向一组用户提供对一个版本的访问权，而向其他用户提供另一个版本的访问权。使用并行激活时，必须建立路由策略以便对具有某个版本的访问权的用户予以区别。路由策略作为应用程序配置元数据的一部分。另外，路由策略可防止产生歧义并确定哪个版本获取控制权。
使用场景举例：某电信运营商
用户需求：因地域不同，资费标准、套餐内容、优惠促销活动也不同，所以需要同一应用程序的在各地的版本略有不同，并要求这些版本同时运行，根据用户登录 IP 来将用户请求路由到相应版本的应用程序上去。
图 4. 并行激活场景示意图
操作过程：
首先必须至少将这个应用程序的不同版本安装到不同的目标集群上去。例如，my_application 应用程序 1.0 安装在 dynamic_cluster_1 动态集群上，而应用程序版本 2.0 安装在 dynamic_cluster_2 动态集群上，以此类推，关于如何安装应用程序参见参考资源。
激活应用程序版本。单击应用程序 > 版本控制中心 > application_name。选择不活动的版本，并单击 激活。 为了能够来自不同 IP 的请求路由到不同的应用程序版本上，我们需要事先设定路由策略，具体做法参见参考资源 验证 ODR 是否正常运行。单击 服务器 > 随需应变路由器。要路由请求，状态必须是 已启动。
这样我们就完成了并行激活， ODR 会根据事先设定好的路由策略将请求路由到不同的
验证版本
验证某个版本是确定新版本是否可用并准备移动到生产环境和替换当前版本的过程。它会在生产环境中克隆一套跟生产环境一模一样的环境，来用于新版本的测试。采用这种方式，使得您的生产应用程序可以继续维护请求同时，在真实的生产条件下安装和验证新版本。
使用场景举例：某全球购物网站
用户需求：购物网站竞争激烈，需要根据市场情况，随时推出并更新促销活动，要求新版本上线之前，能够在与生产环境相同的环境下进行测试，并要求在应用程序更新时，不间断对外面服务。
图 5. 验证版本场景示意图
操作步骤：
首先，确保将应用程序布署到相同的动态集群中。版本 1.0 处于活动状态并且在动态集群上运行。版本 2.0 是候选验证版本，已安装同一动态集群并处不活动状态。
单击 应用程序 > 版本控制中心以验证是否安装了应用程序的两个版本，而且只有其中一个版本处理活动状态。 在版本控制中心，选择版本 2.0 并单击 验证。“验证状态”页显示了如何在当动态集群 dynamic_cluster 上验证新版本和将版本 2.0 部署到克隆集群上的第个步骤。应用和序版本控制中心显示了其中一个版本处于验证方式，而“管理版本”页显示了版本 2.0 是部署在 dynamic_cluster-Validation 动态集群上的。“动态集群”页面显示创建了 dynamic_cluster-Validation 这样一个克隆的动态集群，而“服务器”页面显示了克隆的服务器。
提示：在执行转出后或者取消验证后，用于验证的克隆动态集群将会会删除。如果想保留该集群可以通过在验证集群上设定 saveClonedCluster 定制属性，来保留验证集群。
验证是否正确执行了验证。单击 应用程序 > 企业应用程序或应用程序 > 所有应用程序，选择版本 2.0 应用程序，在 管理模块中，验证版本 2.0 是否已经映射到验证集群。 测试新版本。启动验证集群，并设置好路由规则。
现在，您就可以在真实的生产环境中，测试新版本的应用程序了，在测试完成之后，可以进行转出操作，切换到新版本上。
小结
本文向您分绍了 WAS V8.5 中智能管理中的应用程序版本管理功能，它使得您能够在不间断对外服务的情况下，对应用程序版本进行部署和更新，并且介绍了两种不同的版本转出模式，和应用版本管理使用的两种典型场景。希望本文能够对您了解 WAS 中智能管理功能有所帮助。