Scaling Out最流行的社交游戏，FarmVille

拥有每月8735万活跃用户的Farmville是Facebook上最流行的游戏，也是因特网上最流行的web game之一。为了支持scale out，这一应用被部署在云中，广泛地使用了缓存，有能力在顶峰时期关闭一些功能，并很好的运用了性能监测和管理。

按照来自开发该游戏的Zynga公司的开发者Luke Rajlich的说法，FarmVille于2009年6月上线，4天之后就达到了100万的用户，60天内就达到了1000万。拥有每月8000万的活跃用户，FarmVille影响到了20%的Facebook用户以及超过总数1%的世界人口。要在这样短的时间内在这样的规模下scaling out，需要一定的硬件和软件解决方案。

InfoQ采访了Luke Rajlich以了解更多的架构信息。首先，这一应用运行在云中的虚拟Linux服务器上，所以它可以方便的请求和接受额外的计算资源。该应用运行在基本的LAMP栈上，这里的P指的是PHP。该应用广泛的使用了缓存：

基于上来说我们的应用是面向对象的，MVC应用，有一个定制的DB/Cache接口。我们对于缓存相当依赖，特别是memcache，用以支持我们的负载。同时，我们也有水平分区(shard)的数据库。

为了应付峰值的流量，这一应用依赖于在短时间内增加额外的容量：

从架构上来说，我们能够快速的增加容量，因为应用的负载可以被划分到任意的层次(负载均衡，web服务器，memcache，数据库)。同时，我们对于在任意层次增加容量有专门的形式化的程序。因此，增加容量的操作很容易管理并且能快速的执行。同时我们运行于虚拟的环境之上，因此我们可以快速的增加容量而不用预备额外的硬件资源，这一点非常明显的减少了从我们决定增加容量到我们实际增加所必需的硬件资源之间的时间。我们逐步的采用了配置工具，比如puppet，以此减少了增加额外硬件所需要的开销。剩下的困难的部分首先在于如何知道和发现应用的哪一部分会破坏性能。为了顾及这一考虑，我们对于前面所提的服务降级投入了许多时间，同时还花费了大量的精力投入到应用性能的监控上面。

这一游戏有好些个部件，当性能成为瓶颈的时候“我们可以有效的关闭在平台上使用的不太重要的功能”，以此缓解对应用的需求：

还有好些个其它的组件[在游戏本身以外]，比如朋友阶梯，送礼请求，等等。我们可以将这些元素从游戏本身剥去，因为游戏本身的基本部分不会受到这些组件性能的影响。这是至关重要的，因为我们的游戏主要是一个基于时间的游戏，用户在特定的时间回到游戏执行特定的操作。如果我们存在宕机时间这些特定的操作将会产生巨大的用户体验的影响，因此我们想要避免产生这种情况。

这一应用的读写比例高达3:1，他们广泛地使用缓存来处理它，在跟Todd Hoff的采访中Rajlich揭示了其中的奥秘：

用户的状态包含了大量的数据，这些数据具有微妙而复杂的关系。举例来说，在一个农场中，物体相互之间不能冲突，所以如果一个用户在农场上建了一所房子，在后台需要检查在用户的农场不会有其它的物体占据了重叠的空间。与其它的大部分的主要是读操作的主流网站，比如Google或Facebook不同的是，FarmVille有着相当重的写操作负载。数据读写的比例是3:1，这是一个高得惊人的写比重。FarmVille后端最主要的请求之一就是一些更改玩游戏的用户状态的请求，为了增强伸缩性，我们致力于使我们的应用主要与缓存部件交互。

FarmVille与Facebook平台之间的顶峰流量达到了3GB/s，所以客户端应用程序需要关闭一些对平台的请求来避免阻塞通信链接：

FarmVille与Facebook平台之间的流量是巨大的：在顶峰时刻，两者之间的流量基本达到3GB/s，同时在缓存集群和应用程序之间又有1.5GB/s的流量。此外，因为性能可以差异较大，应用程序具有动态的关闭任何到后台调用的能力。我们可以拨号进行微调，以关闭迅速增加的更多的对于后端平台的调用。此外我们还使得所有到后台的调用都避免阻塞应用本身的加载。这里的思想是，就算所有其它的都失效了，玩家至少仍可以玩游戏。

对于性能监控和管理“我们使用了nagios来警报，munin来监控，以及puppet来做配置。我们极大地利用了系统内部状态来追踪程序所使用的服务的性能，比如Facebook，DB，以及Memcache。此外，当我们发现性能降低的时候，我们基于样本来调节一个请求的IO事件。”

附注一下，根据根据Inside Social Games分析师Justin Smith的说法，FarmVille背后的公司Zynga，去年获得了4.9亿美元的收入，今年有望超过8.35亿。

查看英文原文：Scaling Out the Most Popular Social Game, FarmVille