内容


迁移到 IBM WebSphere Application Server

第 2 部分:迁移的阶段

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 迁移到 IBM WebSphere Application Server

敬请期待该系列的后续内容。

此内容是该系列的一部分:迁移到 IBM WebSphere Application Server

敬请期待该系列的后续内容。

©2001 International Business Machines Corporation. All rights reserved.

前言

应用服务器市场日新月异。包括 IBM 在内的众多强大的角逐者正引领大家提供支持最新 J2EE 标准的产品。同时,应用服务器市场上的更多昔日的角逐者正走着一条不同的道路。一些应用服务器,如 NetDynamics,正被逐渐淘汰。其它的,如 ATG Dynamo 和 Gemstone/J®,正在改变它们的业务模式以提供在现有应用服务器上的服务而不是支持它们自己的应用服务器。共同的思路是确实有必要把现有的应用迁移到 J2EE 基础上。

迁移不单是把非 J2EE 应用移到 J2EE 标准这一种。我们经常碰到的是要求在应用服务器之间迁移 J2EE 应用。例如,Sun 最近己经停止支持 AIX® 上的 iPlanet,这留下了一大批忙于寻找替代解决方案的 AIX 迷。

在本系列的第 1 篇文章, 迁移到 IBM WebSphere® Application Server ? 第 1 部分:准备迁移中,我讨论的问题是准备从另一个应用服务器迁移到 WebSphere Application Server 的代码。代码迁移只是答案的一部分。事实上,代码迁移可能只是整个迁移过程的一小部分(对 J2EE 应用而言肯定是这样)。在这第 2 篇文章中,我讨论了迁移所涉及的不同阶段,给出了一个样本迁移路线图并就估计整个迁移的工作量提了一些建议。我还提供了提示和技巧以及从现实的客户方案中获得的最佳实践。

迁移过程被分成几个阶段,主要是因为不同的技能集适用于迁移过程的不同部分。安装基础设施不同于编码。编码和性能优化也是需要不同技能的不同过程。

迁移被分解成以下活动或阶段:

  • 确定作用域(Scoping)
  • 技能迁移(Skills Migration)
  • 代码迁移(Code Migration)
  • 运行时迁移(Run-time Migration)
  • 运行时性能优化(Run-time Performance Tuning)
图 1. 迁移的阶段
迁移的阶段
迁移的阶段

把迁移分成阶段能帮助您为每项工作找到正确的人选。拥有若干开发人员的较大型的组织能够利用他们的不同种类的技能库。经过精心计划,阶段之间甚至可以交错。例如,一个小组可能负责迁移应用程序代码的垂直部分,而另一个小组则把这个过程发展到 J2EE 标准。注意到每个迁移是不相同的是重要的。这里提出的阶段仅仅是一个方针,可以按照这个方针实现一个迁移。

确定作用域

在最近的一个迁移工程中,我们跳过了确定作用域阶段,开发人员直接进入到代码迁移阶段。在迁移中,有时会发现客户机的应用程序代码对 EJB 规范作了大量的随意修改;另一个应用服务器的 EJB 实现似乎不受这些修改影响,但 WebSphere 却受影响。从客户机的观点看,WebSphere 是有缺陷的。然而,唯一的“缺陷”(当然这根本就不是缺陷)是 WebSphere 按 EJB 规范实现!

完成代码迁移,最初估计需要两天时间,但作为变通方案,这个时间可以延长到几周,并同时完成对体系结构和代码的修改。可以料到,这会给难于理解为什么他们的代码无法在我们的产品上运行的客户带来很大麻烦。

如果我们做了最初的确定作用域的工作,那么每个人都将可以更好地为实际工作的需要做准备。

确定作用域阶段的目的

确定作用域阶段的目的是确定迁移工作的作用域。这是一个关键步骤,因为它设定了迁移工作余下部分的阶段。此间,您必须做:

  1. 理解需求
  2. 完成设计和代码检查
  3. 检查运行时环境
  4. 制定教育计划
  5. 制定整体迁移计划

这些信息构成估计和风险识别的基础。

涉及到什么

对一个中型应用而言,确定作用域阶段要占约一周时间。下面给出一个作用域确定阶段的日程安排示例:

  1. 检查应用程序需求(0.5 天)
  2. 设计和代码检查(1.5 天)
  3. 运行时环境检查(0.5 天)
  4. 迁移应用程序的单个垂直部分(2.5 到 5 天)

