LinuxEye - Linux系统教程

LinuxEye - Linux系统教程

当前位置: 主页 > 开源资讯 >

PaaS正能量:6人团队,仅1人全职后端 支撑6000万用

时间:2013-03-07 09:45来源:CSDN 编辑:CSDN 点击:
6人团队,仅1人全职后端,可以支撑起日百万活跃用户的线上活动?SongPop用事实告诉我们,利用好PaaS这是完全可行的!而从PaaS上获益的绝不是SongPop他们一个,近日Google博客上贴出了一
6人团队,仅1人全职后端,可以支撑起日百万活跃用户的线上活动?SongPop用事实告诉我们,利用好PaaS这是完全可行的!而从PaaS上获益的绝不是SongPop他们一个,近日Google博客上贴出了一些GAE的用例,其中包括:“Angry Birds”的拥有者Ravio,Ruzzle拥有者MAG Interactive等。

相信有很多人对PaaS持谨慎态度,到底是用还是不用?而在前一阶段“ 用户指责Heroku私自修改路由机制造成高支出”这场风暴过境后,PaaS似乎变的更加让人望而却步了。然则PaaS真像这些负面所说,高投入之后却带不来应有的回报?下面就看一看那些来自PaaS的正能量,本文将以一个重点做陈述,下面来一览High Scalability上总结的 小团队PaaS成功之旅
 

SongPop

SongPop,音乐版你画我猜 游戏;于2012年5月上线,现已拥有6000万个用户,位列2012年iOS游戏下载榜第5。而今SongPop已有能力处理日百万活跃用户的线上活 动,然而问题的关键却在于SongPop的工程师团队只有6人!其中也仅有一个人在做全职的后端工作。SongPop只花了不到6个月就实现了从0到1万 每秒查询的扩展,他们把大部分的功劳归结于所使用的PaaS平台 —— Goolge App Engine。

经验总结如下:只做轻活,让PaaS去承担重的部分;当你需要扩展时,你只需要购买更多的资源和做少量的调整(当然,也可能会很多);得到的回报是可以专心于App的特色开发,并且能够以很小的团队开始。
 

SongPop的架构图解:

单一的看架构图,显然不能知晓SongPop以6人工作团队去支撑每天百万活跃用户的关键。下面来看一下SongPop问题解决策略:

学到的知识

  • Premier Support(企业技术支持服务)。看起来很像是推销员的宣传曲调?然而一旦活跃用户达到了10万,它们就会开启一个Premier Support账户,这让他们可以与一个在线工程师进行洽谈,解决宕机问题。
  • Denormalize(反规范化)。为了降低可预见的延迟,它们将几个模型中的数据汇集到一个实体中。一个很老的方法,但是却很实用。
  • Cache(缓存)。为了减少用户对游戏对手列表的查询,列表会被储存到缓存中,这同样是GAE的特性之一。这个以及反规范化操作将花费一个工程师4天左右的时间。
  • Deadlines(截止时间)。一旦某个操作的性能衰退到一个临界,是时候转换到一个更可预知的策略。
  • 复合索引。查询变的缓慢,其原因归结于大部分索引性能被占用。解决方案就是使用组合索引或者把数据整合到一个实体中,这个问题的发现来自Premier Support的帮助,同样这也是PaaS的弱点之一。
  • 轻易实现与其它服务的整合。类似Google和Amazon这样的公司都有一个相同的优势,它们一般会建立一整套的协作服务。鉴于SongPop每天需要世界范围类的处理和分配17TB的音乐和图片,Google Cloud Storage显然很适合他们,并且易于在GAE中使用。对于大数据技术,Google BigQuery更是随时就绪。这也是设计中重要的一点。
  • 位置头文件。GAE请求自动的包含了基于客户端请求IP的位置信息,SongPop使用了这个信息去为玩家匹配对手,并构建配置文件。
  • Synchronous Simulated Gameplay。SongPop使用的一个创新策略就是Synchronous Simulated Gameplay。在游戏中保障可扩展、一致性、低延迟是相当不容易的,那么SongPop是如何做到的呢?SongPop的做法是将游戏记录,然后与你 对战(就像你和其它人做的一样)。你将得到一种与玩家对战的游戏体验,但是这样工程师就避免了很多技术挑战。只需要储存声音片段和游戏结果,匹配玩家进行 游戏,然后做出响应。确实很聪明。(更多详请移足 “SongPop如何使用Google App Engine和Google Cloud Storage发展到6000万用户”

通过以上几个关键点,SongPop成功的实现了以6人工程师团队处理每日百万的在线用户。然而从Google App Engine这个PaaS服务获益绝不是SongPop一个,还有Rovio等:

几个从GAE获益的公司:

1. Ravio—— “愤怒小鸟”的拥有者。使用App Engine仅花费2周的工作就推出了游戏的网页版,使他们能够利用机会快速发展它们的业务。

2. GetAround—— TechCrunch Disrupt出品的汽车租赁服务,使用App Engine建立了一个连接汽车业主的市场,用户可以从中租借汽车。几乎无额外工作就完成了他们产品的扩展。

3. MAG Interactive—— 休闲游戏的开发者,热门游戏Ruzzle的创建者;通过App Engine对后端进行扩展,迅速的发展到500万用户,期间更“老练”的未发生任何扩展问题。

4. Nubbius—— Cloud Gate使用App Engine建立,允许律师在任何地点管理其工作流程的SaaS平台。在快速部署扩展的同时,每年成本节约更超过13万美元。

5. RedBus,在线旅行社使用Google BigQuery调度上万汽车的日程表。不到30秒就可以分析2TB的数据(在Hadoop上需要大约一天的时间),成本却不到Hadoop基础设施的20%。

总结

以上阐述的是一些从Google App Engine中获益的用例,然而从Google App Engine中获利的公司绝不止以上几个;同样可以获益的PaaS平台也绝不是Google一家所有,比如:Netflix大爱的Amazon,受广大微 软用户拥护的Azure,以及广受Rails用户喜欢、虽然前一阶段却遭受质疑的Heroku。

由此可见,完美的服务是不存在的(毕竟还存在宕机、安全这些难以攻克的问题),选择匹配自己业务类型(数据类型及程序原型等)的服务才是根本。同 样,随着PaaS平台发展的愈加成熟,各个服务的缺点会得到进一步改善,优点则会更加的突出。而经过用户与服务供应商之间的共同努力,从中获益的模式以及 途径将变的更加清晰。

转载请保留固定链接: https://linuxeye.com/news/1331.html

------分隔线----------------------------
标签:PaaS
栏目列表
推荐内容