编者按：今天的文章，由Bill Davidheiser，iVoteSports首席设计师和创始人所写。描述了公司如何使用Windows Azure来优化它的iVoteSports MLB-focused移动游戏。

让我们从一个详单简单的想法—大多数运动（如棒球）可以细分为游戏中的游戏，开始（了解）iVoteSports.com (在苹果、安卓和亚马逊应用超市上销售)。比如每局棒球有很多有效击球，每个单独的击球员又有许多针对他的有效击球可能的结果，如进球垒、一击和本垒打。

这个游戏的基本主题是让用户预测每个事件的结果并赢取正确猜测的点数。赢到的点数是基于很多因素的，如事件结果的概率。

确定一场直播比赛的获胜者是一个挑战，因为事件的次数和概率（各不相同）。使用棒球的一个例子：每次游戏都有至少9局，每局又有6次有效击打，每次有效击打又有至少3种事件（一击、坏球等等）。因此，伴随着每个常规赛每个队162场比赛的量，有一个巨大的事件总量不可被裁判员管理，至少在我们比赛中的实际资源约束。为了解决这个问题，我们使用人群采购概念创建了一个编程方式来决定结果。

WINDOWS AZURE设计和波动系数

就像提到的，直播赛事的实质是很多人在一个相对较短的时间段（大约3小时）里聚在一起然后很快又散去。由于iVoteSports应用程序是在直播比赛时使用，它需要支持这些急剧的使用高峰。

这种类型的波动需求对一个云端应用程序来说好极了。我们的空闲状态是我们维护两个小型的（单核）Windows Azure web role实例。然而有很多玩家在用，我们（需要）可以快速添加web实例，随着需求的加强而自由伸缩。即日添加额外实例的触发点大多数是基于处理器利用率：如果我们一直超过80%我们将会添加额外实例。

在未来版本，我们将会通过管理API 以编程方式添加实例，充分利用Microsoft企业库的自由伸缩应用程序块(WASABi)，而不是现在的手动实现伸缩。当大量流行的赛事集中在某几天而需要获得增加的运算能力时我们可以主动地增加实例数。

iVoteSports的实际扩建比起一个手机游戏，更像是酷似多层企业应用程序。我们对介绍、应用程序和数据层有着完全不同的概念。

由于数据库是多租户的，用户id与所有事件（如保持分数、做出预测或者猜测一个结果）处理数据均有关系。我们的观点是UDF和存储过程开发很大程度上很像创建一个典型的.Net应用程序。由于只有用户预测和结果信息时刻保持最新的（统计信息和时间表才被存储），Windows Azure SQL Database的150GB限制不再是问题。

我们最初决定使用SQL Database很大程度上是因为创建一个优化的TSQL（可以在繁忙的日常运转中修改并且无需重新部署代码）的愿望。对于我们的下一代游戏来说，我们很可能会把我们的数据结构部分迁移到更物超所值的Windows Azure Table Storage (如果不能全部迁移的话)。

另外要注意的是，一个有很多逻辑处理在服务器端的移动应用程序有着很多好处。Web开发者钟爱于在近实时推出补丁修复bug的能力。不幸的是在移动应用程序代码中当一个bug被找到就没有时间用于修复。拿苹果来说，可能会花费多达一周的时间获取改动批准。

移动应用程序

当安全不再是游戏的主要问题时，我们实现了email地址和物理设备ID之间耦合的强制认证。如果将来需要，我们可以在某些功能上得到一个用于基于角色认证安全令牌。

所有来自移动设备的通讯都是无状态、有效同步的。每个移动设备都是一个轻量级的服务器，每秒钟都在检查是否有信息在等待。如果有信息在等待，就会有一次更为昂贵的数据交换调用。

概率和点

概率是我们游戏的重点。游戏结果的概率受关键影响力影响，如历史事件结果（飞出球比坏球更常见）、选手匹配（击跑员X比起投手Y做的更好）、选手资质（击跑员命中0.24）。当然还有其他如体育场、注射剂、天气以及选手在游戏中扮演角色的概率等因素，但是这些因素平均影响力很小，大多数适用于本地运动赌博。