在开始做之前,知道要做些什么是重要的;您必须深刻理解目标以便知道什么时候任务算完成了。需求汇总包含诸如功能需求、性能目标、伸缩和可用性需求这样一些东西。这些需求会影响必须要做的事并且应该很好地归档。即使应用程序已经在另一个应用服务器的平台上运行,把需求写下来仍然有好处。

对照这些需求,应用程序在另一个平台上的表现如何,了解这一点是重要的。应用程序的当前性能可以接受吗?当前的应用程序能伸缩成可处理目前和将来需求的吗?要理解需求是否合理,在简单迁移之外是否还需要做点额外工作(作为这项工作的一部分),就应该回答这些问题。

性能经常被认为是进行一项迁移工作的原因。不幸的是,谈到性能问题,一个更好的算法通常才是最好的解决方案。就是说,如果应用程序代码本身是低效的,那么迁移到替代应用服务器将很可能只会贡献边际收益(如果有的话)。如果性能是迁移背后的驱动力,那么我希望您把时间花在检查和重做应用程序的设计上(这会花去很多时间)。

在迁移的上下文中,设计和代码检查主要关系到识别代码中需要我们在迁移时做些工作的元素 ? 不是代码的整体质量(就是说,质量好的代码通常更易于迁移)。特别地,代码检查应该识别用到的另一个平台的专用技术和所支持的标准的不同版本之间的差别。要达到这个目的,很多代码检查是机械的并且可以很快完成。作为这项工作的一部分,您可能要识别所用的 EJB 的特定版本以及 CMP 实体 bean、BMP 实体 bean、有状态会话 bean 和无状态会话 bean 的特定数量。每种元素类型的数量对于估计所需的总工作量将是便利的工具。

专用技术通常就是迁移中的多数麻烦的根源。在应用服务器的早期,标准的覆盖范围没有 J2EE 覆盖的广。第一代应用服务器用新技术填补了鸿沟。例如,JHTML 是在没有 JSP™ 标准的情况下开发出来的专用技术。JHTML 在概念上有很多方面和 JSP 很相似,但也存在够多的差别,使得在它们之间做迁移比简单的机械过程还是要复杂些。

运行时环境的配置对运行中的应用程序的可伸缩性和可靠性有重大影响。理解运行时环境对应用程序代码的编写方式有什么影响是重要的。为部署在单个节点上而编写的应用程序若不作大量修改,其伸缩性不会很好。在您的估计中必须考虑这些修改因素。

安装运行时环境是件棘手的事。如果目前您有许多服务器正协调地与另一台应用服务器一起工作托管您的应用程序,那么您很可能将需要相近数量的用于 WebSphere 的硬件。虽然安装和配置一个 WebSphere 群集不一定难,但却费时。

理解另一个应用服务器的当前部署环境是有价值的。请确保在您的作用域确定工作中包括用于设计 WebSphere 运行时环境的时间并为以最小成本和最少的服务中断迁移您的运行时制定一个计划。

作用域确定阶段的最后部分是一步一步地迁移应用程序的单个“垂直部分”。垂直部分是应用程序的“自顶至底”表示,它尽可能多地触及有关技术。对 Web 应用程序开发来说,一个垂直部分可能开始于一个从用户那里收集信息的页面,然后用一个 servlet 调用一个负责把用户信息写到数据库的无状态会话 EJB,然后再把用户重定向到另一个页面。垂直部分不必覆盖每一个可能的偶然事件;例如,一个垂直部分可能不提供错误校验或者可能“掐灭”几个技术。值得注意的是,迁移一个垂直部分估计要 2.5 天的时间不包含软件安装或测试时间。

注释:对构建一个完整的垂直部分来说,两天半时间似乎并不多。事实上,确实不多。然而,一个迁移工作与构建一个垂直部分无关;它与迁移一个现有的应用程序有关。作为迁移工作的一部分(这对确定垂直部分的作用域来说最是如此),应用程序的业务逻辑不应改变。这意味着不改动一行代码就迁移一块重要的应用程序代码应是可能的。迁移工作常常很机械。在 EJB 和 JSP 各自的规范的不同版本之间迁移一般不需对应用程序的现有设计作大量改动。然而,在一些案例中,规范的版本间的微妙区别会带来很多麻烦。与容器处理应用程序异常的方式有关的 EJB 规范的版本之间的差别可能会要求对设计的再次考虑。

