级别： 初级 David Kra (dakra@us.ibm.com), 执行 IT 架构师
2004 年 6 月 01 日 本文是这个系列的第一篇文章，定义了启用网格应用的六种策略。本文解释了适用于这些策略的应用程序特性，以及运行这些应用程序给整个组织带来的好处。后续文章将探讨如何花费尽可能少的代价，通过 1 至 5 这五种策略，来启用网格应用。
启用网格简介
本系列的
第 2 部分介绍了如何用六种策略中的前面两种启用网格应用，在这种情况下应用程序作为一个或者多个批处理任务运行，这些任务的位置相互独立。
第 3 部分讲述了六种启用网格应用策略中的 3、4 两种，文中概要介绍了如何划分批处理程序的工作，以及如何将程序变为服务子例程，以供客户机通过网格中间件进行调用。
所谓启用网格的应用程序是指这个应用程序可以完全运行在网格之上。然而，要完全开发出网格的潜力，就意味着必须利用实质性的网格基础设施来加快处理过程或提高协作程度。随着 OGSA 等网格标准的逐渐成熟，启用网格意味着应用程序在网格环境中以 Web 服务的方式运行，同时能够选择是否利用网格基础设施中提供的多种服务。比如说，在即将发布的 WebSphere® Application Server 中，J2EE 或 C 的应用程序可以作为 Web 服务在启用网格的中间件之上运行，同时还可以利用中间件和网格基础设施中提供的服务。
启用网格的策略有六种。从仅仅在网格中运行程序，到充分利用网格的优势。有一点十分重要，仅仅是在网格中运行程序，您的客户就可以获得价值，您也可以获得盈利以及在业界的领导地位。同时，通过提供网格的功能（如文件的系统与任务调度），您也许能够减少产品中的非核心功能代码，而不会损失功能。
随着时间的流逝，对启用网格的需求是不可避免的：您的应用程序必须能以 Web 服务的形式访问。比如说，应用程序必须有自己的 EJB 组件，并公开为 Web 服务，或者必须具有某种 Web 服务的工件（wrapper、接口、facade、veneer 或其他您喜欢的名字），并能够通过它调用已有的代码。目前已经有了实现这一目标的工具。
由于网格的标准已经构建到适当的 Web 服务规范中，在应用程序中启用 Web 服务也变得越来越重要。面向服务的架构和 Web 服务正成为战略网格环境的基础。
本文所描述的启用网格的策略是相互关联的，但是这些策略确实具有不同的好处，为实现这些好处所要做的工作也不同。本系列将向您介绍这六种网格并发和并行应用实现策略中的五种。
即便是每一种策略都有其自身的价值，也并不是每一个应用程序都需要实现最高级的策略。很多应用程序都不会接触第五级，大多数已有的应用程序不需要因此也不用达到第六级。第六级策略是供具有特殊需要的应用程序使用的，它的设计从底层开始就支持并紧密集成了并行处理，可以在构成应用程序的各种不同的程序中使用。
同时，您的应用程序并不一定要一步一步地实现其目标策略，也不必一步登天。比如说，在策略 2：独立并发批处理和策略 5：并行服务之间，典型的产品发布路线可以包括策略 3：并行批处理或策略 4：服务中的一个，但是不包括全部。有关这六种策略的详细解释请参阅
图 1。
图 1. 六种启用网格的策略
在本系列文章的讲述进程中，任何较低层策略带来的好处都认为是已经具备的。同时还假设应用程序已经获得了某些技术属性，能够满足前面的策略的要求。
六种策略和实现的三个阶段
本文简要介绍了这六种策略，以及在应用程序中实现每种策略所能获得的好处：
- 策略 1：简单批处理（Batch Anywhere）
- 策略 2：独立并发批处理（Independent Concurrent Batch）
- 策略 3：并行批处理（Parallel Batch）
- 策略 4：服务（Services）
- 策略 5：并行服务（Parallel Services）
- 策略 6：紧耦合并行程序（Tightly-Coupled Parallel Programs）
这些策略可分为三个实现阶段：
-
运行—— 策略 1 和 策略 2，以及策略 3 的最简单形式，这一阶段着重实现应用程序能够在网格中运行。
-
适应 —— 策略 3 中较复杂的形式，以及策略 4 和策略 5，在不要求针对网格中间件的特定要求做很多变化的前提下，通过在应用程序中启用网格功能来适应其功能和价值。这一阶段的意义重大。同一个应用程序还可以改变其结构，在非网格环境中运行。
-
利用 —— 处于策略 6 的应用程序可以在其操作中利用网格或群集基础设施，因为在一开始编写这些应用程序的时候就将网格考虑进来了。属于策略 6 的应用程序如果不在网格中运行就不能在有限时间内成功完成任务。
图 2六种策略如何对应于启用网格的三个阶段。
图 2. 启用网格的三个阶段
这六种策略不是互相排斥的。它们是策略，也可以看作采纳网格的阶段，或集成的风格。它们之间相互关联，可以认为是循序渐进的里程碑，从相对简单的采纳网格的策略，如作为简单批处理（Batch Anywhere ）任务运行，逐渐发展到启用更强的网格功能，如紧耦合并行程序（Tightly Coupled Parallel Programs）。
这六种策略中的每一种都可以从其前面一种策略的基础上发展起来，从这个意义上将，它们是相互关联的。例如，可以在已有的应用程序中按这样的方式启用网格功能：将其中消耗资源最多的计算任务当作简单批处理任务，在网格中最适当的计算机上执行（也就是第一种采用网格的策略）。由网格在运行时决定将该任务指派给哪一台机器。
然后，通过消除抑止并发操作的因素，同一个应用程序进一步发展为启用网格功能的任务单元，可以作为同一个批处理任务中的独立并发批处理（Independent Concurrent Batch ）实例来运行（策略 2）。这样，整个应用程序的吞吐量就比一个时刻只有一个实例运行的情况大大提高了。
下一步，应用程序可以朝两个方向发展：
-
可以进一步消除阻碍并发的因素，允许其中启用网格功能的任务单元作为并行批处理（Parallel Batch）任务运行（策略 3）。请注意，这时可能发生改变的是工作单元的定义，而应用程序不会变化。在这种情况下的工作单元可能是实现前两种策略时采用的一组原始工作单元。必须向应用程序中加入两个组件：一个负责对任务进行划分，并将其提交给网格。另一个负责收集计算结果。
-
重新设计应用程序，启用网格的工作单元不再作为一组批处理任务运行，而是作为服务（Service）（策略 4）。
最后，可以进一步重新设计应用程序的工作单元，将其作为多个在后台运行的可并行调用的有状态服务。
已有的应用程序通常很难达到策略 6 的要求，因为重新设计应用程序的代价会抵消其带来的好处。最好是重新开始设计，将应用程序实现为紧耦合并行程序。
 |
