65.9K
CodeProject 正在变化。 阅读更多。
Home

社交网络和 Windows Azure:从两个做得好的公司吸取的经验教训

emptyStarIconemptyStarIconemptyStarIconemptyStarIconemptyStarIcon

0/5 (0投票)

2012年8月21日

CPOL

12分钟阅读

viewsIcon

34790

从两家拥有云体验的公司那里学习社交网络经验。

Advertisement

“云”之所以成为当今的热门词汇,是有原因的。不仅基于 Web 的应用程序继续向云迁移,即可伸缩的托管平台,而且越来越多的解决方案提供商正在上线,为企业公司提供基于云的托管服务。这种丰富的云托管使得社交网络应用程序和游戏的开发人员能够构建强大、吸引人的应用程序,以满足通常不可预测的流量需求。例如,单人游戏开发者可以构建具有经济高效的后端支持的移动应用程序,这些应用程序会根据其成功程度进行扩展。而大型运营商可以推出尖端的社交营销应用程序,随时准备一夜之间走红。这就是云托管的力量和机遇。 

微软的 Windows Azure 是最早也是最受欢迎的云平台之一。作为一个可伸缩的托管平台,它为当前的 .NET 开发人员以及使用 PHP 和 Java 等其他语言的开发人员提供了一个理想的空间来启动他们的 Web 应用程序,而无需担心繁琐的运营问题。使用 Windows Azure SDK,开发人员可以将他们现有的代码库部署到他们的 Windows Azure 帐户,通常只需少量修改。

尽管如此,精明的开发人员仍会审查其应用程序的体系结构,以确保它能够利用基于云的托管的优势,同时应对其差异。对于初次接触云的人来说,一些习惯的改变可能并不显而易见。一些最大的机遇只有通过仔细而彻底地探索平台才能揭示。