总之,垂直部分迁移能帮助您识别问题发生的点并制定相应计划。

有很多与迁移垂直部分有关的目标。迁移垂直部分最重要的目标也许是定出估计基础的测量基线。通过代码检查,理解应用程序代码的特征,比如特定元素的数量。把这些信息与迁移一块具有代表性的代码(垂直部分)所需时间的绝对量度结合起来,您就能够拿出一个非常准确的估计(带有发现和测试的适当补丁)。垂直部分迁移的另一个重要成果是让您对迁移最后的成功有信心。

即使垂直部分迁移未能成功地传送一个工作原型,它仍将给您带来有价值的信息。至少,一个“不成功”的垂直部分迁移将识别出难题所在并允许您相应地调整开发进度表。如果您需要帮助,那就获取并早日获取帮助 ? 它将在长期运行中给您回报。

技能迁移

您的小组处理 WebSphere Application Server 时所需的培训依赖于 WebSphere 将取代的应用程序的特征。要考虑的不同技能集有很多。特别是:

  • J2EE 体系结构和编码
  • WebSphere 工具
  • WebSphere Application Server 安装和配置
  • WebSphere 部署

WebSphere Application Server 版本 4.0 与 J2EE 1.2 完全兼容。如果 WebSphere 将取代的应用服务器也与 J2EE 兼容,那么您的应用程序开发人员很可能己经具备了所需的 Java™ 编码技能。如果您打算从不符合 J2EE 的应用服务器(例如 NetDynamics 的较老版本)上迁走,那您很可能得让您的小组获取更新技术的技能。别假设您的小组成员将简单地“拾起”新技术;如果您在开始时进行了适当的培训,将可以节省时间。

另一个应用服务器的详细信息不是至关重要的。然而,理解该平台支持的规范的版本是有帮助的。大体理解该平台提供的专有服务通常就够了。

注释:BEA WebLogic Server 的早期版本使用名为“T3”的远程方法调用(Remote Method Invocation,RMI)的替代品。创建 T3 是为了处理 Sun 提供的现有的 RMI 实现的缺陷。知道 RMI 的这个替代品存在通常就够了(在迁移角色中,对 T3 的详细理解是不需要的)。T3 在 EJB 部署代码的生成中使用,无论如何,这些代码必须重新生成以用在 WebSphere Application Server 上。经常需要对应用程序代码作小量改动以改变用于 EJB 查找的名称格式。

工具是另一个需要考虑的问题。如果您打算采用 WebSphere 开发工具作为迁移工作的一部分,那么接受使用这些工具的适当培训是非常重要的。WebSphere 工具非常强大,但很可能与您的开发人员过去习惯使用的不同。让您的小组学会如何有效地使用这些工具需要花一些时间。

基础设施人员和操作人员负责安装、配置并维持 WebSphere 产品环境的有效运行。我们假设现有的基础设施人员熟悉基本管理事务和他们的系统所运行的操作系统,并且有管理 Web 站点的日常操作的实践经验。基础设施人员须学习如何安装、配置和维护 WebSphere Application Server 产品环境。

您需要的培训的数量在很大程度上依赖于您的目标。如果您打算获取迁移的外界帮助,那么您可以暂时放弃部分或全部培训。

代码迁移

“使它运行,使它正确运行,使它快速运行”是增量开发界里的一个著名“真言”。增量开发的这种风格对士气有积极影响。对开发人员来说,拥有一些能运行的东西通常使进一步的开发更加容易。对管理来说,使一些东西及早运行能带来必然成功的信心。增量开发的这个三步哲学也适用于迁移工作。

在第一步中,用尽可能短的时间和尽可能少的改动使您的应用程序在 WebSphere Application Server 上运行。这应是一个相对短期并带有证明必然成功的努力的过程。在第二步期间,重组您的应用程序以排除错误、使用最佳实践并使它符合 J2EE 规范。这一步的主要目的是提高应用程序的整体质量并使它对将来的改动更具弹性。有了应用程序的“正确”运行,代码迁移的最后阶段就是按需要优化代码。

增量地进行代码迁移提供很多有价值的东西。在使您的应用程序代码运行期间,您可以把设计和代码检查期间未发现的问题揭示出来。通过及早发现这些问题,您就更可能有时间来解决它们或者调整您的优先顺序以适应它们。增量迁移的另一个好处是您可以决定您是否想放弃迁移(可能是等待一个技术的更新版,或者甚至是全部重写)。

