InfoQ

InfoQ

文章

我的书签

登录注册 以永久保存书签。

该内容已经被标记书签!

标记书签错误,请重试!

基于Azure云计算平台的网格计算,第2部分:开发网格应用

作者 David Pallmann 译者 朱永光 发布于 2009年10月14日

领域
语言 & 开发,
架构 & 设计,
运维 & 基础架构,
企业架构
主题
网格计算 ,
架构 ,
.NET ,
云计算
标签
微软 ,
设计模式 ,
Azure

在本系列的第1部分,我们介绍了在Azure上进行网格计算的设计模型。在这篇文章中,我们将用C#来开发一个网格应用程序以实现这个模式;而在第3部分,我们将首先在本地运行这个应用程序,接着在云中运行。为了实现这些功能,我们需要网格计算框架提供的辅助功能。

网格框架的角色

除非你准备编写大量的底层基础软件,那么应该为你的网格应用程序选用一个框架,来消除繁重的工作,让你集中精力于应用程序代码的编写。虽然Azure实现了你想在网格计算基础结构中所需的很多服务,但仍然需要在Azure和网格应用程序之间添加一些特定于网格的功能。一个优良的网格计算框架应该为你完成如下工作:

  • 提供对工作运行的计划调度和控制能力
  • 从底层存储中检索输入数据。
  • 为网格执行器生成任务以便执行
  • 把任务分发到可用的执行器
  • 在网格执行应用程序的时候跟踪任务的状态
  • 从执行器中收集结果
  • 把结果存储到底层存储中

下图显示了框架如何把网格应用程序和Azure平台结合到一起。应用程序开发人员只需编写应用程序特定的代码去加载输入数据、生成任务、执行任务和保存结果数据。这个框架提供了全部所需功能——这些功能极大地利用了Azure平台的特点。

part2-1

在本篇文章中,我们将利用Azure Grid,一个Neudesic Grid Computing Framework的社区版本。Azure Grid提供了4个软件组件,来实现列在下面的所有功能:

  • 加载器,让你可以添加自己的代码,来从底层资源中提取输入数据并生成任务。
  • 执行器角色,让你可以添加自己的代码,来执行应用程序任务。
  • 聚合器,让你可以添加自己的代码,来把结果存储回底层资源。
  • 网格管理器,让你启动工作运行,并监测它们的执行情况。

Azure Grid只在你的网格应用程序执行期间才使用云资源,使你的费用尽量最低。底层存储保存着输入数据、结果和Azure Grid的跟踪数据库。云存储用于与执行器通信过程的参数传递和结果收集,且在你的网格应用程序执行的时候把它们都清空。一旦你的网格应用程序执行完成,在空闲的时候,你也可以挂起网格执行器的运行实例,那么就无需为存储和计算时间支付持续的费用。

应用程序:Fraud Check

我们将要编码的应用程序是一个虚构的欺诈检查(fraud check)程序,使用某些规则对申请者数据进行计算,以求出欺诈可能性分数。每个申请者的记录都作为一个网格任务来进行处理 。申请者记录具有这样的结构:

part2-2

通过在申请者记录上应用业务规则,Fraud Check程序可算出一个0到1000之间的欺诈可能性分数,而0表示最坏可能的分数。如果分数低于500,那么申请可能被拒绝。

设计网格应用程序

在你设计网格应用程序的时候,你需要确定能把工作划分到可并行执行的独立任务的最好方法。你首先要考虑2个关键问题:

  • 你基于什么基础来划分工作为任务?
  • 有多少种不同类型的任务?

在Fraud Check这个例子中,为每个申请者记录创建单独的任务是很有道理的:为每个记录评出欺诈分数是一个原子操作,而且在所有的记录处理完成后,它们的顺序如何也无所谓。

对于Fraud Check而言,只需要一种任务类型,我们将其命名为“FraudScore”。FraudScore任务就是为申请者记录算出欺诈分数。

