基于 Azure 云计算平台的网格计算，第 1 部分

在这个由 3 部分组成的系列文章中，我们将看一下利用 Azure 云计算平台的网格计算。在第 1 部分中，我们将看到所涉及的设计模式以及一些有益的观点。在第 2 和第 3 部分，我们将看到一个用来展示专门为 Azure 而开发的网格计算框架的代码例子。

并不是所有人都清楚，网格计算和云计算之间的区别，所以我们先来简短解释一下两者。虽然网格计算和云计算不是同一个东西，但是它们之间有很多可协同的地方，并且共同使用它们是非常有意义的。

网格计算

网格计算就是利用工作于并行模式而非单机模式的一大批计算机来处理计算问题。这种方式有很多优点：

• 节省时间：对于单机要处理一个月的工作，在有 30 台专注于这个问题的计算机的情况下，有可能一天就完成了。历史上最大的网格计算项目，就是 SETI@home 项目，通过利用数十万台志愿计算机的能力，在 10 年的时间里就获得了 2 百万年的合计计算机处理时间。
• 节省成本：你能使用成本更低的资源来完成工作，而不是购买具有最高级别处理器和内存的大量服务器。就算，你必须购买那么多的计算资源——却可以买那些更小、更便宜的机器，它们也更容易用于其它用途。
• 可靠：网格计算系统必须预先考虑到故障，或个别计算机可用性的改变不会妨碍工作的成功完成。

并不是所有类型的工作都适合于网格计算。只有那些可以被分解为多个小任务的工作才适合，而且处理这些任务的计算机所构成的松散耦合网络可以并行运行。为了分发任务、收集结果并管理系统，有必要建立一个智能基础结构。无需感到惊讶，网格计算的早期采用者都需要去解决一些巨大的计算问题。因此，你会看到网格计算如今用于遗传学，保险统计计算，天文分析以及电影动画渲染。不过，现在有所改变：网格计算越来越关注普通的业务问题，且云计算带来的竞争也加速这方面的发展。计算任务并非要无比庞大才能从网格计算方式中获益，也不一定要计算密集的任务才适合进行网格计算。任何具有反复执行特点的任务都适于网格计算。不管你是那种需要每月处理 4 百万订单的财富 500 强企业，还是那种只需批准 1 千个信用申请的中型企业，网格计算都能为你所用。网格计算早于云计算 10 年出现，所以如今的网格计算自然而然不会使用云的方式。最通常的方式是：

• 专用机器：购买大量的计算机，专用于网格处理。
• 网络周期挪用（Cycle Stealing）：当你机构中的其他机器空闲的时候（如晚上），把它们暂用于网格处理。一台白天使用的业务工作站，晚上就可变为网格处理计算机。
• 全球周期挪用：在全世界的互联网范围内，应用周期挪用概念。SETI@home 项目就是这样工作的，其利用了超过 300000 台的活跃计算机。

云计算可以成为网格计算的另外一种实现方式，其具有很多吸引人的特点，可以根据你的业务模型提供灵活的伸缩，并已经准备好很多传统方式必须定制开发的支撑基础结构。

用于网格计算的业务应用程序

为了把网格计算带入主流，需要出现一些引人注目的业务应用程序。让我们来看一下 3 类适合于网格计算方式的业务应用程序，以及获得的巨大商业价值。第一类例子是数据挖掘。数据挖掘和其他形式的数据分析，都能识别来自业务数据中有趣的关系和模式。

• 食品店可以使用数据挖掘来研究购买模式，及在对某些商品是否进行打折上作出战略决定。
• 录像出租连锁店可以使用数据挖掘，基于顾客之前的租借记录来决定向他们推荐哪个新的录像。
• 电子商务网站可以使用数据挖掘，来实时地研究用户的导航模式，并调整要展示的商品和广告显示。

第二类例子是决策分析，就是为了作出业务决策需要执行一组向前连动的业务规则。在某些场景中，涉及复杂计算的决策需要非常快速地作出。网格的并行性可用来获得很快的响应时间，在工作量增加的时候也不会出现延误。

• 信贷机构可以使用决策引擎来计算信用评级。
• 金融机构可以使用决策引擎来快速审批贷款。
• 保险公司可以使用决策引擎来计算申请者的风险，并核定其保单费率。

第三类例子是批处理，在你偶尔需要处理突发的大量工作负荷，而内部又没有这么多的能力来处理的时候，就可借助于网格计算。

• 传真服务需要生成和递送电子传真文档。在进行传真的时候，工作负荷很巨大，而在其他时候又比较低。使用网格的方式来处理文档的生成和递送，可以避免购买那些大部分时间无用的庞大内部计算能力。
• 营销活动可能需要自动向大量的地址发送电子邮件、传真、信件或语音消息。网格的并行性让这样的发送活动在很短的时间内就同时完成，无论工作量有多少。
• 电子商务网站，需要为每个订单启动一个业务过程工作流，而在繁忙季节有可能要处理巨量的工作流实例。把网格用于订单处理工作流可以避免，用有限的本地资源来处理这些订单而出现的瓶颈和处理时间延后的情况。

