一家票务公司要销售滚石乐队的告别演出门票，IT部门经理担心，开始网上售票后，公司的服务器和软件会不会不堪重负?但实际上该公司并没有增加数十个服务器和存储系统，有关IT人员只是拧开开关，将公司的骨干网与一个“网格”相联。结果公司在3分钟内销售了90万张门票，没有一个顾客因系统处理能力不足而被拒之门外。
上述情景并非可望而不可及。网格作为一种能带来巨大处理、存储能力和其他IT资源的新型网络，可以应付临时之用。网格计算通过共享网络将不同地点的大量计算机相联，从而形成虚拟的超级计算机,将各处计算机的多余处理器能力合在一起，可为研究和其他数据集中应用提供巨大的处理能力。有了网格计算，那些没有能力购买价值数百万美元的超级计算机的机构，也能利用其巨大的计算能力。
计算的“乌托邦”？
Gartner公司的Rob Batchelder认为，网格的构想一直是计算领域的“乌托邦”，在科技应用上虽有巨大前景，但最大的缺陷是缺乏明显的商业应用。自20世纪90年代在欧美出现以来，网格主要被用于帮助分散的大学研究人员分析粒子加速器和巨型望远镜的数据。但在过去的两年中，网格的概念和GlobusToolkit已在研究和教育领域得到广泛应用，数十项全球性的大项目采用这些技术，以挑战科学计算中的海量计算问题。
目前网格技术虽主要为学术机构所控制，但企业也在陆续跟进。事实上，全球网格论坛（GlobalGridForum)的主要赞助企业就包括Unilever——一家以经销肥皂、冰淇淋著称的企业。与许多正在研究和评估网格技术的企业一样，Unilever自己对于如何利用此技术仍秘而不宣。而Johnson&Johnson与Merck等制药公司、BMW与波音等制造企业却已利用这一技术的处理能力和存储空间进行仿真试验，例如药品能否保护细胞免受病毒侵袭？飞机机翼是否会在暴风雨中折断？
基因研究是网格技术的自然应用，这一领域所需的投资很难由一家企业来承担，生物科技企业可用网格技术来分析基因数据;医生可以用网格技术制作出病人器官的三维模型，作为诊断疾病的辅助手段;网格可以处理来自商店现金记录或金融市场的数据流。其他行业，如航空、保险、运输和国防，也会从中受益。如此看来，网格计算并非是可望不可及的乌托邦，其商业应用的广阔前景就在眼前。
争夺控制权
网格计算被誉为继Internet和Web之后的“第三个信息技术浪潮”，有望提供下一代分布式应用和服务，对研究和信息系统发展有着深远的影响。主要IT厂商早就为获得网格计算的控制权展开了竞争。
Sun公司日前发布了“网格引擎”企业版5.3的测试版，使企业内部的计算机网格更容易联接，提供更好的管理和资源分配。网格引擎软件提供了开放源代码版本，自2000年发布到目前为止，共被下载了1.2万次，共有11.8万个CPU利用该软件进行管理。Sun公司技术产品营销经理PeterJeffcock认为，网格计算有明显的三个阶段:群集网格、校园网格和全球网格，目前发布的GridEngine企业版5.3使Sun向功能校园网格迈进了一步。Sun还与竞争对手一起支持AVAKI与Globus等行业组织，积极参与网格计算开放标准的建立。
Microsoft的研究部门也参与了各项分布式计算研究项目，包括容错远程文件系统Farsite，以及建设分布式系统的Millenium；HP也表示将提供Coolbase软件，使用户可以通过Internet共享各种计算设备;Compaq宣布正在制定一个全球性的网格计算解决方案计划，向寻求网格计算系统的客户提供软硬件和技术支持。为此，Compaq与加拿大PlatformComputing结盟，充分利用该技术，以及CompaqTru64UnixAlpha服务器系统和运行Linux的CompaqProLiant服务器，为用户提供完整的、集成的、开放的网格解决方案。Compaq还建立了网格计算高级研究中心，继续对该技术进行研究。日本的企业在网格计算方面也跃跃欲试。NTT宣布将于2002年中期开展为期6个月的网格计算试验，参与者包括了Intel、SGI等。
今年8月，IBM宣布在网格计算领域投资40亿美元，在全球建设40家数据中心，正式进入网格计算领域。IBM被英国政府选中，负责NationalGrid(国家网格)项目，这项预算达2500万美元的网格会把8所大学的计算机相连。IBM目前正与美国的宾夕法尼亚大学合作，将数家医院联接，构建一个复杂的计算网格。参与的医院可快速利用远方的医疗数据，并共享分析程序。日前，IBM还宣布了一项名为北卡罗莱纳生物信息科学网格的项目，涉及60家企业、大学和生物医学研究公司，这是全球第一个主要由私营行业参与的网格项目。而此时距IBM进入网格计算领域仅仅3个月。看来IBM是要立志做网格技术的“领头羊”。
那么，这一项目的实施是否标志网格计算已开始进入商业应用呢？
标准是成功关键
就像TCP/IP协议是Internet的核心一样，构建网格计算也需要对标准协议和服务进行定义。目前，包括Global Grid Forum、研究模型驱动体系结构（Model Driven Architecture）的对象管理组织(OMG)、致力于网络服务与语义WWW研究的W3C,以及Globus.org等标准化团体蠢蠢欲动。
今年7月，OMG、W3C、Grid Forum等标准化组织与来自学术、商业领域的人士出席了“软件服务网格研讨会”，加快全球大网格(GGG)标准的制定。接着，另一开放源代码网格标准组织——Globus也集会研究通过广域网联接的高性能计算的基础设施问题。Globus目前正致力于开发标准的网格架构和其他技术。
迄今为止，网格计算还没有正式的标准，但在核心技术上，相关机构与企业已达成一致：由美国Argonne国家实验室与南加州大学信息科学学院(ISI)合作开发的Globus Toolkit已成为网格计算事实上的标准，包括Entropia、IBM、Microsoft、Compaq、Cray、SGI、Sun、Veridian、Fujitsu、Hitachi、NEC在内的12家计算机和软件厂商已宣布将采用Globus Toolkit。作为一种开放架构和开放标准基础设施，Globus Toolkit提供了构建网格应用所需的很多基本服务，如安全、资源发现、资源管理、数据访问等。目前所有重大的网格项目都是基于Globus Tookit提供的协议与服务建设的。
除了标准以外，安全和可管理性、IT人才的缺乏也是网格计算亟待解决的一个问题，否则将无法成为企业的商业架构。在内部系统环境中常常视而不见的问题，如安全、认证和可靠性，在任何分布式环境下都必须得到解决。研究咨询公司StencilGroup的合伙人Brent Sleeper认为:“这要求具有高层次的架构技能，而不是简历上列出的编程语言。”如果把全球的网格都联在一起，那么就能借用彼此未用的资源，网格就会更强大和灵活。虽然这也是网格的最终目标，但把网格联在一起也会带来政治问题。IBM为大学建设网格或Unilever建设内部的网格都只是单纯的IT决策，而将私有网格联接，形成能力更大的共享网格，其中的风险却大得多。在客户需要时，相互竞争的网格提供商是否愿意出售彼此多余的资源？此外，网格应用常涉及大量的数据和计算，需要在各组织间共享安全资源，这不是当前的Internet和网络基础设施所能做到的。看来在网格计算实现商业应用之前，还有很多的问题需要解决。
然而，设想一下运用前所未闻的计算能力所能完成的工作，我们都会明白，构建全球网格的前景几乎是无法抗拒的。美国Argonne国家实验室的科学家Rick Stevens指出：“就像最初的Arpanet成为Internet的中心一样，就把Teragrid看做是形成全球网格中心的雏形吧！”
网格的商业应用
生物医学：网格可提供药品开发人员所需的计算能力，用以研究药物和蛋白质分子的形态与运动。
工程：波音、福特、bmw公司都在尝试用网格计算进行复杂的仿真与设计。
数据搜集/分析：制造、石油加工、货物运输、甚至零售企业都要维护昂贵的设备，时常会出现问题，造成不好的结果。同无线传感器一样，网格能够存储和处理所有交易。
娱乐产业：特殊效果设计。
Globus Toolkit 没有提供任务调度器，也没有提供元任务调度器（meta-scheduler）。不过，有一些任务调度器已经和 Globus 集成起来了，还有一些也可以集成进来。
在网格中，任务调度与负载平衡是十分重要的功能。大多数网格系统中都包括某种任务调度软件。这种软件可以查找到某台机器的位置，并在上面执行用户提交的网格任务。有些调度器实现了按照任务优先级进行调度的系统。优先级的实现方式有时是使用多个任务队列，其中每一个队列都代表不同的优先级。当网格计算机可以执行任务的时候，就从优先级最高的队列中取出第一个任务。通过调度器还可以实现各种不同类型的策略。策略中可以包含多种对任务、用户、以及资源的约束。比如说，可能有一种策略限制在一天的某些特定时间执行网格任务。
调度器通常会对实时网格负载做出反应。它们在提交任务之前，会用反映当前机器使用情况的量测信息来确定哪些机器不忙。调度器可以组织成层次结构。比如说，元调度器将任务提交给群集调度器，或其他低层调度器，而不直接提交给独立的计算机。更高级些的调度器可以对所调度的任务的执行过程进行监视，从而对整体工作流实施管理。如果由于系统或网络的原因而导致一些任务丢失，好的调度器会自动在别的地方重新提交任务。然而，如果某个任务进入死循环，运行的时间超过了某个最大时间，那么这样的任务就不应该再重新调度了。典型情况下，各种任务具有不同类型的结束代码，其中一些结束代码适合于用于重新提交任务，而另一些则不适合。
我们通过一个预约系统可以实现在网格中提前保留资源。这种机制不仅仅是调度器。它首先是一种基于日历的系统，可以在特定的时间段内保留资源，防止其他任务在同一时间内使用该资源。它还必须能在预约的时间到达的时候将任意机器或资源上正在执行的任务删除或挂起。
在应用程序中启用网格时的考虑：调度器。当您为网格环境启用应用程序的时候，需要考虑一些与调度有关的问题。下面列出其中一些：
数据管理。意思是保证当所调度的任务运行时具备可用的数据。如果需要将数据移动到待执行的节点上，那么我们还需要对数据的移动操作也进行调度。
通信。任何相关任务的进程间通信都要求对任务进行并行调度。
调度器的作用域。在具有多个调度器（如具备元调度器）的环境中，要协调并发任务，或保证特定的任务在指定的时间执行，这些工作的复杂程度很高，当不同的调度器具有不同的作用域时，情况就更加复杂。
调度策略。调度可以有不同的实现目标。
面向应用程序——调度的优化目标是实现最佳运行时间。
面向系统——调度的优化目标是实现最大吞吐量。任务可能不会立即开始。在执行的过程中也可能被终端或抢占。也可以将任务调度为通宵执行。
网格信息服务。调度器和信息服务之间的交互可能十分复杂。比如说，如果在任务实际运行之前通过 MDS 找到了某项资源，然后，我们可以假设在任务实际运行之前该资源的状态不会发生变化。或者我们可以建立一种预测能力更强的机制，提前预测资源状态可能发生的变化，从而提前做出调度决定。
资源代理。通常情况下，资源代理必须与调度器接口。
负载平衡。负载平衡问题是由于工作负载在网格系统资源中的分散特性所引起的。尽管 Globus Toolkit 没有提供负载平衡的功能，而在某些特定环境中，负载平衡服务却是必需的特性。当作业被提交到网格任务管理器中时，工作负载可以通过推模式（push model）、拉模式（pull model）或组合模式（combined model）进行分布。推模式的简单实现是通过循环的方式将任务发送到网格资源上。然而，这个模型没有考虑到任务队列的长度。如果每一个网格资源上都发送到相同数目的任务，那么在速度较慢的机器上会形成较长的任务队列，而一个长时间运行的任务在不受到细心监视的情况下可能阻塞其他的任务，使之根本无法启动。对于这个问题，一种解决方案是使用加权循环的方案。
在拉模式中，网格资源从任务队列中获取任务。在这样的模式下，任务队列的同步化与串行化就成为协调多个网格资源的任务获取的必要手段。本地及全局任务队列的策略也是可行的。在本地拉模式策略中，每一组网格资源都指派为从一个本地任务队列获取任务。在全局拉模式策略中，所有的网格资源都被指派使用同一个任务队列。本地拉模式的优势在于能够对网格资源进行分片。比如说，离数据比较接近的，或相互有关的，或要求使用相似资源的某些任务，都可以用这种方法进行控制。
推模式和拉模式的组合模式可以解决前面提到的一些问题。每一个网格资源可以决定何时能接收更多的工作，并向网格任务服务器发送工作请求。然后，任务服务器就向其发送新的工作。
在这两种负载平衡模式下，都需要考虑故障恢复的条件。我们需要检测出哪些网格资源已经无法继续操作了，在推模式中，不能把新的工作发送给已经失效的资源。此外，无论是在推模式还是在拉模式中，我们必须细心控制所有已经提交的但尚未完成的任务。失效主机上的所有未完成任务都需要进行重新分配，或者由同一组中的其他可运行主机接管过来。
在应用程序中启用网格时的考虑：负载平衡。当您为网格环境启用应用程序的时候，还需要考虑与负载平衡有关的设计问题。应用程序设计和开发人员需要理解目前的负载平衡机制是什么样子（手工、推、拉、或是某种混合模式），这会对应用程序，特别是它的性能和运行时间产生影响。如果应用程序中具有大量独立的任务，每一个都可能受到负载平衡系统的影响或控制，那么这样的应用程序就可以从网格整体性能和吞吐量的提高当中获益，不过这个应用程序也可能需要建立更加复杂的机制，以便处理将任务延迟、或在整个网格内移动任务所带来的复杂性问题。
代理。在网格环境中，代理的职责非常重要。在很多网格环境中都可能需要实现这个组件，而实现它的方法可以相对简单，也可能十分复杂。代理的基本职责是在服务请求者和服务提供者之间提供匹配服务。在网格环境中，服务请求者可能是应用程序，也可能是被提交执行的任务。服务提供者就是网格资源。
Globus 工具箱并没有提供代理的功能。不过它通过监视与发现服务（MDS）提供了网格信息服务。您可以对 MDS 进行查询，从而发现主机、计算机和网络的属性，如当前可用处理器个数、所提供的带宽以及可用的存储类型等等。
在应用程序中启用网格时的考虑：代理。当您设计在网格环境中运行的应用程序时，很重要的一点是理解资源是如何被发现和分配的。可能需要应用程序告诉代理它的资源要求是什么，这样代理就可以保证给这个应用程序分配适当的资源。
进程间通信（IPC）网格系统中可能包含帮助任务之间相互通信的软件。比如说，应用程序可能会将自身划分为大量的子任务。这些子任务当中的每一个都是网格中的一个独立的任务。不过，应用程序的算法可能要求子任务之间相互通信，传递一些信息。这些子任务要能够定位其他特定的子任务，与之建立通信连接，并发送适当的数据。消息传递接口（Message Passing Interface，MPI）是一项开放标准，它及其若干变种经常作为网格系统的一部分来解决诸如此类的问题。
在应用程序中启用网格时的考虑：IPC。在任务之间进行进程间通信的需求总是会增加应用程序的复杂程度，因此只要有可能，您就应该将这种通信减到最少。然而，在大规模的复杂应用程序中，进程间通信通常是不可避免的。在这种情况下，您应该充分理解可用的 IPC 机制，并将失败或通信速度变慢带来的影响降到最低，这样有助于保证整个应用程序的成功。
非功能性需求
下面我们将讨论一些与基础设施有关的其他问题。这些问题被称为非功能性需求，是因为它们与网格中某项特定的功能单元没有关系，如任务管理、代理等。
性能
当您考虑在网格环境中启用应用程序时，网格的性能以及应用程序对性能的要求必须被考虑在内。服务请求者对服务的质量比较感兴趣，如可接受的运行时间等。当然了，如果您要构建一个网格及一个或多个应用程序，用来在网格中提供服务，那么服务提供者也希望能最大程度地利用网格中的功能和吞吐量。
可靠性
可靠性是计算领域内永恒的话题，网格环境也不例外。实现这一难题最好的方法是预见所有可能出现的失败情况，并提供解决这些情况的手段。最可靠的方法能够“容纳异常情况的出现”（surprise tolerant）。网格计算的基础设施必须处理主机中断和网络中断等情况。下面列出一些需要考虑的方法：
使用检查点-重启机制。
用持久性存储保存中间结果。
用心跳监视机制跟踪系统状态。
用健壮的系统管理解决方案最大程度地提高网格及其组件的可用性。
拓扑问题
网格计算的分布式本质使地理上和组织机构上的大跨度变得不可避免。随着内部网格的拓扑扩展为外部网格拓扑，复杂程度也逐渐提高。比如说，非功能性操作需求，安全性、目录服务、可靠性、性能等都变得更加复杂。让我们来研究一下拓扑的问题。
网络拓扑。网格架构内的网络拓扑可能在很多不同方面上呈现出来。网络组件可以表示 LAN 或校园网的连通性，甚至还能表示网格网络之间 WAN 的通信情况。网络的职责是为所有的网格系统提供充足的带宽。像基础设施中其他的组件一样，我们可以通过定制网络来提供更高级别的可用性、性能以及安全性。
出于安全性以及其他一些架构性的限制，网格系统从很大程度上来说是网络密集型的。尤其是数据网格，它可能在整个企业的网络内散布着一些存储资源，因此在基础设施的设计中，为了保证足够的性能，关键因素就在于处理数量巨大的网络负载。
启用应用程序时应该考虑的问题包括如何使网络通信量最小，如何使网络延迟最短。假设应用程序的设计已经能够保证最小的网络通信量，那么就有几种方法可以使网络延迟最短。比如说，千兆以太局域网可以用来支持高速群集，或实现远程网络之间的高速 Internet 骨干网。
数据拓扑。我们最希望把任务指派到距离它所使用的数据最近的机器上执行。这样可以降低网络的通信量，还可能降低可测量性方面的限制。
数据需要存储空间。在一个网格的设计中，存储的可能性问题是没有止境的。存储要求一定的安全性、要可以进行备份、要可管理，还/或要进行复制。在网格的设计中，您需要确定您的数据对于需要它的资源来说一直是可用的。除了可用性之外，您还需要保证数据得到适当的保护，因为您不能让未经授权的人访问到敏感的数据。最后，您需要最佳的数据访问性能。显然，带宽和访问数据的距离两者是相互有关的，但是您不会希望让 I/O 问题阻碍网格应用程序的运行速度。对于那些磁盘密集型的应用程序，或是数据网格而言，您可以将工作重点更多地放在存储资源上，比如您可以使用那些能够提供更高容量、冗余程度或容错机制的存储。
混合平台环境
网格环境是一组异质的主机，它们具有不同的操作系统和软件栈。为了执行应用程序，网格基础架构需要知道应用程序能够找到所匹配的网格主机环境的先决条件。您必须考虑多种不同的因素，然后才能使应用程序在类型与数量都尽可能多的环境中执行，这一点十分重要。
运行时需要考虑的问题。应用程序的运行时需求及网格主机的运行时环境必须相匹配。例如，下面列出 Java 应用程序在这方面的一些要求。用其他编程语言开发的应用程序也可能存在类似的要求。
Java 虚拟机（JVM）。用 Java 编程语言编写的应用程序要求具备 Java 虚拟机（JVM）。Java 应用程序可能对 JVM 的版本变化很敏感。为了解决这种敏感性，应用程序需要对 JVM 版本号进行识别，这是匹配的先决条件。这项先决条件的内容可能是要求某种 JVM 版本号，或是某个最小 JVM 版本号。Java 应用程序也可能对 Java 堆的大小敏感。Java 应用程序需要把最小堆容量作为先决条件。Java 包的类型，如 J2SE、或 J2EE 等，也可能是先决条件的一部分。
应用程序的跨平台可用性（可移植性）。应用程序的可执行性是与特定的平台有关的。比如说，用 C 或 C++ 语言编写的应用程序需要在目标平台上进行重新编译，然后才能运行。您可以为每一种平台重新编译一次应用程序，得到的可执行程序就标记为目标平台上的。这种做法能够增加应用程序能够运行的网格主机数目。它的局限性在于将应用程序移植到其他平台上时所花费的成本。
了解 OS 环境。网格是一组异质计算资源。如果应用程序依赖于某种特定的操作系统。那么该应用程序就需要验证网格中是否具有正确的环境，并处理环境不同所带来的问题。
输出文件格式。当一台网格主机上运行的应用程序的输出信息被另一台网格主机上运行的应用程序所访问的时候，了解输出文件的格式就显得十分必要了。这两台网格主机可能具有不同的平台环境。您可以考虑用 XML 作为数据交换的格式。XML 现在已经十分流行，它不仅仅是一种用于数据交换的标记语言，还是一种用于存储半结构化的数据格式。
当您要在网格环境中启用某个应用程序时，必须充分理解网格环境中的功能性组件和非功能性因素，如性能要求或操作系统要求等。