这些任务需要读取输入数据,生成结果数据。FraudScore的输入数据也即申请者记录,而结果数据则是欺骗分数加上一个文本字段来解释得到这个分数的原因。FraudScore所需的参数和返回结果,连同其名称一起显示在下面。

part2-3

在某些网格计算应用程序中,任务在完成工作的时候可能也需要访问额外的资源,比如数据库或Web Services。FraudScore没有这样的需求,不过如果需要的话,可以通过输入参数来提供必需的信息,如Web Service地址和数据库连接字符串。

开发网格应用程序

现在,我们的网格应用程序的输入参数、任务和结果字段已经定义好了,我们可以继续编写应用程序了。Azure Grid只要求我们编写加载器(Loader)、应用程序任务和聚合器(Aggregator)的代码。

编写加载器代码

加载器代码负责读取输入数据,并生成附带参数的任务。大部分时候,这些数据都来自于数据库,不过Fraud Check编写成从电子数据表中读取输入数据。

Azure Grid通过一个名为AppLoader的类,为你的加载器提供了一个可以开始编码的模板。需要实现GenerateTasks方法,来获取你的输入数据,生成带有任务类型名称和参数的任务。你的代码创建Task对象,并作为数组返回。在基类中,GridLoader,把你的任务处理为队列后放到任务执行位置的云存储中。

part2-4

为了实现Fraud Check的加载器,我们用下面的代码替换任务创建的示例代码,以从电子数据表CSV中读取记录,并为每条记录创建一个任务。

part2-5

输入的电子数据表的首行应该包含参数名称,而后面的行应该包含值,正如之前显示的那样。创建任务的过程很简单,就是初始化一个Task对象,并构造器中赋给它如下信息:

  • Project Name:你的应用程序的项目名称。这从配置文件设置中读取。
  • Job ID:工作运行的编号,一个字符串。这个值是由外部提供给GenerateTasks方法的。
  • Task ID:这个任务的唯一标识符,一个整数。
  • Task Type:要运行任务的名称。
  • Task Status:应该设置为Task.Status.Pending,以表明这是一个还未运行的任务。
  • Parameters:参数名称和值的字典集合对象。
  • Results:NULL——结果将由网格执行器在执行任务后来设置。

把Task添加到一个列表集合中,就完成了这部分工作。一旦所有的任务都生成好,把List.ToArray()作为结果传递给加载器,它就会把这些任务排队到云存储中。

编写聚合器代码

编写好加载器之后,就是聚合器,其处理任务结果,并在本地存储它们。

Azure Grid通过一个名为AppAggregator的类,为你的聚合器提供了一个可以开始编码的模板。需要实现3个方法:

  • OpenStorage,在第一个结果已经准备好可以处理的时候调用,让你有机会打开存储资源。
  • StoreResult,在每个结果需要保存的时候调用。输入参数和结果都用XML来传递。
  • CloseStorage,在最后一个结果已经保存好后调用,让你有机会关闭存储资源。

在基类中,GridAggregator处理来自云存储中的结果,并调用你的方法来存储这些结果。

part2-6

在StoreResult中,当前任务的参数和结果以如下格式的XML来传递:

part2-7

为了实现Fraud Check的聚合器,我们将完成同加载器相反的事情,即把每个结果添加到电子数据表CSV文件中。

  • 在OpenStorage中,打开一个.csv文件来接受输出,把结果写出到电子数据表CSV文件的行列中。
  • 在StoreResult中,结果(以及包含在这个上下文中的输入参数的第一个和最后一个名称)从XML里提取出来,写出到CSV文件中。
  • 在CloseStorage中,文件被关闭。

part2-8

编写应用程序任务代码

在编写好加载器和聚合器后,还有一块功能需要编写:应用程序代码本身。AppWorker类用来包含应用程序任务代码。当前任务被传递给一个名称为Execute方法,其检查任务类型,以决定执行哪些任务代码。

part2-9