这些例子描述了网格计算走出应用程序类型的限制，变为一种所有业务类型都可考虑使用的常见形式。

云计算和微软的 Azure 平台

云计算就是利用具有智能基础结构的大规模数据中心来为你提供所需的计算资源。云计算横跨应用程序托管和储存，并且提供用于通信、工作流、安全和同步的服务。云计算的优势包括如下几点：

• 按需伸缩：你需要多少容量就可以拥有多少容量，事实上没有限制。
• 根据用量收费：现用现付的商业模式就是你只需根据使用量来支付。这也不是一个长期的约定，在你用量级别改变的时候，并不会限制你。
• 无需前期投入：不用购买硬件，或维护它们，或为操作系统打补丁。基建费用被转化为运营费用。
• 更小的 IT 团队及更少的 IT 事故：诸如高可用性、可伸缩性、冗余存储和故障转移等功能都已经内置于这个平台中。

微软的云计算平台也叫 Azure，当前由 4 个主要服务领域组成：

• Windows Azure 提供了应用程序托管和存储服务。应用程序托管意味着可以“在云中”（也即在云计算数据中心中）运行类似 Web 应用程序、Web 服务或背景工作进程这样的软件。应用程序可被负载均衡，可运行你所需任意数目的实例，也可随时更改实例的数目。云存储可提供类似文件系统的 Blob 存储、队列和数据表。
• SQL Data Services 在云中提供了完整的关系数据库，具有和 SQL Server 企业产品一样的功能。
• .NET Services 提供了企业业务处理所需的功能。服务总线（Service Bus）把多个位置或组织用发布 - 订阅消息的方式在互联网之上相互连接在一起。访问控制服务（Access Control Service）为应用程序提供了企业及联合安全性。工作流服务（Workflow Service）能在云中执行工作流。
• Live Services 提供了一个虚拟桌面，跨计算机和设备的数据与 Web 应用程序的同步能力，以及实现社交网络的各种通讯和协作功能。

Azure 是一个全新的平台；在本文编写的时候，它还处于预览的阶段，有望在今年年底投入商用。

把网格计算和 Azure 云计算放到一起

Azure 被设计来支持多种应用程序类型，但没有为网格计算提供特定的特性。然而，Azure 提供了网格计算系统所需的很多功能。为了让 Azure 成为一个优秀的网格计算平台，只需运用正确的设计模式和框架来提供网格特定的功能。我们现在先来看一下设计模式，在第二部分我们将研究支持这个模式的框架。

对于这个模式，你需要注意的第一件事情是，在 Azure 云中和企业端分别存在一些软件 / 数据，以及一些基础功能。它们分别完成什么事情，以及为什么要这样安排？

• 云用来完成网格计算本身的工作。云资源的使用主要面向临时的工作，可以最小化成本。在你不运行网格计算解决方案的时候，你就不会产生费用。
• 企业作为数据的固定存储位置。它是网格运行所需的输入数据的来源，也是工作结果的最终存储位置。

在这个模式中的软件角色是：

• 网格执行器（Grid Worker）：网格执行器是一个云中的软件，能执行网格应用程序所需的任务。这个软件作为 Worker Role 以多个实例运行于云中。框架使用了交换指令安排方式，以便任何网格执行器都可执行任何被其请求的任务。网格执行器运行在一个循环中，从任务队列中读取下一个要执行的任务，接着执行任务，并把结果写入到结果队列中。当网格执行器没有队列任务要运行的时候，就发出一个关闭的请求。
• 网格管理器（Grid Manager）：网格管理器是一个企业端的软件，管理着网格计算执行的工作运行。网格管理器有 3 个组件：
  • 加载器（Loader）：加载器的工作就是，为网格执行器生成要执行的任务，来启动网格应用程序工作。加载器运行在企业端，是为了访问一些基础资源，比如为每个任务提供所需输入数据的数据库。在加载器运行的时候，生成的任务被写入到云中的任务队列（Task Queue）里。
  • 聚合器（Aggregator）：聚合器从结果队列中读取结果，把结果存储到固定位置的基础功能中。聚合器也能知晓，网格应用程序的执行是否完成。
  • 控制台（Console）：控制台是一系列管理功能，用于配置项目、启动工作运行，并在网格执行的过程中查看其状态。它也能提供一个类似在机场里显示飞行状态的视图，来显示待处理的任务和已完成的任务。

在这个模式中的数据角色是：

