Friends For Sale

官方命名:
　　Friends For Sale!
　　中文译名:
　　好友买卖
　　朋友买卖
　　
　　在朋友买卖插件出现的短短三个月时间内，朋友买卖成为facebook前十名的应用，它每秒钟处理200个请求，每月产生300 000 000个page view。在技术上，选择了Ruby on Rails框架，两个兼职程序员，一打服务器，和优秀的架构。
　　
应用架构:

　　l Ruby on Rails
　　l CentOS 5(64bit)
　　l Capistrano 升级和重启应用服务器
　　l Memcached
　　l Mysql
　　l Nginx
　　l Starling 分布式队列服务
　　l Softlayer 堡垒主机
　　l Pingdom 站点监视器
　　l LVM 逻辑卷管理器
　　l Dr.Nics Magic Multi-Connections Gem 数据库读写分离
　　
当前情况:

　　l Facebook十大热门应用
　　l 将近600 000活跃用户
　　l 每天500000独立用户访问量并保持持续增长
　　l 300 000 000 page view 每月
　　l 每月300％的稳定增长率
　　l 上个月2100 000 000的独立用户
　　l 每秒处理200次请求
　　l 每月5TB的流量
　　l 两个兼职开发者（目前一个全职），一个远程DBA支持
　　l 4台数据库服务器，6台应用服务器，a staging server, a front end server
　　六台 4核 8G内存 应用服务器
　　每个应用服务器建立16个mongrels一共是96个mongrels
　　
系统设计目标：

　　支撑facebook应用－买卖朋友。
　　它基于一个波动的金融市场。
　　目前它是facebook排名前十的热门应用。
　　Tips：像买卖宠物一样买卖好友！你可以玩弄他，送礼物，或者用来炫耀。精明的投资者会把他的朋友发展成人们的货物，其实这只是满足
　　
F&Q答问

