浅解Facebook的服务器架构
2012-12-09 17:51:09   来源：互联网   评论：0 点击：

<作为全球最领先的社交网络，Facebook的高性能集群系统承担了海量数据的处理，它的服务器架构一直为业界众人所关注。我们使用图解的方式来浅谈Facebook的服务架构。

大体层次划分
Facebook的服务架构可从不同角度来分层次。
角度一：PHP与非PHP。即一边是PHP整的经典LAMP stack，一边是非PHP整的各种services，如下图示：

Facebook的网页创立时是扎克伯格PHP写的，到现在，都用PHP开发。后端有用各种语言开发的services。它们之间用跨语言的thrift RPC通信。（scribe也是建立在Thrift之上）。

角度二：按服务层次划分，如下图：


前端是负载均衡器（有用硬件也有用软件），负责分配前端WEB服务器，WEB服务器是用PHP来聚合数据，最后面是services,Memcached和数据库。
有意思的是对后面三种的定性：
Services：快速，复杂；自己开发的业务进程，来实现复杂的业务逻辑，速度快。百度，腾讯都是这种思路。
Memcached：快速，简单；Memcached做简单的Key-Value缓存，服务应用快速的读请求。PPLive也是这样实现的。
数据库：缓慢，持久化。数据库做持久存储，磁盘IO相对较慢，现在有SSD有改善，不过Memcached做缓存这个不是问题。

NewsFeed的架构
写操作：
Bob更新状态，Web服务器上的PHP程序除了将内容写到Mysql数据库之外，也将该行为动态的ID通过Scribe发到一个Leaf Server上（根据Bob的用户ID Hash方式选Leaf Server）

读操作：
另一个人Alice打开Facebook，加载主页，PHP程序向Aggregator服务器查询（Thrift调用），Aggregator从若干个Leaf Server里读出Alice的朋友所有行为动态/Actions的前40个，Aggregator做聚合和一定的排序，返回给PHP程序。


PHP程序获取这些行为动态的ID之后，从Memcached中读出这些ID对应的内容，如Memcached没有则从Mysql数据库中读取，汇聚后生成HTML返回给浏览器。

Chat的架构
页面请求，仍由WEB服务器(PHP)处理,当然也依赖web Tier之后的各种service,比如查看消息历史，在线用户列表，发送聊天消息等等。

接收聊天消息，则没通过PHP服务器，而是专用的用Erlang语言写的Channel服务器来处理，通过Long-polling来接收聊天消息。Channel服务器是Chat服务的核心部件。发送的消息通过Web Tier发到Channel服务器。

后方用C++写的Chatlogger服务器来做历史记录的读写。
同样也用C++写了Presence服务器来从Channel服务器汇集在线状态。
系统的简化结构如下图所示：


Web Tier，Chatlogger,Presence,Channel都是多个服务器组成的集群。
Channel服务器有根据User ID做分区，每个分区由一个高可用的Channel集群服务器。
Web Tier，Chatlogger,Presence，在公开的文章和PPT中并没有说明这些集群具体怎么做分布和冗余备份。