幸运的是,有两家公司分享了他们在这一领域的真实经验。其中一家公司 Gestone [http://www.gestone.com] 正在推出一项新的社交网络服务。另一家公司 Thuzi [http://www.thuzi.com] 在培养其作为一家具有前瞻性思维的社交媒体营销公司的声誉的同时,自 2009 年推出 Outback Steakhouse 首次获得巨大成功的营销活动以来,一直将其微型网站建立在 Windows Azure 之上。两家公司自其社区技术预览版 (CTP) 以来一直在使用 Windows Azure,并为刚接触云的开发人员提供了许多建议。

认识 Gestone

Andy Harjanto 创立 Gestone(发音类似“guest-tone”,代表“Get Stuff Done”)是因为他想创建一个轻量级的协作系统,该系统利用现有的社交媒体,如 Facebook、Twitter、LinkedIn,为团队成员创建更自然的沟通工具。“Gestone 旨在支持团队内部的正常合作以及公司之间的联合。在 SharePoint 和 Windows NT 的旧时代,你基本上使用文件系统并允许其他人访问你的公司网络。时代已经发生了很大的变化。随着所有社交媒体的出现,公司实际上已经进驻 Facebook 和 Twitter。IT 工作者正在使用 Facebook。我们不断地接收信息流。我们如何过滤这些信息?”

Gestone 通过让项目团队成员成为其一个工作项的“CEO”,来转变项目管理模式。Gestone 为该工作项创建一个 Facebook 页面,其中包含一个标题目标、团队成员、“定时炸弹”(用于时效性任务)以及你在 Facebook 页面上已经习惯的所有社交互动。

Harjanto 表示:“Gestone 试图做的是将对你重要的事物捕捉下来,让你在一定的上下文中工作,而不仅仅是流式传输状态更新。你可以创建一个工作项,这是一个上下文。然后,你就像在 Facebook 上协作一样进行协作,带有更新和附件。我们正试图成为一个比基于文件或基于流的协作系统更现代化的协作工具。”

当 Harjanto 于 2010 年 9 月在华盛顿州贝尔维尤开始开发 Gestone 时,他有两点优势。一是他曾在微软工作 14 年,参与过 Active Directory 和 Windows Mobile 等产品,这为他编写 Windows 平台代码提供了背景知识。二是他在之前成功的创业公司 Guppers 中获得了使用 Windows Azure 作为生产平台的实践经验。这段经历让他对处理数据管理问题有了深刻的认识,这对他的新公司也很重要。

Harjanto 说,Guppers 是一家专注于商业市场的短信公司,“有点复杂”。“我们路由到 SMS、Email、Chat 网关。我们使用数据中心。数据中心的成本很高,尤其是如果你雇人的话。机器有时会崩溃。当(Windows)Azure 发布时,我们已经玩了一段时间了。在 2009 年 11 月 PDC 发布(Windows)Azure 时,微软邀请我们成为他们发布(Windows)Azure 的特色初创公司之一。当我们切换到(Windows)Azure 时,我们就知道所有数据本身都会被备份。所以我晚上可以睡得更安稳。当我开始 Gestone 时,我们使用(Windows)Azure 是毫无疑问的。”

Harjanto 使用 Visual Studio Ultimate 2010,以 Silverlight (C#) 构建其前端,同时设计后端以最大程度地适应未来平台。“我非常相信,尤其是在业务应用程序中,提供非常丰富的用户体验。我实际上希望使用 HTML 5,但它还处于早期阶段——浏览器支持还不完善。我选择 Silverlight 来提供丰富的用户体验,包括右键单击和拖放功能。我们计划在迁移到 iOS 时使用(Windows)Azure。目标是我们不改变后端任何东西,只改变前端。”

认识 Thuzi

虽然 Jim Zimmerman 是 Thuzi 的 CTO,但他更喜欢“首席开发人员”这个头衔。他是一位骨子里的程序员,是大约 25 至 30 人团队的领导者,其中一半是开发人员,一半是设计师,还有“几个销售人员”混在其中。

Thuzi 专注于社交媒体,主要是营销应用程序。与 Harjanto 一样,Zimmerman 发现拥有数据中心成本太高且不可预测,此后他已完全放弃数据中心,只保留源代码管理。“他表示,我们做的每一个应用程序或产品,都是以(Windows)Azure 为目标进行设计和构建以实现可伸缩的。我们不确定某个应用程序是否会火爆,所以很多时候我们会过度预期,这样万一它火爆了,我们也不会显得很糟糕。我们习惯于大规模可伸缩的模式。即使是小型应用程序也可以扩展到 100 万用户。一旦你习惯了这种模式,你就不想回去了。

“大约一年半前,我们首次在 CTP 中使用了(Windows)Azure。开始时,我知道我只见过一个 Facebook 应用程序火爆——当时很少有营销应用程序这样做。我知道我不想冒险 购买四台服务器,结果却是一个不起眼的应用程序。我也不知道该买多少台服务器。我可以做一些数学计算,估算每秒的请求数,但仅此而已。如果营销活动做得好,而我没有配置足够的硬件,那将是天大的麻烦。我需要一个可伸缩的解决方案。由于我是 ASP.NET MVP,我倾向于选择微软。谷歌的东西只支持 Python——我对此不感兴趣。亚马逊基本上就等于拥有自己的数据中心。微软更容易扩展,而且我不用担心虚拟机 (VM)。它更偏向应用程序思维,而其他则更偏向基础设施。”

他的第一个全功能 Windows Azure 应用程序是 Outback Steakhouse 的“Bloomin’ Onion”忠诚度营销活动 [http://www.microsoft.com/casestudies/Windows-Azure/Outback-Steakhouse/Restaurant-Chain-Outback-Steakhouse-Boosts-Guest-Loyalty-with-Social-Networking-and-Cloud-Computing/4000005861]。该营销活动的目的是奖励前五十万 Facebook“粉丝”一张免费 Bloomin’ Onion 的优惠券。经过八周的开发周期,Thuzi 于 2009 年 11 月 5 日推出了该应用程序,希望在 30 天内达到 50 万粉丝。他们用了 18 天就达到了。

经验教训:使用 Windows Azure Tables

两家公司早期学到的一个教训是,在远程数据集群上使用 SQL 会带来他们未曾预料到的新服务器动态。Zimmerman 说:“我们在 SQL 中受到了限制。起初我们不理解云是如何工作的。你在一个巨大的 SQL 集群上——大多数程序员都没有在集群上编程过。你通常只在企业应用程序中看到它们。集群的工作方式有时是它们进行负载均衡,有时会转移,有时连接字符串在其中一个服务器或另一个服务器上有效,有时它们会关闭一个 VM。”

Zimmerman 说,在云中,连接会变得断断续续,并可能在意外时间超时。“如果你在超时发生时建立数据库连接,就会出现异常。如果你没有代码来处理它,你就会得到一个看似随机的错误。这里的教训是,虽然这加强了彻底的错误处理代码的必要性,但它也极大地支持了 Windows Azure 的一个关键功能:Windows Azure Tables。”

Gestone 就是 Harjanto 所采取的方法。“我主要使用 SQL 表来存储帐户信息,但我喜欢(Windows)Azure 表。它非常、非常可伸缩。使用 SQL 时,当你有数百万笔交易时,你需要做一些连接、分区管理之类的事情。”然而,通过 Windows Azure,Harjanto 可以为每个项目映射一个表,有效地将项目相互隔离。“通过这样做,我获得了一些好处。一是安全边界。二是,如果公司想归档,我可以轻松地归档整个表,而不必担心其他项目的任何记录是否被意外包含。我可以轻松地归档整个表。

“Windows Azure 表几乎是可伸缩的。你可以添加数十亿个对象而不会降低性能,因为它们是分布式的,并且它们通过实体键/值对工作。这与 Google 或 Yahoo 相同。它们不使用传统的 SQL Server。为了实现可伸缩性,它们使用实体键/值对数据库。”

经验教训:谨慎查询

Zimmerman 也认为这个解决方案是可行的。但有一个例外。由于 Windows Azure Tables 的结构,主要是缺乏索引,他发现自己需要谨慎设计。“如果你忘记给表添加索引,然后添加了数百万行,或者你有一个有内存泄漏的老应用程序,连接未关闭,代码错误等等,你就会进行表扫描,然后被踢出(Windows)Azure 表。你会收到‘请稍后重试’的消息以及其他你没见过过的错误代码。”然而,理解这一点让他改变了设计方式,包括添加了测试了限制(“请稍后重试”消息)并指示数据层如何处理它的代码。“解决方案是正确地设计。你做的每一个查询,如果有一个 WHERE 子句,请确保它有一个索引。”

正确措辞查询是 Harjanto 成功的关键,可以这么说。“在(Windows)Azure 中,你基本上只能使用两个键。你有一个分区键和一个行键。所以如果你想进行超出行键或分区键范围的查询,那将花费很长时间,尤其是当项目非常大的时候。但是,如果你基于分区键和行键进行查询,那将非常、非常快。他们的做法是,具有相同分区键的所有内容都存储在同一个逻辑服务器上。所以对于具有该分区键的所有内容,你可以快速访问同一个服务器。因此,为了获得最佳性能,你需要特别注意设计你的表。了解你的关键场景是关键。”

经验教训:JSON 和 BLOBs

与 Windows Azure 表相结合,两家公司都找到了一个优雅的解决方案,这是其他高度可伸缩的网站都在使用的:文档存储。“Facebook 就是这样扩展的,”Zimmerman 说。“它们没有数据库,它们使用 BLOB 存储。每个用户都有自己的 JSON 数组,自己的存储文档。当你返回到站点时,它只会返回那个 JSON。你可以通过这种方式支持 1 亿用户。你所做的只是更新他们的小存储。”这样做使 Thuzi 能够构建能够应对一夜成名带来的不可预测流量的微型网站。

对 Harjanto 来说,这种相同的技术已成为 Gestone 功能的核心。“如果你看看我们的数据结构,我们存储的是层次化数据。项目有许多工作项。这些工作项主要有帖子更新,就像 Facebook 一样。团队中的每个成员都可以发表评论。在帖子更新中,你还可以(在 Gestone 中)进行文件附件。或者你可以做笔记,甚至存储一个小型数据库,比如电子表格——所有可以放在帖子更新中的快速业务小部件。它是层次化的,带有我们需要存储的对象。所以(Windows)Azure 表非常完美。(Windows)Azure 表不存储 blob 文件,只存储键/值对。我们存储所有这些东西的方式是,我们将它们序列化为 JSON 格式,一个长字符串。这个长字符串会随着帖子更新一起存储在表中。例如,在 PowerPoint 文件的情况下,我在帖子更新期间创建一个 JSON 字符串,该字符串实际上是对(Windows)Azure BLOB 的引用。我们可以通过这种方式实现大量的版本控制——如果两个人更新文件,我们会保留两个文件。”

摘要

Gestone 的 Andy Harjanto 和 Thuzi 的 Jim Zimmerman 都学到了最重要的一点:Windows Azure 提供了一个高度可伸缩、多功能的平台,可以在其上构建数据密集型且通常不可预测的应用程序。总而言之,以下是开发人员可以将其应用于自己的 Windows Azure 项目的关键要点:

  • 当流量不可预测且可伸缩性是问题时,请选择云平台,特别是 **Windows Azure** [http://www.microsoft.com/windowsazure/windowsazure]
  • 充分利用 **Windows Azure Tables** [http://msdn.microsoft.com/en-us/library/dd179423.aspx]。
  • 确保你的 **错误处理** 考虑到典型的云行为,例如负载均衡和可能的连接超时。
  • 在你的 **WHERE** 子句中包含索引,并包括 **分区键和行键**。

有关这两家公司及其在 Windows Azure 上所做工作的更多信息,请查看以下内容。

© . All rights reserved.