• Home
• kafka0102的侧面照

分享：Playfish’s Social Gaming Architecture

Posted in architecture on 九月 22nd, 2010 by kafka0102

highscalability.com上的Playfish’s Social Gaming Architecture – 50 Million Monthly Users and Growing是篇很不错的大杂烩，内容涉及全球第二大socialgame公司Playfish的技术架构、产品设计、团队协作、产品运营等诸多经验之谈，尤其对初创团队很有借鉴意义。我这里还只是对文中提到的一些技术经验做些汇总，也推荐大家去浏览原文，重点看看自己感兴趣的段落。但说起架构的事情，其实看多了，往往都是大方向上相似，细节上有自己的考量和特点，以形成自己的架构风格。

SOA

SOA在企业应用中热火朝天，但在互联网应用中SOA被提及的很少。Playfish的SOA并不是使用SOA工业中的技术栈，其思想就是组件化设计。当系统变得复杂以后，松耦合的组件化是必然的趋势，系统内组件间通过约定的接口交互。对于复杂系统来说，组件间的低依赖性是很重要的，当一个组件不能正常提供服务，系统应该是优雅的降级，而不是雪崩般的集体挂掉。说起来简单，但相信很多平时跑的很健康的系统，往往只是在一个组件坏掉后，才发现系统原来并不是看起来的那样可靠。

The Cloud

从一开始，Playfish就使用Amazon的基础云服务，国外的很多初创公司都是这样做的。关于使用基础云服务的诸多优点，其实很多文章都有提到，对初创产品来说，对硬件资源的需求变动性很大，像socialgame，高峰期和平时对硬件的需求可能相差很大，如果自己搭建硬件资源，会有很大的资源浪费，而使用具有可扩展性的云服务无疑更会经济。更重要的是，不用操心于硬件资源管理，团队会更加专注于核心的服务。不过，国内使用基础云服务的似乎不多，《程序员》杂志以前倒是有过一篇介绍国内socialgame公司使用基础云的文章，但国人还是喜欢什么东西都自己掌控的好，所以能自己折腾就绝不麻烦别人。当然，Playfish并没有使用Amazon的所有云服务，比如Amazon的ELB（Elastic Load Balancing）和RDB（RationalDatabase），因为将他们的应用迁移过来无疑会很麻烦甚至危险。

Java

Playfish主要是基于Java平台的，也是得益于Java的诸多优点，比如甚是丰富的开源库，既可以用于开发Web程序也可以用于开发服务器端程序。当然，Playfish也需要花些精力对JVM做性能调优。而在数据处理分析方面，Hadoop那一套东西是必不可少的。文中提到，Playfish使用Jetty作为应用Server，窃以为可能是做嵌入式使用，如果是独立server，tomcat和resin应该是更好的选择。

Database System

数据库方面，Playfish使用的是mysql，从早期的master-slave发展到现在的shard。socialgame的特点是写多读少，所以传统的主从模式就不合适了。在shard方式，Playfish应该是基于用户id散的，所以可扩展性很强。在schema方面，Playfish将mysqlkv化了，为了加快访问速度，将和用户相关的诸多信息塞到blob类型中，这样DB的写压力被分散到后端应用上，而应用又是能很好的扩展的。所以，Playfish对mysql的使用也是nosql化了，但Playfish没有直接使用现成的nosql产品，而是使用更成熟的mysql搭建适合自己的nosql存储方式。在读多写少应用中，像memcached这样的缓存系统是必不可少的，而对写多读少的场景，Playfish有效的利用了flash客户端，使得客户端就像个memcached，写操作时即时更新客户端而不需要从服务器端再次读，而服务器端可以使用消息队列来异步写。

YAMI4 – Messaging

YAMI4是个什么东西？YAMI4是http://www.inspirel.com/yami4/，一个很轻量级的消息框架，google的结果很少，用的人似乎也不多。Playfish说是在做了很多的评估后采用了YAMI4。我粗略的浏览了YAMI4的文档，发现这个东西还是很有特点的。YAMI4支持如C++、Java、Python等多种语言，它不是一个独立的消息系统，而是一个嵌入式的消息框架（库）。消息传递有两种模式：1）是点对点的同步模式，可以使用如Thrift等RPC框架进行消息传递，但不适用于Playfish。2）是基于消息的异步模式，通常是使用如ActiveMQ等独立的消息系统（broker），但它会成为单点（当然可以花成本来去单点），并且消息的传递还要经过broker这一跳。而YAMI4是个可以嵌入producer的broker，这样消息可以点对点的传递给consumer，没有了broker的单点的困扰，并且调用可以是异步的。而对消息的数据格式，YAMI4像IDL一样提供了较友好的支持。

总结

写的匆忙，止笔于此，回头把YAMI4研究下。