浅谈Facebook的服务器架构

　大体层次划分

　　Facebook的架构可以从不同角度来换分层次。

　　一种是：

　　一边是PHP整的经典的LAMP stack；另外一边是非PHP整的各种service。

 

　　Facebook的页面从刚创立的时候扎克伯格写的，到现在，都用PHP开发。后端有用各种语言开发的service。它们之间用跨语言的thrift RPC通信(Scribe也是建立在Thrift之上)。

　　另外一个角度划分的层次是：

　　前面是负载局衡器(没说是用硬件的还是软件的)；负责分配前端的Web服务器，Web服务器是用PHP来聚合数据；最后面是 Services，Memcached和数据库。

　　有意思的是对后面三种的定性：

　　Services – 快速，复杂； 自己开发的业务进程，来实现复杂的业务逻辑，速度快。

　　Memchached – 快速，简单；Memchached做简单的key-value缓存，服务应用快速的读请求。

　　数据库– 缓慢，持久。数据库做持久存储，磁盘IO自然慢，不过有memcached做缓存没关系。

　　NewsFeed的架构

　　写：

　　Bob更新状态，Web服务器上的PHP程序除了将内容写到MySQL数据库之外，也将该行为动态的ID通过Scribe发到一个Leaf Server上(根据Bob的用户ID选的Leaf Server)。

　　读：

　　另一个人Alice打开Facebook，加载主页，PHP程序向Aggregator服务器查询(Thrift调用)，Aggregator从若干个Leaf Server里头读出Alice的朋友的所有行为动态/action的前四十个，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集群服务。

　　Webtier, chatlogger, presence，在公开的文章和PPT中并没说这些集群具体怎么做分布和冗余备份的。

 

Facebook优化的细节技术：

Memcached

Memcached是一款相当有名的软件。它是分布式内存缓存系统。Facebook(还有大量的网站)用它作为Web服务器和MySQL服务器之间的缓存层。经过多年，Facebook已在Memcached和其相关软件（比如，网络栈）上做了大量优化工作。

 Facebook运行着成千上万的Memcached服务器，借以及时处理TB级的缓存数据。可以这样说，Facebook拥有全球最大的Memcached设备。

 

HipHop for PHP

和运行在本地服务器上代码相比，PHP的运行速度相对较慢。HipHop把PHP代码转换成C++代码，提高编译时的性能。因为Facebook很依赖PHP来处理信息，有了HipHop，Facebook在Web服务器方面更是如虎添翼。

 HipHop诞生过程：在Facebook，一小组工程师（最初是3位）用了18个月研发而成。

 

Haystack

Haystack是Facebook高性能的图片存储/检索系统。（严格来说，Haystack是一对象存储，所以它不一定要存储图 片。）Haystack的工作量超大。Facebook上有超过2百亿张图片，每张图片以四种不同分辨率保存，所以，Facebook有超过8百亿张图片。

Haystack的作用不单是处理大量的图片，它的性能才是亮点。我们在前面已提到，Facebook每秒大概处理120万张图片，这个数据并不包括其CDN处理的图片数。这可是个惊人的数据！！！

 

BigPipe

BigPipe是Facebook开发的动态网页处理系统。为了达到最优，Facebook用它来处理每个网页的分块（也称“Pagelets”）。

比如，聊天窗口是独立检索的，新闻源也是独立检索的。这些Pagelets是可以并发检索，性能也随之提高。如此，即使网站的某部分停用或崩溃后，用户依然可以使用。

 

Cassandra

Cassandra是一个没有单点故障的分布式存储系统。它是前NoSQL运动的成员之一，现已开源（已加入Apache工程）。Facebook用它来做邮箱搜索。

除了Facebook之外，Cassandra也适用于很多其他服务，比如Digg。

 

Scribe

Scribe是个灵活多变的日志系统，Facebook把它用于多种内部用途。Scribe用途：处理Facebook级别日志，一旦有新的日志分类生成，Scribe将自动处理。（Facebook有上百个日志分类）。

 

Hadoop and Hive

Hadoop是款开源Map/Reduce框架，它可以轻松处理海量数据。Facebook用它来做数据分析。（前面就说到了，Facebook的数据量是超海量的。）Hive起源于Facebook，Hive可以使用SQL查询，让非程序员比较容易使用Hadoop。（注1: Hive是是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能，可以将sql语句转换为 MapReduce任务进行运行。）

 

Thrift

Facebook在其不同的服务中，使用了不同的语言。比如: PHP用在前端，Erlang用于聊天系统，Java和C++用于其它地方，等等。Thrift是内部开发的跨语言的框架，把不同的语言绑定在一起，使之可以相互“交流”。这就让Facebook的跨语言开发，变得比较轻松。

Facebook已把Thrift开源，Thrift支持的语言种类将更多。

Varnish

Varnish是一个HTTP加速器，担当负载均衡角色，同时也用于快速处理缓存内容。

Facebook用Varnish处理图片和用户照片，每天都要处理十亿级的请求。和Facebook其他的应用应用一样，Varnish也是开源的。

Facebook可以平稳运行，还得利于其他方面.虽然上面已经提到了一些构成Facebook系统的软件，但是处理如此庞大的系统，本身就是一项复杂的任务。所以，下面还将列出使Facebook能平稳运行的一些东西。

 

1、Web 前端是由 PHP 写的。Facebook 的 HipHop会把PHP转成 C++ 并用 g++编译，这样就可以为模板和Web逻贺业务层提供高的性能。

2、业务逻辑以Service的形式存在，其使用Thrift。这些Service根据需求的不同由PHP，C++或Java实现。

3、用Java写的Services没有用到任何一个企业级的应用服务器，但用到了Facebook自己的定制的应用服务器。看上去好像是重新发明轮子，但是这些Services只被暴露给Thrift使用（绝大所数是这样），Tomcat太重量级了，即使是Jetty也可能太过了点，其附加值对Facebook所需要的没有意义。

除了语言层面的，还有很多架构，多数是开源架构，并且有很多是Facebook根据自己的业务需求而设计的架构并使之开源的。

4、持久化使用MySQL，Memcached，Hadoop'sHbase。Memcached是一个流行的缓存，被用做MySQL缓存。

5、离线处理使用Hadoop和Hive。

6、日志，点击，订阅传输这些数据使用Sribe，使用Scibe-HDFS被记录和存储在HDFS中，因此允许使用MapReduce进行扩展分析。

7、BigPipe是他们自己制定的技术，使用管道逻辑来加快页面渲染。

8、VarnishCache用作Http代理，提升性能和效率。

9、10亿级的海量图片存储和传送，使用Haystack进行处理，这是一个由Facebook开发的专用的储存解决方案，提高了优化水平并且可以追加写。

10、Facebook消息使用自己的架构，值得注意的是这个架构是一个共享的基础架构，并且是动态集群管理的，业务逻辑和持久化被封装在称为‘Cell’的东西中，每一个Cell都是使用者的一部分，新的Cell可以自由的添加。持久花技术使用HBash来完成。

11、Fackbook消息的搜索引擎构建在HBase的一个反向索引存储上。

12、Fackbook搜索引擎的实现细节目前我还不清楚。

13、输入预搜索使用自己定制的存储器和检索逻辑。