ISV博客系列：本帖出自Fielding系统的创始人兼首席执行官

撰写Windows Azure ISV系列博客的目的是宣传来自ISV（独立软件供应商）在Windows Azure 应用程序的开发和部署过程中的一些成就。本文由Fielding 系统 的创始人兼首席执行官 Shawn Cutter所写， 描述了该公司是如何使用Windows Azure 来为其石油和天然气产业客户提供基于web的服务。

-------------------------------------------------------------------------------------------------------------

Fielding系统为大大小小的中上游石油和天然气公司提供两种强大的基于web的服务，帮助运营商精简生产活动和增加外勤业务管理、远程监控和生产分析。每个应用程序都包括一个全功能的移动版本，允许所有客户访问他们的数据并从任何现代智能手机上进行操作，包括iPhone、Android 和 Windows Phone。

FieldVisor 是一个领域自动化和数据采集应用程序，可以用于跟踪在石油和天然气生产操作中的任何动向。用户可以跟踪生产、装备、服务、处理历史、任务和许多其他方面的生产操作。FieldVisor更加侧重于以手动方式输入数据取代纸和笔等外业操作并提供稳健的分析并发出报告。ScadaVisor 监视远程设备如流量计、pump-off控制器、tanks、压缩机、PLC's、人工升降机和其他各种实时监控设备。同类之中它是唯一真正基于云计算的服务，因为它由我们自己的叫做VisorBridge的基于云计算的通信和轮询引擎所支持。

本来所有的Fielding系统应用程序都被托管在我们自己的数据中心中。这些应用程序都被升级以充分利用Windows Azure所带来的优势，并在2011年7月份完全被迁移到Windows Azure上。做迁移到云的决定是因为我们想集中精力和资源研究前沿技术而不是花大量的精力在每个应用程序的服务器、备份和网络的管理上。我们认识到通常情况下公司花费了大量的时间和资源来支持他们的业务而不是集中精神研究技术，而云计算就允许我们这样做。迁移到云还有利于通过减少过剩的服务器资源和包含在维护数据中心和主机代管的软件许可上花费的昂贵费用来大大节约成本。通过衡量云的各种选择，我们选择了Windows Azure，因为它提供给我们一个更强大的开发平台。Windows Azure比其他服务提供了更快的投入市场的速度和更好的可伸缩性，利用这一优势的同时实际上只托管了虚拟机。

迁移到Windows Azure起初只是节省了现有数据中心的机架空间、电源、备份和辅助热战主机代管的费用。然而，迁移后，随着我们扩展服务和客户群，成本一直在下降。

体系结构

FieldVisor、 FieldVisor Mobile、ScadaVisor和 ScadaVisor Mobile在Windows Azure里都以独立的带有每个客户的单租户SQL Azure 数据库的多租户web应用程序的形式存在。这些应用程序由中央的SSO管理应用程序所支持，管理所有的用户、角色、安全和一些其他应用程序配置，连同为处理警报和通知、维护客户数据库并从field设备上执行远程数据收集的多线程worker角色。

目前，我们利用了Windows Azure的几乎所有方面，包括：

• 计算实例：多个web和worker角色
• Blob 存储： Blob 存储用于站点增量升级以及使用BacPac进行SQL Azure数据库的自动备份。
• Table存储： Table用来处理集中的数据以及为计算系统记录提供性能计算数据。
• Queue存储： Queue用于事件调度、实时设备数据请求、自动通知和worker角色管理。
• SQL Azure： 所有客户应用数据都与多租户的几个核心管理数据库一���保存在单租户数据库中。
• SQL Azure报告： FieldVisor 和 ScadaVisor的报告由SQL Azure 报告所支持。客户使用Report View ASP.NET 控件选择运行报告并且有一个worker角色控制的用户定义的时间表管理着所有预定的报告。
• Caching： Caching在每个应用程序中与每个web应用程序支持的cache一起被当作session供应者。Caching也用来限制每个SQL Azure数据库的负载。

我们考虑了升级每个应用程序时使用Table Storage的多项工序。由于数据的复杂性并且需要已经存在的SQL数据库，我们决定为所有主要进程利用数据库，但为后台进程、数据插入、自动导入/导出和远程设备轮询选择依附到一个pub/sub模型上。

单点登录（SSO）/中央多线程Worker 角色

我们自定义的单点登录（SSO）服务与所有worker角色一起处理定时任务、通知、自动导入/导出和其他需要驻留在几个小实例中的进程。大多数实际工作和进程在SQL Azure中是被分成较小单元来执行的，所以这些计算实例所需要的费用比较低。

应用程序

FieldVisor 和 ScadaVisor以及它们的移动版本支持web和Odata服务，都被托管在两个中等计算实例里。我们的多租户部署过程处理rollouts和管理IIS来启动新的网站和服务。图表描述了每个应用程序的单租户数据库。

SQL Azure报告

初次将应用部署到Windows Azure上，我们必须确保SQL Server 2008 R2 Reporting Services的实例处于运行状态，处理FieldVisor 和 ScadaVisor的所有报告。从那时起，我们将所有报告迁移到SQL Azure 报告中，也是使用SQL Azure报告进行生产的第一家公司之一。