对于Fraud Check,在我们的应用程序中使用switch语句来检查我们任务的类型——FraudScore,并执行代码基于在输入参数中的申请者数据来计算欺诈可能性分数。

part2-10

FraudScore代码的首要业务逻辑就是提取输入参数,在Task对象中,可以通过名称和字符串值的一个字典集合来逐一访问。

part2-11

接下来,执行一系列的业务规则算出分数。下面是一个摘录:

part2-12

最后,FraudScore更新任务的结果属性。也是简单地在字典集合中设置名称和字符串值。

part2-13

GridWorker这个基类和WorkerRole实现了把结果排队到云存储中,稍后将被聚合器取回。

准备运行

我们已经开发好了自己的网格应用程序,准备来运行它了。稍微回顾一下我们刚刚完成的事情:使用一个框架,实现了加载器、聚合器和任务代码。我们只需编写特定于应用程序的代码。

剩下的事情就是要来运行应用程序。对于网格应用程序,你应该总是仔细测试,且首先在本地用少量任务来运行。一旦你对自己的应用程序设计和代码完整性有把握了,就可以移步到云中大规模的执行了。我们将在本系列的下一篇文章(第3部分)中来讲述应用程序的运行。

关于作者

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

阅读英文原文Grid Computing on the Azure Cloud Computing Platform, Part 2


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

深度内容

大规模视频网站的计费与流量管理

本次分享将会就大规模视频网站的计费与流量管理这个话题,从操作层面细细进行讲解和分析,为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”,让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011

专访Jeffrey Richter:Windows 8是微软的重中之重

Jeffrey Richter以其多本Windows核心技术的经典著作而闻名,同时,他深入掌握微软的.NET等一系列核心技术,2012年1月,Jeffrey Richter在北京接受了InfoQ中文站的专访,谈到Windows 8和WinRT编程,并就异步编程、Windows编程中的可扩展性、性能和安全性方面给出自己的建议。

应用云平台的可用性——从新浪SAE看云平台设计

云计算平台的可用性,相比传统互联网服务而言,更加复杂和困难,也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台,以及对云计算的用户提出了建议。

JVM定制改进 @ 淘宝

淘宝高度重视Java平台的健康发展,组建了一个团队专注于Java平台的底层部分的性能、功能与稳定性改进;工作主要基于OpenJDK中的HotSpot VM开展,其中一些通用的功能随后也会逐渐反馈给OpenJDK社区。希望能与使用Java平台开发应用的大家交流经验。
本次演讲视频录制于QCon杭州2011

"伤得起"的云计算应用——对云端应用之架构的思考

2011年4月21日至22日是值得云计算从业者纪念的日子。Amazon的IaaS服务出现故障,导致许多商业网站的服务中断,影响非常严重。作为云计算用户,我们需要思考的是,如何保证即便在云服务不可用的情况,我们的应用架构仍然能够屹立不倒?本文正是站在云计算用户的角度试图探讨这一问题。

让交付的速度跟上思考的速度

12人的技术团队,4组刀片服务器,每月20亿的访问量,每日1次准时部署,99.9%的可用性。这可能吗?当然。想知道如何做的吗?百姓网将与您分享他们在DevOps实践过程中的经验和技巧。
本次演讲视频录制于QCon杭州2011

架构之路——穿行在产品和业务之间

篱笆作为一家起源于社区的电子商务公司,反映到技术层面就是同时要面对产品和业务,以及经营战略的变化调整。如何在产品和业务的夹缝之间完成技术架构的抽象与平衡,寻找更有效的价值定位,这当中有些经验教训和个人感悟愿与众人分享。
本次演讲视频录制于QCon杭州2011

特性注入:成功三部曲

本文将对特性注入以及相关方法做一个扫盲性的介绍。我们会解释这个框架的关键要素,并附上实例来证实它们。为了让文章保持相对较短,我们不会深入到某个工具或方法中,而是会给出一些参考资料,以便大家做进一步的研究。