级别： 初级 David A. Kra (dakra@us.ibm.com), 执行 IT 架构师
2004 年 6 月 01 日 本文是该系列文章的第 4 部分，也是最后一篇文章。文中描述了启用网格应用的六种策略中的第五种。这个级别上的应用程序已经变成服务子例程的多个实例，可由客户机通过某种网格中间件并行调用。本文解释了这一级别应用程序的特性，同时也总结了程序开发人员必须、应该和可以做哪些工作来实现并利用这个级别。主要的目标是尽可能让应用程序不知道网格中间件的存在。
简介
本系列文章的第一篇“启用网格应用的六种策略，第 1 部分：概述”（相关链接请参阅
参考资料）概要介绍了这六种策略，并总结了每一种策略的特性和能够带来的好处。
第二篇“启用网格应用的六种策略，第 2 部分：策略 1：简单批处理和策略 2：独立并发批处理”（有关链接请参阅
参考资料）展示了如何在使用这两种策略的网格中启用应用程序。第一种策略将应用程序启用为单独的作业，可以在众多网格计算机中的任何一台上运行。第二种策略启用应用程序的多个独立实例，这些实例可并发运行。
第三篇“启用网格应用的六种策略，第 3 部分：策略 3：并行批处理和策略 4：服务”（有关链接请参阅
参考资料）讨论了用这两种相互排斥的策略启用网格应用的情况。策略 3：并行批处理将批处理任务划分为子作业，发送到网格节点上，随后将每一部分结果收集起来。策略 4：服务是从批处理到面向服务架构的过渡步骤。
您的应用程序可能不需要实现启用网格的后两种阶段。只有当您需要多个同步的服务实例时才应该实现策略 5。更进一步讲，大多数现有的程序都不需要也不能使用第六种策略，因为它是为专门的程序需求服务的，这些程序
从设计的时候开始就和并行处理紧密耦合。本次启用网格系列文章除第 1 部分外，并不对策略 6 做更多介绍。有关如何为策略 6 设计应用程序的更多信息，请参阅 IBM Readbook “RS/6000 SP: Practical MPI Programming”（相关链接请参阅
参考资料）。图 1 对这六种策略进行了说明。
图 1：六种策略的说明
策略 5：并行服务
当您决定采用策略 5：并行服务的时候，它与前面几种策略最大的区别就在于，您可以立即为一项服务生成多个实例，并且每一个客户机都可以并行地使用这些服务。策略 5 是策略 3：并行批处理（一项作业的任务被划分为子作业）在服务架构中的体现。在策略 5 中，客户机将服务请求针对网格中间件进行划分，以便指派给服务实例。有关策略 5 的说明，请参阅图 2。
图 2：策略 5 的说明
在策略 5 中：
- 客户机的每个实例都可以并行使用多个服务实例。
- 服务实例之间并不通信。这就类似于策略 3 中以批处理划分为基础的并行实现（“embarrassingly parallel”）策略。
- 服务请求的速率依然是中等。客户机程序与服务器之间是轻度耦合关系。
策略 5：并行服务是启用网格策略 3：并行批处理和策略 4：服务的真正结合。它与策略 3 相似，可以并行处理已经经过划分的任务，同时也具有服务实例，这一点正是策略 4 的风格。
用策略 5：并行服务启用网格应用所带来的好处
策略 3 和策略 4 的结合提供了一些混合性的好处。在并行和服务预先初始化机制的共同作用下，相应时间得到了改善，只有第一次服务请求的情况可能是个例外。在网格中提供并行服务带来的另一个主要好处在于，客户机可以用全新的方式利用这些服务，下面将要谈到。
基于状态的并行性
策略 3：并行批处理中采用的并行技术（“embarrassingly parallel”）其基础是向原本相同的同一子作业实例中传送不同的参数。这种方法有时被称为“参数并行性”（parametric parallelism）。策略 5：并行服务除了参数之外，还允许使用其他类型的并行，即，基于状态的并行性。在基于状态的并行性中，每一个服务实例在典型状态下都具有不同的状态信息。
多播
在多播的情况下，客户机用相同的参数调用所有的服务器实例，然后，每一台服务器基于其自身的状态以及已经拥有的信息进行处理。稍后，每一台服务器都可能改变自身状态，并返回适当的结果。
考虑数论中的一个例子：查找素数。服务器上的服务具有 100 个实例，其中的每一个都对输入的数值进行检查，看它是否能被该实例自己的素数清单中的数字整除。第一个服务实例上的清单包含了从 1 到 1,000,000 之间的所有素数。第二个服务实例上的清单包含了从 1,000,001 到 2,000,000 之间的所有素数，依此类推。如果一个大数字一次被发送到所有这 100 个实例上（“多播”），那么就可以检查出它是否能被小于 100,000,000 的任何一个素数整除，而完成整个任务的时间只是一个实例情况下的大约 1/100。
大约这个词表示我们不承诺获得这样的结果。其原因有多种。任务花费的时间比策略 3：并行批处理少，这是因为每一个服务实例不需要在处理每一次请求的时候加载或计算自己的素数清单。从另一方面看，网格中间件将服务请求分发到 100 个服务实例上花费的时间要比只分发到一个实例上稍微多一些。
实例研究：策略 5
策略 5 的实例是一个确定数字是否为素数的应用程序。清单 1 展示了判断素数服务所提供的功能。
清单 1. 判断素数服务提供的功能
:
boolean TestRelativelyPrime (long n)
/* Report whether n is prime relative to whatever primes the
service instance is responsible for */
instanceID TakeResponsibility(long low, long high)
/* Take responsibility for knowing which numbers in the range
{ low .. high } are prime */
/* result is the instanceID of the service which has taken this responsibility */
boolean DropResponsibility(long low, long high)
/* Drop responsibility for knowing which numbers in the range
{ low .. high } are prime */
long [ ] [ ] ReportResponsibility()
/* Report the ranges in which the service instance is responsible for knowing
which numbers are prime */
/* result is 2 column array
low 1 high 1
low 2 high 2
low 3 high 3
low n high n
*/
|
注意：并不是每一种网格中间件都提供包括多播、全播（eachcast）、选播（anycast）、单播（unicast）在内的所有分发机制。
其他服务使用模型
在前面所举的数论例子中，我们向所有服务器同时多播相同的参数。然而，策略 5 还提供了三种其他的调用模型，即，“全播”、“选播”和“单播”。
-
全播。
“全播”意味着客户机可以通过网格中间件向每一个服务实例发送一组特殊的参数，这些参数可能不相同。同样在前面多播的例子中，使用这种技术可以通知 100 个服务实例其各自的“职责”。客户机创建一个具有 100 组参数的数组 { {1, 1000000}, {1000001, 2000000}, {2000001, 3000000}, ...{99000001, 100000000}, }。然后，通过网格中间件将这个数组全播到判断素数服务实例的 TakeResponsibility 方法上。（从清单 1 中可看到判断素数服务中的这个方法，以及其他方法。）
-
选播。 “选播”意味着客户机可以让网格中间件将大量服务器请求分配给较少的服务实例。当提供服务的机器速率不相等时，这种技术特别有用。假设在上面的例子中，客户机想让服务检查小于 1,000,000,000 的数字是否是素数。可以将超出的部分划分成 100 个相等的块，多次进行全播，让每一个服务实例都承担相等的附加工作。然而，这样做的前提是假设所有的机器速度相等，且都能专注于提供服务。这是一种不安全的假设。客户机应该改变策略，将这一部分数据划分为 900 个不同的参数组，并令网格中间件选播到 TakeResponsibility 调用上。性能较好的节点将迅速完成一次 TakeResponsibility 调用，然后会再得到一次请求。
我们假设 TakeResponsibility 没有隐式地自动执行 DropResponsibility。每个 TakeResponsibility 请求都是在实例先前的状态下构建起来的，这样就使得实例能够处理另一个范围内的素数。
当处理选播时，网格中间件会在服务实例中分配调用请求，使其能够尽可能快地处理。判断素数服务如果运行在比较快的机器上，那么计算新范围内素数的速度就会比慢速的机器快。然后，这台机器将分配到另外一个尚未处理的数字范围，依此类推，直到所有的范围都处理完毕为止。
-
单播。
到目前为止，客户机不仅可以访问很多服务器上的服务实例，而且只要客户机使用了这些实例，它使用的就是全部的实例。“单播”使得客户机将请求发送到某个特定的服务实例上。在我们的素数测试例子中，如果待测试的数据小于 1,000,000,000，那么客户机可能将任务发送到某个可负责该数字所在范围的特定服务实例上。
假设服务实例 75 负责 74,000,001 至 75,000,000 范围内的素数。为了检查 74,654,321 是不是素数，客户机可以将 74,654,321 单播到素数检查服务实例 75 的 TestRelativelyPrime 方法上。实例 75 只需要在预先计算好的速数表中查找，看其中是否包含 74,654,321 即可。
客户机该如何知道哪一个服务实例处理哪个特定范围呢？尤其是在将 900 个 TakeResponsibility 调用选播到 100 个服务实例上之后，这个问题尤其严重。答案可能与网格中间件及其使用方式有关。一种可能性在于从 TakeResponsibility 方法返回的是实例的 ID。另一种方法是服务提供 ReportResponsibilities 方法，客户机可以通过多播的方式对所有服务实例调用这个方法。
关注策略 5 中的服务器
由于策略 5 并行服务是并行和服务两种策略的结合体，因此这种技术“必须”以及大多数“应该”和“可能”实现的功能已经在前一篇文章中讨论过了。然而，我们从上面的素数测试例子中可以看到，策略 5 提供了大量的新机会可供利用。您当然可以将应用程序改进得更好。
只实现前文的建议当然很容易，但是这里有一些新的东西需要考虑，如初始化、终止等。
初始化多个服务实例的过程很可能由一名用户引发。这个过程可能会并行发生，不过可能不要求同步。当某个程序访问深入后台的某一层次上的资源时，就必须考虑同步的可能性。除了前面讨论到的干扰、锁、热点以及死锁问题之外，还要考虑到资源是深入后台的，它可能已经有缓冲，这样可以有助于另一个实例的启动，但也可能没有缓冲，因此会损害启动过程。
究竟是让每个实例使用一个大的资源请求（自私的用法），还是分成 100 个较小的请求（礼貌的共享方式）？这要看情况而定。某种条件能让一个实例在只有一个实例的时候以最快的速度完成初始化，却并不意味着相同的条件能在 100 个实例的情况下让所有实例以最快的速度完成初始化。测试应该在典型的或者最坏的情况下进行，而不应该在只要一个实例的情况下进行。
提供一个示例客户机和接口定义
在规划示例客户机程序的时候，您应该考虑服务、客户机以及中间件部署环境出现变化的情况。网格中间件可能只提供了单播、多播、全播、选播服务调用方法中的一个子集。在一种极端的情况下，您的服务可能只有一个实例在运行，或者中间件只支持单播。还有另一种极端，可能出现成千上万的客户机实例，而且每一个客户机都可能使用了一个，多个，或者所有这成千上万个服务器上服务实例。
虽然策略 5 侧重于并行服务，您还是应该提供一个可处理服务实例的退化样例程序，在这个程序中可以忽略多播、全播以及选播特性。您还必须提供可展示并行服务及多个客户机用户用法的示例。
策略 5：并行服务总结
为了将服务器应用程序启用为实现并行服务的网格应用，您至少应该实现哪些功能？
- 初始化和终止：也许不是全部实例，但可能很多实例都会并发地开始或者停止。
- 客户机示例：提供简单和特殊的示例。
图 3. 网格环境中的客户机和服务器
结束语
下面总结一下这六种策略：
| 策略 1 | 简单批处理 | 应用程序可以作为一个单独的作业，在众多网格计算机中的任何一台上运行。 | | 策略 2 | 独立并发批处理 | 应用程序的多个独立实例可以并发运行。 | | 策略 3 | 并行批处理 | 批处理程序的任务经过划分，这样多个独立的程序实例就可以分别并行处理作业中的每一部分。 | | 策略 4 | 服务 | 程序变成了服务子例程，客户机可通过某种网格中间件调用这个例程。 | | 策略 5 | 并行服务 | 程序变成某个服务子例程的多个实例，客户机可通过某种网格中间件并行地调用这些实例。 | | 策略 6 | 紧耦合的并行程序 | 这种特殊的程序要求，并且从一开始就设计为紧密耦合的并行处理方式。 |
在应用这些策略的过程中，您的目标是关注应用程序本身：将应用程序从集成和部署的过程中分离出来。将与特定中间件有关的代码隔离出来，并让集成小组和部署小组根据他们在多种网格中间件中选择的结果，完成与特定中间件有关的工作。您所实现的策略要能为用户带来他们所要求的商业利益。
有关那些您“必须”、“应该”和“可以选择”实现的任务，您应该完成环境要求并且用户也能从中获益的工作。有一些额外的可选增强功能在“可以运行”和“运行得更好”之间形成巨大鸿沟。这些特性除了带来额外的价值之外，甚至还可能让能够“运行得更好”的那个版本的价格极其高昂。
参考资料
关于作者  | 
| | David Kra 是 IBM Grid Computing 机构的执行 IT 架构师。他在 IBM 度过的 27 年职业生涯中，一直在指导用户的分布式计算项目，从应用程序层到电缆连线，从需求到部署，他都可以提供建议。自从上世纪 70 年代以来，他提出了各种具有可扩展性、高容量、高可用性的通信解决方案，几乎涉及 IBM 的每一种平台，以及若干种非 IBM 的平台。他是 IBM Academy of Technology 的成员。
|
对本文的评价
| 