Worker Roles

Worker角色实例设计用来在多线程环境中运行，在那里每个任务处理器都有自己的线程，每个实例的单个主线程维护所有其他线程。单个主线程也具有计算实例之一的企业主线程的功能，确保有且只有一个决策者决定什么时候运行哪个实例。这个Worker角色的体系结构被构建用来填补Windows Azure不提供SQL代理或额外任务计划程序的空白来处理这些类型的计划任务。运行在这些worker角色上的进程同时提供内部的管理职能和面向客户的服务。下面是这些进程的一些例子：

• 关键设备警报处理
• 运行客户计划报告
• 内部的健康检查和报告
• 发送电子邮件和短信通知
• 包含重新检索和blob备份的数据库维护
• 为客户自动化进口和出口

主调度程序利用Windows Azure Queue向queue提交一个或一组任务。运行在多个计算实例之上的Worker线程监听各个queue并且接收并处理任务。很自然地，每个实例的多线程性使我们能够最大化每个实例的所有资源，并且还可以保留任务处理将来的无限可扩展性。Windows Azure Queues使得worker角色能够处理进入脱机状态的情况；那些任务被放回到queue中，它们可以被其他实例处理。任务的每个单元被设计成幂等的，这样一来每个消息都从queue中进行处理，工作单元本身也包含每个进程处理所需要的数据，并且当其中的一个worker消失，这个工作单元能被其他的worker拾起，所以不存在数据丢失的风险。

多租户

迁移到Windows Azure过程中，我们决定将每个应用程序转成在多租户应用模式下运行，而不是为每个客户每个应用程序单独调配。这一决定基于两个关键因素：

• 为所有客户的每个应用程序增加维护和rollout次数
• 每个客户需要大量的服务器资源

在大量使用的过程中，每个应用程序可能会占用大量的内存，如果每个客户的每个服务基本上都有自己的IIS应用程序，它会消耗甚至是一个大型实例消耗的所有内存。我们通过映射了SQL Azure连接到基于一个特定客户可用的服务和基于用户的身份的附加数据访问层处理多租户。我们当前在两个中等示例上托管核心的面向客户的服务并且随着使用越来越多负载逐渐增大，附加示例可以用来共享在一天的高峰期中处理的服务。我们使用性能计数器来监视使用性能并利用Compute API管理我们的服务。对我们的服务来说，有两个关键的计数器：CPU和内存使用情况。

我们还创建了自己的多应用程序来托管部署过程和使用worker角色监视blob存储中zip文件的变化的管理层，并且当改变被删除时更新应用程序。进程大大地降低了推出更新时管理和维护的开销。

Windows Azure Worker和Web角色大小

我们为诊断、性能单独负载测试每个应用程序，并且在完全将应用程序迁移到Windows Azure之前考虑计算实例的大小。中央SSO服务和少数的worker进程已经在两个小的计算实例上运行，并且没有任何问题和性能顾虑。可以不用理会这些进程，因为这些实例每秒请求次数很少，大部分处理都只是涉及简单、简短的突发传送，甚至是在高峰期IO和内存的使用率都很低。

针对应用程序实例，为了找到正确的配置，我们测试了几种不同的配置。测试包括记录每个应用程序的用户请求模式并在Test Studio中重复测试。主要测试的配置是2-6个小的计算实例与2-3个中等计算实例进行对比。中等实例显然需要更多的内存，并且在网络和IO能力上也有差异：

• Small: 100Mbps
• Medium: 200Mbps

在重负荷测试中负载呈指数级增长反映了这一差异。当具有6个小的计算实例的配置每秒生成50个请求时，这些请求只得排队等候并且会导致超时。中等实例轻松地通过了重负荷测试，觉得将来我们可以继续对其进行扩展而不是使用大型实例。我们还能分解中型实例使他们处理单独的服务，意味着我们从拥有4个计算共享实例到拥有两个中等实例集，每个集托管了50%的服务。

总结

对于Fielding系统来说，几乎整个Windows Azure堆栈都被利用在我们的drive中，集中全部的精力构建难以置信的可扩展的石油和天然气软件服务而不用担心服务器容量、备份和管理。在选择将所有东西都迁移到Windows Azure之前，我们也评估了其他的云计算服务。我们看到了平台即服务（PaaS）设计给我们带来的长远利益并且明白通过在一些远程的数据中心上添加和管理虚拟机所带来的优势。当我们的竞争对手花费大量的时间和资源管理他们的数据中心的时候，我们正在集中精力提升我们的核心技术：软件。我们通过更多地使用Windows Azure Caching 和 Windows Azure Service Bus来利用Windows Azure以实现不断地提高。云不只是我们卖给客户的某个东西；我们还可以像使用Office 365 和 Dynamics CRM那样在内部使用它。是它让我们走在技术的前沿。

本文翻译自：http://blogs.msdn.com/b/windowsazure/archive/2012/04/11/isv-blog-series-blog-post-by-shawn-cutter-founder-and-ceo-of-fielding-systems.aspx