混杂各种关键影响力在一起产生一个结合概率，可以让预测员将之转换为游戏结果的获胜点数。我们称之为预测一个iVote。例如，一个本垒打，Casey Jones的击球比起Joe Throwhard（的击球）会赚30点算作一个正确的iVote来说，然而，相比Casey对一个实力较弱的击球手做一个本垒打预测可能更有机会得100点。拉斯维加斯人通常称这为“point spread”。

更深层次，当很多人谈论同一场比赛，点动机可以被创建，以此鼓励非主流预测，保持iVote更为公平的分配。这一概念大概是模仿所谓的“Spread Betting”。

请注意，虽然iVoteSports.com处理很多赌博的概念，我们绝不是一款赌博应用程序。只有点数涉及，永远不会有真实资金。

统计数据远

添加当前统计信息，允许预加载击球员阵容，显示选手信息和细节，当然还有使用最新统计信息让我们的概率计算使用的是好数据，让游戏更加有趣一些。

我们从Stats.com获取两种类型的数据：日常的和赛前的。日常数据包括日程表、名册和球员统计信息，并在每个早上太平洋时间上午4点加载到我们的SQL Database。赛前数据会在每场棒球比赛开始前15分钟加载，包括每个队的开场击球员阵容和投手。

结果判定

编程判定一场事件结果却是挺困难的。当一个可信任的官方在记录每场赛事，这便不再是问题。但是正如之前提到的，使用个人官方不是我们移动应用程序的一个可伸缩的答案，因为我们一天中有很多比赛在不同时间发生。

群体设计模式对我们来说是一个极好的答案。正如许多优秀的文章和练习范例（如Truthsquad Experiment）所记载的，如果你听到足够多的人在说某件事是真的，那么他就可能是了。当然有关于“群体真理”一些注意事项，如确保（群体均为）合作者，小于临界值的人数。然而这些挑战可以减轻，整个群体数学上证明可行，对我们的目的相当有效。

如“Relation of
assertions to accuracy”图中所显示，在给定赛事中我们达到了选手临界值，我们增加断言结果会更有信心，此断言基本准确代表了结果。例如，如果我们有30%用户来自总人数说某一事件要发生（比如说一个选手三击不中出局），我们有信心超过50%确认比赛的真正结果。

大于60%的信心让我们不仅鼓励那些正确预测的人，同时惩罚那些骗人说他们ivote正确了，事实上并没有的人。

吸取的经验教训

我们对我们的整体设计很满意；尤其是我们游戏的很大部分组件运行在Windows Azure上，我们将可以快速发展至一个新的介绍平台。

我们发现Windows
Azure SQL Database查询优化过程比起常规SQL server更具有挑战。我们使用现在已停产的RedGate backup utility创建数据库的一个本地副本，然后运行SQL Profiler，吧结果送到SQL数据库优化顾问。我们通过SQL Management Studio 手动应用优化顾问的建议到我们的SQL Database。希望微软在不久的将来将会提供工具改善这些处理过程。在使用Windows Azure的开发中我们学到的主要东西就是部署。我们最初使用web role作为web部署选项，并未使用虚拟机（VM）定期重置。非永久性的web部署将会导致部署在web role VM被重新映射时还原为之塔最初状态。当重新映射时，微软不会发送通知，至少不会发送我们都知道的通知。这就会让我们的应用程序还原为之前的版本时造成混乱。

不过总的来说，我们拥有Windows Azure 非常好的体验。随着不可预测和快速的需求变化，Windows Azure将被证明是我们游戏的一个理想的操作平台。另外，开发工具给我们好的生产力和短的学习曲线。

在自然界的技术中，我们希望最终的结果是一个易于使用、富娱乐性的体育游戏。想要查看我们工作的结果，请访问www.ivotesports.com。

本文翻译自：

http://blogs.msdn.com/b/windowsazure/archive/2012/07/24/isv-guest-post-series-ivotesports-scales-its-baseball-focused-mobile-game-app-with-windows-azure.aspx