使它运行

这一步的真正危险是试图做过多的事情。如果现有的应用程序实际能在另一个应用服务器上运行,那么最好的办法是以尽可能少的改动使它运行在 WebSphere Application Server 上。就是说,努力使现有的应用程序在 WebSphere Application Server 上运行;避免对应用程序做重大的设计改动。可能有应用程序在另一个应用服务器上不能实际运行的情况。在这种情况下,使它运行变得更加困难而且事实上可能变成一项重新实现应用程序的工作。

分而治之是这个阶段能采用的一个优秀策略。如果应用程序写得很好,那么修改和测试必要部件应该相对容易。即使应用程序写得不是很好,也应有可能实施某种形式的分而治之的策略。一个企业应用程序可能非常复杂,带有大量的交互的功能流。这些功能流可以被分解到应用程序的垂直部分中。从一个功能开始并将它完全迁移,然后逐渐地把经过测试的其它功能添加上去。

在迁移过程中,测试案例应随代码一起迁移。如果没有测试案例,那就创建它。您应该在另一个应用服务器实现上运行您的测试案例以确认其正确性。创建测试案例,尤其是为现有的代码创建测试案例,在使单个功能的目的更明确方面是很有帮助的。在后来到了更新或升级继承来的应用程序代码的时候,这些测试案例也是有帮助的。

这个工作与任何应用程序开发工作很类似:

  1. 理解需求。
  2. 理解现有设计。
  3. 制定一个单元测试计划。
  4. 在现有实现上实现单元测试。
  5. 选择应用程序的一个垂直部分,做必要修改,测试并部署到 IBM WebSphere Application Server。
  6. 重复。

极端编程(Extreme Programming)[Beck] 关于开发过程谈了很多。幸运的是,“极端”实践在这个上下文中做得很好。对某些开发工作来说,极端编程实践看起来确实有点太“极端”,不过还是有可以遵循的推荐实践的最小集:

  • 首先处理重要功能
  • 及早解决困难的问题
  • 一次做一件事
  • 做可能有效果的最简单的事
  • 测试,测试,再测试
  • 经常发布
  • 分而治之

有很多首先迁移重要功能的理由:

  • 首先迁移重要功能使决策者能更自由地控制迁移过程以按时实现关键功能。
  • 到了最后,如果必须放弃一些东西,那么知道重要部分己经做好了是件好事。
  • “困难的”问题很可能与最重要的功能有一定相关。
  • 实现困难的问题将用去最长时间。
  • 困难的问题也是很难估计的,因此首先考虑它们能使您稍后能有更多一点的时间(如果需要的话)。

一次做一件事。选择一块功能,然后迁移它。对一小块功能进行迁移、测试并集成比对一大块要容易得多。做可能有效果的最简单的事(不要设法预见您不能确保您会碰到的问题;代码应尽可能简单,但不是更简单)。尽量不要试图在这个阶段修复体系结构的缺陷。使迁移后的代码能运行并就让它那样就行了。在“重组”阶段您应再次考虑体系结构。

测试,测试,测试,再测试。在迁移现有代码之前,请确保它在另一个应用服务器上是按预期运行的。如果您知道它是如何在该平台上运行的并且有测试案例的结果证明它,那么您就能够证明迁移后的代码是按预期运行的。在稍后重新评估体系结构时,这些测试案例也是很有价值的。经常运行您的测试案例 ? 这将救您于不幸。

经常发布。使在部署操作系统(和硬件)上运行的 WebSphere Application Server 对开发人员可用。应在部署测试服务器上对迁移后的应用程序进行周期性的测试。可能是每周或每两周。开发和部署平台之间可能存在微妙差别。请及早确定与这些差别相联系的任何问题。

分而治之。在“使它运行”过程中,请对所有级别的粒度使用分而治之的办法。当然,您可以把整个应用程序分解成垂直部分,但每个切片很可能同样可以被分解(然后再次分解)。例如,您可以考虑使用典型的模型-视图-控制器(Model-View-Controller,MVC)模式的应用程序的一个切片:

  1. 为模型编写测试代码。
  2. 在另一个应用服务器上确认测试的结果。
  3. 迁移模型代码。
  4. 确认迁移后的代码按预期的运行。
  5. 为 servlet 和 JSP 编写测试。
  6. 在另一个应用服务器上确认测试的结果。
  7. 迁移 servlet 和 JSP。
  8. 确认迁移后的代码按预期的运行。
  9. 集成全部迁移工作。
  10. 重复。