　　为什么做这个系统：
　　做这个系统更多的是为了测试和了解facebook这个系统
　　设计系统的时候，在设计，架构和实现方面有什么挑战和创新？
　　因为作为facebook的应用，每个请求都不能使用缓存页面，因此，它是一个时实行，并且写操作频繁的系统，对数据库优化要求比较高。
　　如何应付这些挑战？
　　我们采用memcached作为中间层，每个请求都不直接访问数据库。使用Rail's fragment caching缓存表现层。
　　系统目前是什么规模？
　　昨日访问量是500 000个独立用户并且访问量一直在增长。根据统计反馈，本月有 300 000 000 的page view。
　　带宽使用状况
　　上月产生了3T的流量，这月最少5T，内容仅仅是一些图标和xhtml/css。
　　文件数目，图片数目，和数据情况
　　没有文件，有10 000 000用户信息。只有少量图片。
　　增长率？
　　Page view由平均3M 每天增长到一个月前的10M每天，之前一个月1M，因此平均300％的月增长率，平均每秒处理200个访问。
　　用户需要付费么？
　　全部免费
　　用户增长率
　　平均1％，并且以每天3％的速度增长。
　　上月有多少用户活动了？
　　通过google的统计，上月有2 100 000 独立用户访问。
　　系统架构如何做？
　　首先它构建于非常稳定的Rails集群，而且使用nginx软件运行负载均衡和静态内容的服务。6个应用服务器使用4核CPU8G内存。每个应用服务器运行16个mongrels，一共有96个mongrels。负载均衡直接转向 mongrels ports。还有，一个4G的memcache服务器，独立的一台对列服务器。
　　使用god检测进程。
　　数据层，使用两台32G内存，4核CPU，4×15K SCSI RAID 10disk 做主从。使用Dr Nic's magic multi-connection's gem产品做读写分离。
　　现在添加了更多的从属服务器可以获得更高的读效率和冗余。
　　托管商略。
　　如何规划架构
　　在应用层没有做什么，因为功能非常琐碎。在数据库方面，我们只有一个主数据库，尽可能去快速分发。垂直划分数据库提高可用性。
　　有什么独特的地方可以借鉴？
　　三个方面：
　　1、两个开发者之前都没有进行过大规模的Rails开发
　　2、我们的增长率在Rails开发史上比较少见。
　　3、几乎没有做缓存，每个请求直接用Rails处理
　　你们中间学到了什么？你们为什么成功？你们是否希望以后做其他的东西，有什么不想改变的？
　　我们知道了一个好的托管上，好的硬件，好的DBA都是非常重要的。我们曾经选择 Railsmachine，他们是一个非常不错的空间提供商但给我们很大的支持。之后几乎没有碰到过硬件上的问题，而且之用两个小时就平滑切换到了 Softlayer上。选择一个好的托管上尤其重要。
　　另一个重要的事情是可伸缩的架构一贯问题出现在数据库上。首先检查数据库，一般情况下都可以通过数据库服务器，数据库配置，查询，索引来解决。
　　开始就建立在一个好的托管商。
　　我们鉴定用Rails，因为这是免费并且可快速开发的程序，实践证明两个小伙在没有充足时间的前提下也顺利开发完成了。
　　你们的小组如何组成的？
　　我们有两个Rails程序员，包括我在内。而且招安了曾经兼职远程办公的DBA。
　　你们一共有多少钱人？
　　技术方面，两个兼职的，一个全职的，一个远程办公的DBA。
　　你们现在在哪？
　　两个全职人员依然在 SOMA area of San Francisco。
　　这些人的职责？
　　两个开发者作为创始人，我最早做前端开发和程序开发。有一些经验后我也做网管。创始人Alex非常专注于Rails开发，大部分的应用程序是他开发的。现在我主要做数据库方面的工作。
　　有什么独特的管理方法？
　　首先，找到最聪明的人，给最好的待遇，尽其所长。最好的管理是尽其所长，我用这种方法管理公司。我想我经常在这里出问题。
　　你如使一个分散的团队工作？
　　有个好的交流工具。远程办公比较痛苦，核心开发还是要在本地，一些DBA之类的事情可以远程。
　　
开发情况:

　　使用Rails，很多缓存采用Chris Wanstrath的方案，数据库连接使用Dr Nic。我们使用VIM作为编辑器。
　　开发语言
　　Ruby / Rails
　　服务器数量
　　12台服务器
　　服务器应用情况
　　4台数据库，6台应用，一台staging server，一台前端机
　　托管商
　　Softlayer
　　服务器操作系统
　　Centos 5 64bit
　　Web server
　　Nginx
　　数据库软件
　　Mysql 5.1
　　反向代理
　　Nginx
　　如何部署
　　委托Softlayer
　　存储
　　NAS备份，SCSI硬盘支撑。
　　存储容量
　　5TB
　　存储如何扩展
　　Ad-hoc。 我们不关注这块，这是我们的软肋。
　　存储服务器
　　Nope
　　如何处理session
　　数据库，memcache也许更好
　　数据库如何规划
　　目前用的主从。一主多从，使用负载均衡提高读性能。
　　如何做负载均衡
　　Nginx
　　使用何种框架和ajax类库
　　Rails
　　是否使用了消息服务
　　没
　　使用了何种分布式任务管理系统
　　Starling(队列管理)
　　如何处理广告服务
　　使用eCPM
　　是否使用了标准的API
　　Nope
　　团队有多少成员
　　两个开发
　　团队的技能情况
　　Me：前端开发，开发（Rails）。最近专注数据库和高扩展性Rails的开发。
　　Alex：应用程序开发，前端开发，程序架构设计。
　　开发环境
　　Alex使用OSX，我在ubuntu上，我们使用svn进行同步，我用vim编辑器，alex用textmate。
　　开发进度
　　逻辑层，测试驱动开发，在应用层，使用迭代开发。
　　缓存策略
　　使用memcache no TTL，手工设置过期
　　是否采用了客户端缓存机制
　　没
　　
系统管理:

