了解网格类型、网格计算和全球信息网格 (GIG)。本文重点介绍与利用未使用的资源以提高计算机能力相关的问题，有些问题对于独立计算机而言计算量太密集而无法解决。探索一些解决方案的示例，如监视网格规模变化、网格耦合切换以及 GIG 和面向服务的体系结构 (SOA) 测试方法。

　　引言

　　在 developerWorks 系列文章 在 Web 服务上下文中使用 SLA 中，我们将讨论如何使用服务水平协议 (SLA) 保证来保护多个 Web 服务。另一系列文章 在企业级 SOA 中使用 Web Services 将介绍如何将 SOA 整合为三维集成,以提高速度和可靠性、为多个 SOA 提供深度防御，并使用 XML 二进制优化打包（XML-binary Optimized Packaging，XOP）来加快 Web 服务应用程序的速度。在同一系列文章中，我们还探讨了负载平衡 Web 服务、在联邦部门中采用 SOA 的文化注意事项以及 SOA 中紧密耦合的 Web 服务。

　　其中每项内容都趋向于优化资源，以便在多个 SOA 中执行 Web 服务。将 SOA 服务转换为网格和网络中心样式是利用和共享网格中计算机的未使用资源的方法。

　　通过将连接应用程序和系统的 Web 服务移动到网格，您可以借助相互并行连接的多台计算机来扩展资源容量。这表示一个范式转换，即从在一个位置静态使用独立计算机的资源转换为在任何位置以并行方式动态共享多台计算机的资源。

　　在本文中，您将了解什么是网格类型、什么是网格计算以及 GIG 的目标是什么。了解网络计算的概念和结构中缺少的内容，并获取解决问题的建议。

　　网格类型（服务）

　　从服务角度看，网格计算取决于您需要使用的网格类型：专用、非专用或分布式。下面将详细介绍这些类型。

　　专用网格

　　专用网格 由用于网格的专用硬件和计算资源组成。专用网格通过网格体系结构提供了最大的控制和灵活性，因为您可以选择操作的所有方面。它是网格计算的最灵活的形式，可让您自由地选择需要使用的、最适合具体情况的拓扑和网络硬件。

　　非专用网格

　　非专用网格 使用现有计算基础设施的资源和环境。例如，当桌面或服务器计算机通常处于空闲状态时使用公司计算资源的网格为非专用网格。您对这样的环境和网络结构的控制能力较低，因为在网格中不使用计算机时您无法更改支持该计算机所使用的核心结构。您可能更多地依赖于现有的网络和基础设施，对网络决策的控制很少甚至不能控制。

　　分布式网格

　　分布式网格 由在 WAN 或 Internet 上分布的、位于任何位置（内部或外部）的计算机资源组成。事实上，您无法对网络结构进行任何控制，但是您有 能力确保分布式组件可以有效地相互通信。在这种情况下，管理的重点更多地集中在提供访问、安全（包括防火墙和身份验证）和备份解决方案，以便在发生故障时提供连接性。

　　网格计算概述

　　IBM? 曾是商业网格计算的早期倡导者和贡献者，网格计算的目的是通过虚拟化分布式计算和数据源（如处理、网络带宽和存储容量）来创建单一系统映像。同时，网络中许多计算机的资源应用于需要许多计算机处理周期或访问大量数据的单一问题。

　　网格计算是解决需要大量计算能力的问题的一种方法。您可以将其视为分布式大规模集群计算和某种形式的网络分布式并行处理。它可以是一个公司中各个地理位置的计算机工作站网络，也可以是一个公共协作（例如，对等网络计算）。

　　为了共同的目标，通过协作可以协同管理数以千计的计算机资源。因为在有未使用资源的网格中可以平衡资源负载，所以网格计算好像是负载平衡的一种极端形式。

　　网格计算需要使用软件来划分和分配程序片段，就像将一个大型系统镜像分发给数千台计算机。需要考虑的一个问题是，如果某个工作站上的一个软件片段发生故障，则其他工作站上的其他软件片段也可能发生故障。当单一片段在另一工作站上没有故障转移片段，并需要依赖于其他软件片段才能完成一个或多个网格计算任务时就会出现此问题。另一个问题是，如果不能充分利用工作站中未使用的资源可能会造成较长延迟。

　　全球信息网格

　　网格计算适合美国国防部 (DoD) 的全球信息网格远景（DoD 的系统具有异构性）。对于属于 GIG 的网格计算，有三种使用网格计算的方法：

　　计算网格：侧重于计算密集型操作的网格
　　数据网格：处理数据的数据计算系统——控制大量的分布式数据的共享和管理
　　设备网格：其中周围网格用于远程控制设备和分析产生的数据

　　美国国防部根据数据网格类型定义了 GIG 企业服务。这表示已从以系统为网络中心的网络转移到以数据为中心的网络。