值得再说一遍的是,这个阶段应着重于以尽可能最少的改动使现有代码运行在 WebSphere Application Server 中。尽可能多地“抢救”现有代码。单元测试应在应用程序开发过程开始之前就已存在。单元测试将在迁移过程中发展。

使它正确运行

在最近的一个迁移工程中,客户机上有一个大量地违背 EJB 规范的庞大的代码库,而另一个应用服务器应用服务器允许这些对规范的违背。很明显,把代码更新为符合标准的将需要大量改动应用程序的体系结构并将花去几个月时间。最容易的办法是构建变通方案,而不是对应用程序作重大改动。

变通方案(对这些方案的描述会 ? 并可能 ? 产生许多文件)有很多不同形式。在一些案例中,另一个应用服务器的行为被“掐灭”或仿效;在其它案例中,WebSphere Application Server 被用归档 hook 来修改。即使有了适当的变通方案,仍然需要对代码做相对少量的改动。

总之,变通方案允许我们在一个非常短的时间内完成“代码迁移”阶段。在该阶段结束时,应用程序确实能运行了;然而,它存在稳定性问题并且不做更多的大量修改就不能伸缩(完全公正地说,在另一个应用服务器上运行的这种实现不是特别健壮,而且也不能伸缩)。证明了应用程序确实能在 WebSphere Application Server 中运行之后,我们开始重组。

作为重组工作的一部分,我们对应用程序的体系结构进行彻底检查。体系结构的改动被引入到应用程序的垂直部分中。有了一个能运行的应用程序使这些改动容易得多。能在功能系统内对我们的改动进行测试是件很便利的事。随着我们对整个代码库进行一次次的重组,我们对变通方案的依赖也越来越小直至最后它们退役。

总之,把代码迁移分为两个阶段确实是有帮助的。能够实际运行应用程序使我们可以容易得多地修改它。

重组 [Fowler] 是不必增加新行为而修改代码以提高其质量的过程。通常,重组应是正常开发过程的一部分(事实上,在“代码迁移”阶段,一定数量的重组应是自然发生的)。主要手术就是发生在这个阶段。

“主要手术”可以有很多形式。应对应用程序的体系结构进行检查和更新。MVC 是一个著名的也是通常采用的体系结构。您在这里使用已经确定的实践的工作将在长期运行中给您带来回报。跟迁移到 WebSphere Application Server 的未来版本一样,维护也将更容易。即使您目前正在使用 MVC,这个阶段给您确保正确地使用了 MVC 提供了一个机会。通过采用标准,您能够在将来的迁移工作中减轻现在感受到的迁移痛苦。

在更小的规模上,最佳实践的应用程序可能在健壮性、可伸缩性和性能上将产生重大改善。例如,现有的依赖于 DriverManager 或专用连接池的 JDBC 代码可能被更新成使用 DataSource 的。生成 HTML 输出的“经典的” servlet 可能被更新成使用 JSP 的。EJB 可能被更新成实际使用 EJB 功能的。老的变通方案可能被更新(或完全除去)以使用标准功能。

拥有优秀的单元测试使重组容易了许多。单元测试使您对改动充满信心;如果某个改动破坏了一些东西,测试将把它揭示出来。如果您没有单元测试,那么在这个阶段引入它可能是个好主意(例如,如果您在“使它运行”阶段没有找到使用它的机会)。您不必不安,也不必构建几千个测试以进行完全覆盖;您可以一边做改动,一边测试。随着时间的推移,测试的数量将增长,覆盖面也会扩大。和重组一样,测试也应是开发过程的自然组成部分。请考虑在优秀的单元测试工具例如 JUnit上花一些时间。

使它快速运行

到现在,应用程序代码应该已经“正确”运行。就是说,该应用程序已经是 WebSphere 应用程序并且与“一个迁移已经发生了”的事实无关。这个阶段需要的技能与任何 WebSphere 应用程序需要的技能没有任何不同。

运行时迁移

即使是写得最好的代码也要依赖在一个配置适当的应用服务器上运行。安装产品/测试环境是成功的一个关键条件。当然,产品环境的配置可能相当复杂。从头开始安装和配置一个 WebSphere 运行时环境需要几周时间。升级一个在升级过程中必须保持“活动”状态的产品环境需要更长时间。