要点提示
启用网格应用有六种策略，您可以分三个阶段来完成
（
运行,
适应，以及
利用）。
-
并不是每一个应用程序都需要实现第六种策略。大多数甚至不能实现它。
-
每一种策略都能带来价值。
-
您并不一定非要一下子就实现期望的策略。
您的业务应用组件可以在网格中的节点上运行。
-
可能不需要知道网格中间件的存在。
-
可能需要进行修改的地方很少，甚至根本不需要。
-
可以利用网格中间件的优势。
-
网格节点可以对客户机或服务器上资源的收集或废物利用，否则只有当这些机器空闲时才能提供这些资源。
关注应用程序。
-
将应用程序与集成和部署分离开来。
-
隔离出只与网格中间件有关的代码。
-
让负责集成和部署的团队选择以何种网格中间件作为开发基础，并让他们执行与中间件有关的工作。
使用业务组件的客户机应用程序的确会使用网格中间件。
应用程序可以也应该可以不断发展变化，以便更好地利用网格。
|
|
策略 1：简单批处理
图 3说明了只有网格（而不是应用程序、客户机、用户或其他任何事务）才能决定给任务指派哪一个节点。图 3 也体现了一个事实，即，提交任务的机器可能不是网格中的一个节点。比如说，可以查询某个给定数字 x 是不是素数。网格中不止一个节点都可以提交这个相同的查询请求。网格会将正确的结果返回给提交者。
图 3. 策略 1：简单批处理
这种策略的目标是能够在众多的网格节点中的任何一个上运行应用程序的一个实例，这个节点的选择是网格中间件在运行的时候作出的。下次运行的时候，中间件可以选择某个其他的节点。在这种策略中，并发仅仅体现为这个节点以及其他节点可以并发地运行不同的应用程序。
策略 1：简单批处理的主要特征在于：
- 位置独立性，任务的一个实例可以在多个节点中的任何一个上运行。
- 在 LAN 和 WAN 环境中的 I/O 容量、定时功能与性能都是令人满意的。
- 准备工作不太繁重。
- 软件许可工作不太繁重。
- 足够的安全管理级别。
- 启动时间令人满意。
- 任务调度由日程表、前提任务，或文件是否到达来决定。
那么，
令人满意的，
不太繁重，和
足够的意味着什么呢？在下一篇文章“启用网格应用的六种策略：策略 1：简单批处理和策略 2：独立并发批处理”中我们将更详细地解释这些以及更多的其他术语。
策略 2： 独立并发批处理
启用网格的策略 2 可支持同一个应用程序的多个独立实例并发执行。除了第一种策略的主要特性之外，策略 2：独立并发批处理的特性还包括：
- 多个实例可独立运行，不会相互干扰。
- 独立任务是公用的。比如说，Account A 的 Job X 可以与 Account B 的 Job X 并发运行。
- 数据库或其他资源不会成为瓶颈，也不会发生死锁。
对策略 2 而言，同一个任务，比方说 Analysis-A，可以并发但独立地运行多次。也就是说，John 通过 Analysis-A 的一个实例处理自己的书籍，而 Jane 通过 Analysis-A 的另一个实例处理数据。这种并发对于第一种策略而言并不是一种重大的变化，但是还是要付出一些努力才能实现，同时也能获得一些额外的好处，下一篇文章“启用网格应用的六种策略：策略 1：简单批处理和策略 2：独立并发批处理”将更详细地讨论。
策略 2：独立并发批处理的其他主要特征包括：
- 应用程序可能会获得充足的并发性，以便实现其目标。
- 这种并行性策略可能已经足够，不再需要进一步划分。
图 4显示了在网格中运行的多个应用程序实例。
图 4. 策略 2：独立并发批处理
策略 3：并行批处理
策略 3：并行批处理接管每一名用户的批处理任务，划分之后再分发到多个节点上，然后收集起来，得到最后的结果。
在策略 3: 并行批处理中，我们开始使用客户机和服务器这两个术语。客户机/服务器术语确实不适用于前两种策略中的批处理任务。在那两种策略中，只有一个，或独立的多个并发实例，要说有客户端存在，也就只是存在一个提交任务的请求节点罢了。这个节点将任务提交给调度器，如 Tivoli Workload Scheduler，或 Platform JobScheduler（相关链接请参阅
参考资料）。调度器把任务提交给网格中间件，然后在提供网格资源的节点上执行任务。现在，在策略 3 中，客户机作为请求方，先将任务进行划分，然后提交，最后汇聚处理结果。策略 3 中的一个新特性在于，收集任务处理结果与提交任务采用了不同的程序。
策略 3: 并行批处理的主要特征包括：
- 在划分和向节点分发任务时可以并行。
- 可以将程序的功能划分为一个客户机和多个服务器任务。
- 客户机可以将任务划分为较小的服务器任务，然后分散执行。
- 如上文所述，服务器任务是以多个独立的实例运行的。
- 客户机搜集完中间结果之后，就可以组装出最终的结果。
图 5说明了如何在节点之间划分子任务。
图 5. 策略 3：并行批处理
策略 4：服务
策略 4、5、6 超越了批处理的范畴，通过网格中的
服务来完成任务。策略 4：服务的重点在于将批处理转变成面向服务的架构。策略 4：服务是策略 2：独立并发批处理的延伸，但不是策略 3：并行批处理的延伸。在策略 4：服务中，
不存在每一个客户机划分自己的任务然后分散到多个服务实例上这样的假设。
策略 4：服务的主要特征包括：
- 客户机通过网格中间件调用服务。
- 根据客户机的行为，网格中间件负责调用服务。服务的结构应该是可调用的，典型情况下是类、子例程库，或 DLL。
- 客户机和服务器是松耦合的。
- 多个独立的客户机之间可以共享服务。
- 服务可以在多次调用之间维持状态。
- 即使服务启动时间长也没问题，只要服务是长期运行的，而且每一次运行时都被多次使用，如果在第一次使用之前服务已经启动，那就更好了。
图 6说明了在策略 4：服务中客户机调用服务的情况。
图 6. 策略 4：服务
策略 5: 并行服务
策略 5 将策略 4：服务面向服务的架构和策略 3：并行批处理对任务进行划分的模型结合在一起。
策略 5：并行服务的主要特征包括：
- 可以提供多个服务实例。
- 允许根据客户机的行为并行调用这些实例。
图 7说明了并行调用多个服务实例的情况。
图 7. 策略 5：并行服务
策略 6: 紧耦合并行程序
策略 6：紧耦合并行程序属于工程、物理和生物学建模等领域的专用应用程序的范畴，包括有限状态机等等。
策略 6：紧耦合并行程序的主要特征是能够在
提供密集的通信与同步机制。
这一策略的特征在 IBM Redbook“RS/6000 SP: Practical MPI Programming”中有更加详细的描述，相关链接请参阅
参考资料。
策略 6：紧耦合并行程序能够带来的额外潜在好处主要包括：
- 更加快速地获得结果。
- 支持那些通常不能容纳在一个节点上，或者不能在十年之内运行完毕的应用程序。
图 8说明了在策略 6 中程序是如何实现交互式紧耦合的。
图 8. 策略 6：紧耦合并行程序
为什么有六种启用网格应用的策略？
有些人可能会认为，策略 1：简单批处理和策略 2：独立并发批处理可以合并为一种。将其分开的理由有下面两条：
-
带来的好处不同：在很多业务案例中，虽然策略 1 不能按时完成任务，但是策略 2 却可以，同时也不需要实现策略 3：并行批处理。比方说，当某个医疗记帐公司处理多次门诊产生的任务时，如果对每一次门诊的处理是独立的，那么策略 2 提供的并发性就能够有效地利用节点资源。这种并发可以避免在每一次门诊所在的位置或涉及的患者这个层次上实现并行化。
-
付出的努力不同：在很多情况下，特别是存在软件许可证时，达到策略 2 花费的代价要比策略 1 多得多。
策略 6：紧耦合并行程序是另一个极端的情况，从技术上将它应该是两个独立的策略：一个是密集通信的紧耦合并行批处理，另一个情况相同，只不过是针对服务而言的。然而，这两种策略涉及的问题非常相似，除了将批处理程序转换成服务的部分。而这个问题已经在策略 4：服务，或策略 5：并行服务中解决了。想想看，这不是核物理中的正式“标准模型”（相关链接请参阅
参考资料），每一个例子类型都必须与另一个匹配成对。我们只是在使用网格而已。
参考资料
关于作者 | 
| | David Kra 是 IBM Grid Computing 组织的执行 IT 架构师。他在 IBM 度过的 27 年职业生涯中，一直在指导用户的分布式计算项目，从应用程序层到电缆连线，从需求到部署，他都可以提供建议。自从上世纪 70 年代以来，他提出了各种具有可扩展性、高容量、高可用性的通信解决方案，几乎涉及 IBM 的每一种平台，以及若干种非 IBM 的平台。他是 IBM Academy of Technology 的成员。
|
对本文的评价
| 