　　如何保证性能
　　使用Pingdom工具进行网页性能监测。
　　服务器和网络可用性检测
　　现在我们用自己的检测工具和Softlay提供的ping检测工具。最近我们开发了 FiveRuns作为服务器监控工具。
　　如何做网络和服务器性能图标
　　没有做
　　如何测试系统
　　我们分模块测试，然后完善的部分，部署到应用服务器上。
　　如何做性能分析
　　分析每条sql语句保证效率。没有测试标准。
　　如何保证安全
　　小心
　　那些特性需要改进/保持
　　反思和批评。我们会非常谨慎得增加一些特性。
　　如何做web分析
　　使用一个成长中的检测工作做病毒检测，也使用了google analytics。
　　是否做A/B测试
　　一直在做
　　
数据中心是如何设置的:

　　
　　如何备份和回复系统
　　LVM，每周做增量备份，每日做基本备份
　　如何升级软硬件
　　现在手工来做，除非有新的应用。使用capistrano升级和重启应用服务器。
　　如何处理主数据库的升级
　　一般是先切换一个从数据库为主，升级完后再切换回来。
　　你们的发展计划
　　不是很好
　　你们有独立的运营团队么
　　希望有
　　是否使用内容分发系统
　　Nope
　　盈利模式
　　CPM，浏览多收入多。也通过虚拟货币盈利。
　　如何营销你们的产品
　　口碑。病毒传销。
　　在算法上有什么独特的地方
　　Ruby已经非常优秀。我们只需要简单应用。
　　是否在数据库中存储图片
　　没有，这样不太好
　　在前端设计上你们都做了什么
　　在事情发生之前你不知道会发生什么事情。一旦做过，你会有完备的知识去解决下个问题。
　　有什么值得关注的好事或者坏事
　　不可靠的硬件，托管商之间沟通的困难，最重要的事情是选择一个能支持你应用的托管商。（sun补充：好像他们的运维都是idc来做）。另一个重要的事情是商用硬件做一个主从设置能支撑多久，你可以轻松支撑10亿级访问。
　　系统什么时候增加新的扩展
　　没这个计划，事情来了才去计划。
　　有什么值得发扬的
　　Memcache，你可以随意切分你的架构
　　未来是否要调整架构
　　我们马上要给用户数据库分区，因为马上就会达到数据库的极限。
　　
Facebook 营销思想:

　　
　　l Facebook 成功的把社会关系网络数字化
　　l 未来社会关系很重要
　　l Facebook把飞速发展的社会关系放在了互联网上
　　l 你的应用创意可以是：社会性的，诱人的，通用的。
　　l 社会化的病毒营销
　　l 货币化
　　l 普遍具有潜力
　　l 朋友买卖是个社会，因为你可以买卖你的社会关系
　　l 因为它只是一个概念，没有压力并且有点调侃的玩，所以非常有趣
　　l 它是公平的因为每个人都是虚拟的，有价钱，而且都想变得有人缘。
　　l 每次应用都可能发展一些新的用户
　　l 从增长指数上来计算，每个人都能影响1.4个人
　　l 每个用户发出好多邀请，查看公告，阅读feed，查看用户资料，和其他的项目
　　l 每个频道都能跟踪用户点击，修改，和卸载
　　
本节收获:

　　
　　l 扩展性从开始就是facebook的一个方向，他们在一周内就做到每天1000000pv的访问量
　　l Ruby on Rails可扩展
　　l 扩展性表现在架构上，关注架构和运营
　　l 你需要个好的DBA，好的托管商，合理的硬件
　　l 利用cache和高负载的硬件，你不用去做负载的数据库优化
　　l 社会关系是真实的，它构建于facebook的用户基础上，而且有非常好的虚拟应用。
　　l 大部分问题都是数据库的，数据库服务器，数据库配置，查询，和索引。
　　l 用户依然试用VI