安装单个 WebSphere Application Server 节点是一件相对容易的事,大约一天就可以大致完成。安装以负载平衡和故障转移为特色的更复杂的节点群会用去长得多的时间。别跟自己开玩笑,以为一个适度复杂的安装在周末就能完成。一个正确的迁移策略是必需的。

假设迁移运行时基础设施很可能将用去一些时间,那么一个尽可能少地干涉运行时系统的变通方案是必需的。升级一个运行时系统有很多途径。正确的方案依赖于几个因素:

  • 多长时间的停机可以接受?
  • 您能再购买多少硬件?
  • 现有环境是如何配置的?
  • 现有环境提供负载平衡支持吗?
  • 现有环境提供故障转移支持吗?

迁移运行时环境的一个显然的方案是简单地构建 WebSphere 环境,然后“切换开关”。就是说,用 WebSphere 取代您的整个现有环境。对小型配置来说,这样做很好;对更大型的配置来说,再添置大量昂贵硬件的成本可能会高得令人不敢问津。

另一个方案可能是基于个别的迁移运行时环境的分支。这依赖于另一个应用服务器对负载平衡的现有支持。如以下的图 2 至 5 所示,分支可以被关闭、升级并重新引入到环境中。这样,就将运行时环境的“垂直部分”迁移到 WebSphere Application Server 来说,运行时迁移与代码迁移并非完全不同。这种方案的一个关键好处是根据配置的大小和迁移单个部分所需的工作量来估计完成迁移的全部工作量是可能的。

图 2. 如果您的应用程序和运行时配置支持的话,迁移一个垂直部分是可能的。首先,选择一个“垂直部分”(灰色部分)并将它从群集中除去。
如果您的应用程序和运行时配置支持的话,迁移一个垂直部分是可能的。
如果您的应用程序和运行时配置支持的话,迁移一个垂直部分是可能的。
图 3. 把该垂直部分重建成一个 WebSphere Application Server 节点并重新引入到群集中(蓝色部分)。请注意 HTTP Server 也被更新以使用 WebSphere 插件。
把该垂直部分重建成一个 WebSphere Application Server 节点并重新引入到群集中(蓝色部分)。
把该垂直部分重建成一个 WebSphere Application Server 节点并重新引入到群集中(蓝色部分)。
图 4. 另外的应用服务器节点(灰色部分)被从群集中除去,并被重建成 WebSphere Application Server 节点。修改“WebSphere” HTTP Server 以识别另外的应用服务器。
另外的应用服务器节点(灰色部分)被从群集中除去,并被重建成 WebSphere Application Server 节点。
另外的应用服务器节点(灰色部分)被从群集中除去,并被重建成 WebSphere Application Server 节点。
图 5. HTTP Server 与 WebSphere Application Server 节点一起升级。随着时间的推移,WebSphere 完全接管了另一个产品。
HTTP Server 与 WebSphere Application Server 节点一起升级。
HTTP Server 与 WebSphere Application Server 节点一起升级。

上面的图 2 至 5 图解了运行时迁移,它代表一个最佳案例方案,并且要求另一个应用服务器须提供对负载平衡的支持。应用程序的编写方式也对整个工作有影响。例如,WebSphere 不太可能与另一个应用服务器共享 HttpSession 数据;如果应用程序被写成需要 HttpSession 数据的,而且运行时的配置不能“pin”特定节点上的一个用户,那么这种风格的迁移将行不通。在这种情况下,一些方案组合也许行得通。

总之,对运行时迁移工作来说,本质上有两部分。在您的人员能尝试迁移运行时之前,他们先得学习关于 WebSphere Application Server 的更多知识。从迁移一个“系统测试环境(System Test Environment)”开始;这个环境通常可以长时间停机,并且是一个好地方,您的人员可在这里学习如何为应用程序的运行对 WebSphere Application Server 作最佳配置,并允许他们犯错。

在迁移系统测试环境中学习迁移规则,它也允许您犯错。在这个迁移中学到的教训的基础上,制定一个计划来指导整个迁移并在 QA 环境中测试该计划。如果可能的话,以垂直部分方式迁移您的配置,计量迁移单个垂直部分所需的时间并用它来估计整个工作量。