• 任务队列（Task Queue）：这是一个云存储中的队列，存储着任务。在企业端的加载器把它生成的任务写入到这个队列中。在云中的网格执行器从这个队列中读取任务，并执行它们。
• 结果队列（Results Queue）：这是一个云存储中的队列，存储着结果。网格执行器把每个任务的结果输出到这个队列。运行在企业端的聚合器从这个队列中读取结果，并在企业端中持久地存储它们。
• 跟踪表（Tracking Table）：这是一个企业端数据库表，跟踪着任务和它们的状态。加载器把相关记录写入到这个跟踪表中，而聚合器在收到结果的时候对其进行更新。跟踪表让控制台可以显示网格的状态，并让系统知晓网格应用程序何时完成。
• 企业数据（Enterprise Data）：企业提供了数据存储或服务，为任务提供输入数据，或接收任务的结果。这要根据各自组织和项目来特别设定；编写加载器和聚合器的代码要同这些数据存储集成在一起。

演练：创建并执行 Azure 上的网格计算应用程序

让我们来把上面讲到的东西混合到一起，并演练一下使用这个模式和适合的框架，如何从头至尾地开发并运行网格计算应用程序：

1. 网格计算应用程序需求的确立。就是要确认需要完成的任务、输入数据和结果目的。

2. 使用框架，开发人员添加自定义内容到他们的项目中：

• 网格执行器（Azure Worker Role）由一个模板来创建，并为每个任务添加实现代码。
• 加载器由一个模板来创建，并添加一些代码来实现从本地资源读取输入数据、生成任务并把它们排到任务队列中。
• 聚合器由一个模板来创建，并添加一些代码来从结果队列中接收结果，在底层数据库中存储它们。

3. 此应用程序的 Azure 项目通过 Azure 门户网站来进行托管和存储的配置。网格执行器打包并部署到云宿主中，测试后，升级为产品版本（Production）。

4. 使用网格管理器控制台，网格的工作运行在此定义和启动。加载器的运行也在此启动。

5. 加载器读取本地企业数据，生成任务，并把每个任务写入到任务队列。

6. 网格执行器项目在 Azure 门户网站中启动，其会产生网格执行器的多个实例。

7. 每个网格执行器都持续地从任务队列中接收新任务，确定任务类型，执行适当的代码，并把任务结果发送到结果队列中。Azure 队列工作的方式在此非常有用：如果执行器出错，在完成任务的过程中失败，那么任务在超时之后将重新出现在队列中，并会被其他网格执行器获得。

8. 聚合器从结果队列中读取结果，并把它们写入到本地企业存储库中。

9. 在网格执行的时候，管理员能够使用网格管理器控制台几乎实时地观察网格执行器执行任务的状态。

10. 在聚合器获知所有计划中的任务已经完成时候，它通过控制台发出一个关于这个状态的提醒。到此，网格就完成了它所有的工作，它的结果也安全地保存到企业端。

11. 通过 Azure 门户网站可以暂停网格执行器，以避免带来额外的计算时费用。云存储在所有队列被完全地读取后，已经是空的了，因而没有额外的存储费用产生。

把 Azure 用于网格计算的附加值

从技术和经济两方面来说，Azure 平台用于网格计算再好不过：

• 具有很好的成本效益：使用云托管的应用程序避免了购买用于网格计算的计算机的需要。相反，你是为网格执行器的计算时间和所用的队列存储按月支付费用。这样的设计，一旦在网格应用程序完成了处理后，就不会在计算时间和存储时间上带来进一步费用。
• 可伸缩性和灵活性：不管你希望获得很多还是很少的容量，都可满足。你的网格计算应用程序可以做到，只需要一个单独网格执行器实例这样少的资源。
• 可靠性：内建于 Azure 队列中的可靠性机制确保了所有任务都得以执行，就算网格执行器意外关闭也是如此。如果网格执行器意外关闭，那么 Azure Fabric 将会启动一个替代实例。
• 可获得协调功能：Worker Role+ 队列的机制是简单的、具有负载均衡的，也是工作很好的。使用它就避免了编写复杂协调软件的需要。
• 简单：在 Azure 上进行网格计算的模式，其核心是很简单的。角色也都是明确定义的，没有非常复杂的软件元素，需要迁移部分的数目也可尽量保持最少。

下次，我们将来看看使用 Azure 的网格计算框架，如何在代码中实现这个模式。

关于作者

David Pallmann 是 Neudesic 的咨询总监，这个公司是微软金牌合作伙伴和国家系统集成商（National Systems Integrator）。在加入 Neudesic 之前，David 在微软的 WCF 产品团队工作。他出版了 3 本技术书籍，并维护着一个经常更新的 Azure博客。他也是 Azure User Group 的发起成员。

阅读英文原文： Grid Computing on the Azure Cloud Computing Platform, Part 1 。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。