　　实时决策

　　GIG 提高了对环境中需求的响应，用户可以从网格中的任何位置随需访问、共享、收集、处理、存储、传播和管理信息。

　　GIG 的目标是在以网络为中心的环境中获取信息优势，使各种系统和基于消息传递的 Web 服务能够以并行方式进行互相操作，以便解决对任何独立计算机而言计算量太密集的问题。GIG 用户可以发布和检索信息并进行实时决策，而不是依赖于多个自动信息系统应用程序提供的历史信息。

　　低延迟

　　密集型解决方案需要非常高的吞吐量和低延迟，就像 IBM WebSphere? MQ Low Latency Messaging 提供的一样。这些解决方案可以解决金融市场的高周转贸易和分析环境中涌现的大量数据。

　　为一对多的多播消息传递设计的低延迟消息传递软件可以在以太网上每秒提交大约一百万条 120 字节的消息，在 InfiniBand 上每秒提交接近三百万条 120 字节的消息，每秒提交超过八百万条更小的消息，所有这些功能都是在普通的 x86 架构的服务器上实现的。测试还表明具有非常低的延迟，在 InfiniBand 上每秒提交一万条 120 字节的消息所需延迟为 30 毫秒，在 Ethernet 上为 61 毫秒。

　　网格缺少什么

　　在携带信息的网格中，GIG 根据需要将本身“借给” SOA。这意味着网格计算现在依赖于一组开放标准和协议，其中包括用于 Web Serivces 的关键 SOA 标准。

　　将这些 Web Serivces 移动到网格时，这些标准不足以在网格级别解决资源和性能问题。在网格环境的不同领域中，我们需要比 WS-Resource 传输规范包含更多的内容；就需求而言，我们需要考虑将其用作一种方法，以存储和恢复关于网格到网格的监视和管理以及安全的一般信息。

　　问题是无论资源是否缺乏，Web 服务通常均以松散耦合方式运行。我们需要找到一些方法，以确保多个工作站中的资源位于网格中时不被浪费。要找到这些方法，应考虑网格中缺少什么，然后提供一些解决方案。

　　监视网格规模变化

　　在非网格环境中，资源量可能有从低到高的变化，反之亦然。Web 服务等待发送或接收消息时，资源可能缺乏也可能不缺乏。如果在数千个工作站都不能充分控制规模变化，则会对网格中的单系统映像造成影响，从而导致资源过载。

　　一个解决方案是开发网格监视器来监视其他工作站如何利用和共享每个工作站的未使用资源。如果系统发现没有正确地利用任何工作站上的未使用资源，则会向网格和系统管理员发送警报，这样他们可以在日志中查找详细信息以便解决问题。

　　网格切换耦合

　　关于 SOA 中的紧密耦合 Web Services 的文章讨论了如何在工作站级别通过耦合切换机制使用 Web Services。当 Web Services 收到的相应资源达到特定级别的警报时，此切换机制将从松散耦合转换为紧密耦合。在 Web Services 进行切换时，必须切换某些 WS 标准（例如，用于松散耦合的 WS-Context 切换为用于紧密耦合的 WS-Addressing）。

　　在网格级别我们可以做得更深入一些。在网格级别的资源达到特定级别时，应使用网格级别的 Web Services 将警报发送给特定的工作站，以便将某些 Web Services 从松散耦合切换为紧密耦合。如果是相反情况，则在同一计算机中已切换为紧密耦合的其他 Web 服务的资源到达特定级别时，应使用特定工作站上的 Web 将警报发送给网格。

　　GIG 和 SOA 测试方法

　　为确保 GIG 和 SOA 的功能满足预期用户的需求，需要进行全面的测试。GIG 和 SOA 企业服务的复杂性要求测试方法更为深入和全面。同时，为了跟上系统构建者期望的快速变化和较短开发生命周期，必须按时间表进行测试，范围包括从特定于计算机的功能到网格企业。

　　您需要一支由开发人员、测试人员以及系统和网格管理员组成的团队，才能使 SOA 服务成为网格和网络中心。要进行此转换，您必须提前计划在网络级别开发、迁移、测试和部署 SOA 服务的需求和职责。解决这些问题可以更容易地将 SOA 服务转换为网格。您可以使用 IBM Rational? ClearQuest?、IBM Rational Tester for SOA Quality、IBM Rational Functional Tester 和 WebSphere MQ Low Latency 在网格级别减少测试和缺陷跟踪时间并提高工作效率。

　　关于作者
　
　　Judith M. Myerson 是一位系统架构师兼工程师。她感兴趣的领域包括中间件技术、企业级系统、数据库技术、应用程序开发、网络管理、安全性以及项目管理。您可以通过 jmyerson@bellatlantic.net 与 Judith 联系。