通过从系统测试环境开始,然后移到质量保证环境中,您就能够制定并完善一个有效的计划,并且降低迁移活动的产品环境的风险。

全体 WebSphere 环境(Corporate WebSphere Environment)

一般而言,我们推荐把几个环境配置为“全体 WebSphere 环境”的部件(对其它应用服务器也是如此)。最小而言,您应该至少有一个“系统测试环境”、一个“质量保证环境”和一个“产品环境”。

“产品环境”供最终用户使用。这个环境通常有非常严格的可靠性要求并被扩展以支持您的整个用户群。

“质量保证(Quality Assurance,QA)环境”环境用于测试运行时和应用程序的整体正确性。它是产品环境的向下伸缩版,而复杂性是同等的。就是说,QA 环境的配置与产品环境的配置相似(相同的防火墙、负载平衡器、后端系统等等的配置。),只是规模更小(例如,QA 环境的群集可能包含更少节点)。在产品中做某些改动之前,这些改动已在 QA 环境中做过。QA 环境通常容许更长时间的停机,这使它成为测试您的迁移计划的适当环境。

可能要配置大量的“系统测试”环境,这取决于您的特定需要和预算限制。系统测试环境由管理人员用来测试补丁程序和配置改动,然后再将它们用到 QA 和产品环境中。软件开发人员可以用与产品环境极为相似的系统测试环境来测试他们的代码。性能测试人员也用系统测试环境做他们的工作。通常把系统测试环境配置成能反映产品环境复杂性的,并且尽可能在最小规模上达到。因此,系统测试环境的构建和维护相对便宜。

在迁移系统测试环境中学习迁移规则,它也允许您犯错。在这个迁移中学到的教训的基础上,制定一个计划来指导整个迁移并在 QA 环境中测试该计划。如果可能的话,以垂直部分方式迁移您的配置,计量迁移单个垂直部分所需的时间并用它来估计整个工作量。

通过从系统测试环境开始,然后移到质量保证环境中,您就能够制定并完善一个有效的计划,并且降低迁移活动的产品环境的风险。

性能优化

对一个迁移后的应用程序进行性能优化没有任何特别的东西。到您进行性能优化时,您的应用程序应该已经是一个与 J2EE 1.2 兼容的 WebSphere 应用程序。这意味着可以使用现有的 WebSphere Application Server 性能优化技能(请参考《WebSphere V3 性能优化指南》[Ueno],这是一本关于性能优化的 IBM 红皮书)。

对部署的应用程序进行性能优化有很多不同形式。可在代码级或运行时级进行性能优化。无论如何,在开始优化过程前,很可能要对应用程序的目标进行重新评定。与另外购买硬件的花费相比,代码优化可能是相当昂贵的。

结束语

通过把迁移分为几个阶段,您就可以利用不同种类的技能库。例如,这里提出的代码迁移阶段的“使它运行”这一步可能需要一些另一个应用服务器及它所提供的服务方面的知识。在完成代码迁移之后开始的“使它正确运行”这一步,需要具备把现有应用程序升级到 J2EE 所要求的技能。到开始“性能优化”阶段时,应用程序本质上已是一个运行在 WebSphere Application Server 上的 J2EE 应用程序,这时可以使用标准的(现有的)技能。

要估计完成迁移所需的工作量,确定作用域的做法是您的两全之策。通过代码检查,您可以估计出迁移的绝对大小。通过迁移应用程序的一个具有代表性的垂直部分,您可以算出完成迁移所需的时间(并找出可能带来麻烦的根源)。 这些值的乘积提供了完成整个迁移大致所需的总时间。通过首先迁移应用程序中重要的和更具风险的部件,并及早修改工作中的进度和优先顺序,您可以降低一些风险。

不要害怕寻求帮助。我们之外有很多人以前做过这种事。您不必独自做此事。


相关主题

  • 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  • [Beck] Beck 和 Kent 的 Extreme Programming Explained: Embrace Change。大众读物:Addison-Wesley,1999 年。
  • [Fowler] Fowler 和 Martin 的 Refactoring: Improving the Design of Existing Code。大众读物:Addison-Wesley,1999 年。
  • [Ueno] Ueno 和 Ken(主要作者)的 WebSphere V3 性能优化指南IBM 红皮书,SG24-5657-00,2000 年。

评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=55026
ArticleTitle=迁移到 IBM WebSphere Application Server: 第 2 部分:迁移的阶段
publish-date=11012001