在本系列的,我们介绍了在Azure上进行网格计算开发的设计模式,并在,我们编写了一个欺诈评分(fraud scoring)网格计算应用程序,命名为Fraud Check。在这里,第3部分中,我们将来运行这个应用程序,首先在本地运行,接着移到云上运行。
我们使用的框架是,是Neudesic Grid Computing Framework的社区版。
在运行我们的网格应用程序之前,有几件事情需要处理——比如配置跟踪数据库和设置配置信息——不过,我们先来一睹应用程序在云中运行起来的效果图:
那么让我们来完成如下步骤的设置,以便我们能运行它。
Azure Grid为你提供了一个基础的解决方案模板,在其中你可以添加特定于应用程序的代码。上次,我们为Fraud Check网格应用程序添加了代码,不过并未讲解解决方案结构本身。现在我们就来说一说。
我们的网格计算解决方案具有云中的部分,也有企业内的部分。Azure Grid框架把所有这些都包含在一个单独的解决方案中,如下所示。那么,在解决方案中都有些什么?
要运行这个解决方案里云中和基础系统中的部分都很简单:
为了在本地测试所有功能,把AzureGrid和GridManager都设置为启动项目会很有用,那样只按一次F5就可以启动这两个应用程序。
Azure Grid在本地SQL Server或SQL Server Express数据库(2005或2008)中跟踪工作运行、任务、参数和结果。从CodePlex下载的项目源码中还包含了创建这个数据库的SQL脚本。
解决方案里云中和基础系统中的部分都需要少许配置,最重要的地方是和云存储相关的。
云中的网格执行器配置在AzureGrid项目的ServiceConfiguration.cscfg文件中设定,如下:
用于网格管理器的配置是在GridManager项目的app.config文件中设定。大部分设置都具有和云中配置文件一样的名称和含义,且需要设置为相同的值。多出的一个本地SQL Server数据库的连接字符串设置,用于网格应用程序跟踪记录。
由于网格应用程序能被极大地进行伸缩,理所当然你应该仔细地测试它们。在基于Azure的网格计算场景中,我建议按照如下顺序对这个新的网格应用程序进行测试:
1. 开发人员测试
用少量的任务在本地开发机器上测试网格应用程序。在此,你要关注的是,验证应用程序是否正确运行,正确的数据是否在网格应用程序和基础存储之间进行移动。
Grid Manager当然(也一直会)在本地机器上执行。
2. QA测试
还是在本地环境,在多个执行器机器上用大量的任务测试应用程序。这个测试的目标是验证,同样的工作在单机环境中和在利用云存储的多机环境中都能执行。
注意,由于这种方式依旧主要是一个本地测试,只是用到了Azure的云存储。在我们无法协调跨多台机器的工作的时候,这样的方式是必须的。
3. 登台(Staging)环境
把网格应用程序部署到Azure的登台环境中,用少量的任务来运行它。在这个阶段,你可以验证本地正常运行的工作是否能在云中运行。
4. 生产环境
现在,你已经准备好把应用程序推进到Azure托管生产环境的级别,用饱和的负荷来运行它。
你可以使用Azure Manager来监测网格应用程序是否正常运行。
现在我们来准备在我们的开发机器上进行本地测试。根据我们的测试计划,最初是在本地开发机器上用少量负荷进行测试。
输入数据显示在下面的这个CSV工作表,它用Excel创建并保存为CSV文件。Fraud Check应用程序需要这个输入文件的打开账号和启动GridManager.exe的账号一致。在这个测试中,我们将使用25条记录。
为了确保数据库正确设置,云中和企业中的配置都要反映到本地开发存储里。
编译应用程序,启动AzureGrid和GridManager两个项目。
AzureGrid项目不会显示任何可见的东西,不过如果你想的话可以通过开发环境UI(Developer Fabric UI)来检查它的运行情况。
GridManager应用程序是一个基于WPF的控制台,启动后如下面所示:
要在应用程序中启动一个工作(Job),从菜单选择Job > New Job。在显示出的对话框中,填写名称和描述。
点击OK按钮,你将看到工作被创建不过还未运行。工作面板显示为红色以表示工作尚未开始。
现在,我们已经准备好启动网格应用程序了。点击Start按钮,很快你就会看到工作面板变为黄色,任务的网格也显示出来。
上述显示结果将每10秒钟更新一次。不久,你将看到一些任务显示为红色,一些黄色,而一些是绿色。任务在等待的时候显示红色,被执行的时候显示黄色,当执行完成就显示绿色。
当所有任务都完成后,工作面板就显示为绿色。
在网格应用程序执行完成后,我们来检查一下结果。Fraud Check被编写为从输入电子数据表中读取输入参数,再把结果写入到输出电子数据表中。打开这个新创建的输出电子数据表,我们能看到网格应用程序为每条输入记录创建了一个评分、说明文本和批准决定。
在这个我们刚刚完成的测试运行中,我们看到一个Grid View,藉此我们能了解到网格应用程序执行的总体情况。每个小框代表一个网格任务,框中显示任务的ID。在下面的图中,你能看到一个显示了大量任务的Grid View。
除了Grid View外,你还能看到任务和结果。Grid View、Task View和Results View按钮让你可以看到网格应用程序的不同视图。
在工作运行之中或之后,你可以点击Task View按钮来查看任务的相关信息。Task View为每个任务显示一行数据,包括Task Id、Task Type和Worker机器名称。在本地运行的时候,列出的总是你自己的本地机器名称,而在云中运行的时候,你会看到负责处理每个任务的特定机器名称。
Result View类似于Task View——每个任务一行数据——不过以XML的形式为每个任务显示了输入参数和结果。你也可以拉宽这个窗体来查看完整的信息。
在看了本地机器运行的网格应用程序之后,现在让我们来在云中运行它。这要求我们修改一下配置信息以利用云存储项目而非本地开发存储;也要把AzureGrid项目部署到云托管项目中。
部署到云中的步骤和任何托管Azure应用程序类似:
1,右键点击AzureGrid项目,选择Publish。
2,在Azure门户上,访问托管Azure项目,并点击Staging下面的Deploy按钮,来上传你的应用程序包和配置文件。
3,点击Run来运行你的实例。
下一步就是准备你的输入数据。在我们的本地测试环境中,输入到应用程序的数据是一个包含25行待处理的申请信息的电子数据表。这次,我们将使用一个具有1000行的大数据。
由于云中的那部分程序已经在Azure平台里运行起来了,所以我们只需要在本地启动Grid Manager应用程序。
我们再次通过Azure Manager菜单的New Job菜单项,选择一个工作来启动。
和前面一样,我们点击OK完成对话框的录入,接着点击Start来开始工作的运行。你可以在Grid View中看到加载器生成了1000个任务。
切换到Task View,你能看到执行每个任务的云执行器的机器名称。
即使在网格应用程序完成计算之前,你就可以通过Results View开始检查结果了(之前所显示的那样)。
在工作完成之后,云存储已经被清空。由于已经没有工作可做,我们可以暂停部署到云中的应用程序,这样就避免了额外的计算花费。
一旦应用程序完成运行,期望的结果(在Fraud Check这个例子中的输出结果是一个CSV文件)也就准备妥当,行的数目正如我们所预料的(和输入数据的数目一致),每个任务都有了计算结果。
我们能看到1000行数据已经被处理了,不过记录没有保持最初的顺序。这是很正常的:我们无法控制任务执行的顺序,而且我们所关心的只是每个任务保证其的原子性。把输入参数复制到输出结果中的一个原因是,可以把输入信息和结果信息关联起来。
当前,很难估计在Azure中的网格计算应用程序的性能,由于我们还只能使用Azure的预览版【译者注:本文翻译的时候Azure已经正式商用,不过尚未在中国大陆推出,详情见。】,它提供给开发人员用于测试的实例数量只是每个项目2个。
不过有一种让你的网格计算应用程序的实例超过2个的方法,就是把网格执行器托管到多个地方。你能使用多个托管账户,可以和其他Azure账户拥有者进行合作。你也能在本地运行一些执行器。这样做可行,是因为云存储中的队列是网格执行器和企业加载器/聚合器的通信机制。只要你使用一个通用的存储项目,你就能把网格执行放置到各种各样的地方。
我们也希望网格计算应用程序业已成真的地方,能在Azure中也能成真:例如,计算密集的应用程序能通过网格计算这种方式能获得巨大的回报。
随着Azure正式发布的临近,我们应该能收集到很多关于网格计算性能和如何调优的大量有意义数据。
查看英文原文:。