旧的 NFS 照片架构

老的照片系统架构分以下几个层：

1. 上传层接收用户上传的照片并保存在 NFS 存储层。
2. 照片服务层接收 HTTP 请求并从 NFS 存储层输出照片。
3. NFS存储层建立在商业存储系统之上。

因为每张照片都以文件形式单独存储，这样庞大的照片量导致非常庞大的元数据规模，超过了 NFS 存储层的缓存上限，导致每次请求上传都包含多次I/O操作。庞大的元数据成为整个照片架构的瓶颈。这就是为什么 Facebook 主要依赖 CDN 的原因。为了解决这些问题，他们做了两项优化：

因为每张照片都以文件形式单独存储，大量为目录及文件在NFS 存储层上产生了大量的元数据， 这个规模的元数据量远远超过了超过了NFS 存储层的缓存上限，导致每次招聘请求会上传都包含多次I/O操作。庞大的元数据成为整个照片架构的瓶颈。这就是为什么 Facebook主要依赖 CDN 的原因。为了解决这些问题，他们做了两项优化：

• Cachr: 一个缓存服务器，缓存 Facebook 的小尺寸用户资料照片。
• NFS文件句柄缓存：部署在照片输出层，以降低 NFS 存储层的元数据开销。

新的 Haystack 照片架构

新的照片架构将输出层和存储层合并为一个物理层，建立在一个基于HTTP 的照片服务器上，照片存储在一个叫做haystack 的对象库，以消除照片读取操作中不必要的元数据开销。新架构中，I/O 操作只针对真正的照片数据（而不是文件系统元数据）。haystack 可以细分为以下几个功能层：

• HTTP 服务器
• 照片存储
• Haystack 对象存储
• 文件系统
• 存储空间

在下面的介绍中，我们会对于上述的每个功能层做详细的讲述。

存储空间

Haystack 部署在商业存储刀片服务器上，典型配置为一个2U的服务器，包含：

• 两个4核CPU
• 16GB – 32GB 内存
• 硬件 RAID，含256-512M NVRAM 高速缓存
• 超过12个1TB SATA 硬盘

每个刀片服务器提供大约10TB的存储能力，使用了硬件 RAID-6, RAID 6在保持低成本的基础上实现了很好的性能和冗余。不佳的写性能可以通过RAID控制器和NVRAM缓存回写解决，写由于读取大多是随机的，NVRAM缓存是完全用于写入的。

文件系统

Haystack 对象库是建立在10TB容量的单一文件系统之上。

图片读取请求需要在读取系统调用这些文件的位置偏移，但是为了执行读取操作，文件系统必须先找到实际物理卷上的数据。文件系统中的每个文件都被一个叫做inode结构标识。inode包含了一个磁盘上逻辑文件偏移和物理区块偏移的映射。在使用的特殊类型文件系统时大文件块映射可能相当大。

基于文件系统的区块为给个逻辑区块和大文件保存映射。这些信息通常不适合保存在inode的缓存中，而是存储在在间接地址块。所以在读取文件的时候必须按照特定的流程。这里可以多个是间接地址块，所以一个读取会产生多个I/O取决于是否间接地址块被缓存。

该系统只为连续范围的区块保持映射。一个连续的大文件的块映射可以只由一个范围的标识，这样是适应inode的系统需求的。但是，如果该文件是一个被切割的不连续的块的话，他的块地图可能非常的大。以上可以通过文件系统主动为大的物理文件分配大块的空间来减少碎片。

目前使用的文件系统为XFS，一个很大程度提供高效的文件预分配系统。

Haystack 对象存储

Haystack 是一个简单的日志结构（只能追加），存储着其内部数据对象的指针。一个 Haystack 包括两个文件，包括指针和索引。下面的图片将描述haystack存储文件的布局：

haystack最前面的8K存储是被超级块占用。紧随超级块是针，每针组成的一个头部，数据和尾部：

一个针被他的<offset key=”" alternate=”" cookie=”">元组标识，其中的偏移量为其在haystack存储的偏移。Haystack不在任何健值上做限制，即允许可以有重复键针。下图显示了索引文件的布局：

在haystack存储文件中有每针相应的的索引记录，并且包含针索引记录的顺序必须和haystack存储文件相关的针的顺序相匹配。按照规定索引文件的最低需求是找到一个特定的针在haystack存储文件的元数据。载入和组织索引记录到一个有效的查找数据结构是Haystack程序的责任。索引文件是不是很关键，因为如果需要它可以从haystack存储文件重建。索引的主要职责是让针元数据无需通过较大的Haystack存储文件，快速加载到内存中。原因是其可以让索引编程原来存储的1%。

Haystack 写操作

Haystack 写操作同步将指针追加到 haystack 存储文件，当指针积累到一定程度，就会生成索引写到索引文件。由于索引文件是不是很关键，为了能有更快的性能所以采用异步的方式进行写入。

为了降低硬件故障带来的损失，索引文件还会定期写到存储空间中。在崩溃或突然断电的情况下，将haystack恢复处理器存储中任何残缺的针和截断haystack存储中最后一个有效的针。接下来，它会把丢失的针的索引记录 写到haystack文件的最后。

Haystack不允许重写现有的针偏移，如果一个针数据需要被重写，那么新版本必须使用相同的<key alternate=”" key=”" cookie=”">元组。应用程序会自动分辨出这两个相同的键，有最大偏移的便是最新的那一个。

Haystack 读操作

传到 haystack 读操作的参数包括指针的偏移量，健，备用键，Cookie 以及数据大小。Haystack为数据大小添加头部和尾部的长度，然后根据数据尺寸从文件中读取整个指针。读取操作成功的关键就是作为参数传递的健，备用键，Cookie是否匹配，数据是否通过了校验，并且针没有被删除掉。（见下文）

Haystack 删除操作

删除操作比较简单 – 只需要在 Haystack 存储的指针字段中的“删除”位标记一下即可。并且，相关的索引记录不会做任何的修改。是最终的应用程序引用到的是一个删除的针。像这样一个读取删除针的操作将会返回一个相应的错误给应用程序。空间对已删除的针不做任何的回收，只有这样，才能使 haystack 的空间非常的紧凑。（见下文）

照片存储服务器

照片存储服务器负责接受 HTTP 请求，并转换成相应的 Haystack 操作。为了尽量减少服务器检索照片时的I/O操作，该服务器维护着全部 Haystack 中文件索引的缓存。服务器启动时，系统就会将这些索引读到缓存中。由于每个节点都有数百万张照片，必须保证索引的容量不会超过服务器的物理内存。在内存中仅需要保存查找照片所需的少量元数据即可。

对于用户上传的图片，系统分配一个64位的独立ID，照片接着被缩放成4种不同尺寸，每种尺寸的图像拥有相同的随机 Cookie 和64位的密钥，图片尺寸描述（大，中，小，缩略图）被存在代用key 中。接着上传服务器通知照片存储服务器将这些资料连同图片存储到 haystack 中。

每张图片的索引缓存包含以下数据：

由于Google的开源 sparse hash data 结构对于每个条目只有2bit的开销，所以Haystack使用它来保证内存中的索引缓存尽可能小。

照片存 储的写/修改操作

写操作将照片数据写到 Haystack 存储并更新内存中的索引。如果该索引记录中包含了相同的键，那么这是一次对现有的照片进行修改的操作。并且只要修改索引记录中的偏移来反应新图像在haystack存储文件的位置。照片存储始终假定，如果有重复的图像（图像具有相同的键），有较大的偏移量的那个存储是有效的。

照片存储的读操作

传递给一个读操作的参包括Haystack ID，照片的 Key, 尺寸以及 Cookie。服务器事先在缓存中按照照片的Key和所需文件的偏移进行查找。如果找到了它，并向haystack发出读取词图像的请求。按照上面说的，haystack的删除操作并不更新它的索引记录，因此添加到内存中的索引可以包含以前删除的照片的内容。当阅读以前的删除的照片失败后，系统将在内存的索引中色绘制词图片的偏移量为0.

照片存储的删除操作

通知 Haystack 执行删除操作之后，内存中的索引缓存会被更新，将偏移量设置为0，表示照片已被删除。

重新整理（压缩）

重新整理（压缩）是一种回收删除和重复的针（针使用相同的Key）的在线操作。它会通过复制针跳过任何重复或删除的条目创建一个新的 haystack。一旦此操作完成它就回去替换掉内存中的文件和结构。

HTTP 服务器

Http 框架使用的是简单的基于开源的libevent库的 evhttp 服务器。使用多线程，每个线程都可以单独处理一个 HTTP 请求。因为我们的系统消耗大多是I/O操作，HTTP服务器的性能并不很重要。

结束语

Haystack 是一个基于 HTTP 的对象存储，包含指向实体数据的指针，该架构消除了文件系统元数据的开销，并实现将全部索引直接存储到缓存，以最小的 I/O 操作实现对照片的存储和读取。

本文作者为Facebook的工程师Peter Vajgel, Doug Beaver 和 Jason Sobel， 由标点符进行翻译。

原文链接（E文）：http://www.facebook.com/note.php?note_id=76191543919&ref=mf

Related posts:

1. Facebook XHP:让PHP成为模板引擎
2. Facebook HipHop 源代码发布
3. StartSSL免费的HTTPS证书颁发机构

Facebook 的产品设计五维

情感

1. 精准定位——设计对受众定位清晰，符合该设计目标用户群的使用体验。
2. 亲和力——所有交互元素的设计上，用户对信息沟通顺畅，感觉似有人一般的亲和感。
3. 分享——承载对Facebook连接、自由、生活的文化认同。
4. 留恋度——给人超出想象的空间，让人留恋往返，对产品期待更多，得到二次访问。

易用

1. 反馈及时——在交互过程中，用户的操作能够在屏幕上及时得到反馈效果，帮助用户提高效率。
2. 方位清晰——清晰的知道自己在那里，退路在那里，能够去那里。
3. 路径简短——完成任务在尽可能控制在三步之内，完成某项任务所花废的步骤和时间最短最好。
4. 容错性好——设计限制因素，突出正确操作，隐藏可能的错误操作，减少勿操作。

形美

1. 文字悦读——信息传达易读，符合中文阅读习惯，信息传达快速。
2. 颜色合适——利用大众对颜色理解的寓意，使用正确的色彩加强产品的印象。
3. 布局美观——均衡与对称的构图，使画面整体具有稳定性。
4. 空间感强——运用几何透视的原理，设计中表现远近、层次、穿插等关系。

气势

1. 专业性——细节完美，找不到明显的设计瑕疵。
2. 整体性——所有交互元素的设计上，用户对信息沟通顺畅，感觉似有人一般的亲和感。
3. 品牌成分——体现Facebook品牌形象，并使品牌资产保持延续与统一。
4. 惊喜度——局部设计有贴心且另人惊喜的体验。

创新

1. 共性——符合已知事物的普遍认知。
2. 异性——在共性基础上，给人耳目一新的感受。
3. 复制性——能够促进Facebook其它产品的发展。
4. 颠覆性——在互联网上前所未见，能够变成同行业新的标准。

以上的五维可以说是面面俱到，从逻辑上将可以很好的辨别一个功能和页面到底用户体验如何，基于这样的标准，接下来就是按照标准进行评价了，为了评分更加公正，可以进行内部评分和外部评分来进行区分来达到最好的效果。

产品设计内部评审规则

评价周期

1. 每个设计师每个月被评审1次。
2. Team leader每周组织一次评审，提前通知设计师。

人员组成

1. 大评委1人(组织本次评审者，由产品设计主管担任)
2. 评委4人以上（部门经理1 人、主管1人、同事1人、其它。）
3. 被评设计师

评审流程

1. 每次由被评设计师自行上报一个最近上线的作品。
2. 会议形式，被评设计师向评委团进行设计理念简单介绍。
3. 评委各自填写评审表，完成后交由大评委。
4. 大评委对评审表进行数据计算，意见汇总，并制作评审报告。
5. 组长负责每次新改版上线的用户数据收集。
6. 保留好原始评审表，进行存档。
7. 打印评审报告，并将评审意见告诉设计师，完成本次评审。

打分规则

1. 产品设计五大指标总共20条，每一条进行0-5分的打分，如果全部满意即为100分。
2. 单条如果打5分，必须写出理由。打0-4分可以不写理由。
3. 计分时，去掉一个最高分和一个最低分，剩下的分数相加后的平均即为最后得分。
4. 根据线上用户调查数据和评委打分各占50%，最后得出该设计的最终得分。

产品设计外部评审规则

线上用户调研也是用Facebook的产品设计五维去做，但不能用评委的版本，否则收集不到任何有用的信息。用户版只从情感、易用、形美、气势、创新五个大维度出题，不需要细化了，并且选项不能有任何引导性。而文字造成不要使用专业术语，用网友常用的网络用语就可以了。

产品设计用户在线调查问卷

1、您对新XXX的整体满意度如何？(情感)

A 非常满意  B 比较满意  C 一般  D 比较不满意  E 非常不满意

2、您觉得XXX是否好看？(形美)

A 漂亮，太棒了  B 还可 C 一般  D 有点难看  E 恶心，不想再看第二次

3、您认为XXX使用起来怎么样？(易用)

A 更清晰了，方便使用  B 还可以  C没什么感觉  D不如原来方便 E太费劲了

4、您认为新XXX功能怎么样？(气势)

A太棒了，我喜欢  B还可以  C一般  D有点多余  E完全多余的

5、您认为对新XXX的功能XXX怎么样？(创新)

A非常有用，太好了  B比较有用  C一般  D不关注  E对我没什么用

Facebook产品设计五维最终呈现给设计师的是图标化评审报告，不仅能知道设计师在团队中的水平，还能知道具体在那方面做的好，那方面有提高的空间，指导意义远远大于分数的意义。

以下为来自19楼的两份资料：产品设计评审模型& 产品设计评委打分表

原文链接：http://blog.19ued.com/?p=1144

No related posts.

• Web 前端是由 PHP 写的。Facebook 的 HipHop [1] 会把PHP转成 C++ 并用 g++编译，这样就可以为模板和Web逻贺业务层提供高的性能。
• 业务逻辑以Service的形式存在，其使用Thrift [2]。这些Service根据需求的不同由PHP，C++或Java实现（也可以用到了其它的一些语言……）
• 用Java写的Services没有用到任何一个企业级的应用服务器，但用到了Facebook自己的定制的应用服务器。看上去好像是重新发明轮子，但是这些Services只被暴露给Thrift使用（绝大所数是这样），Tomcat太重量级了，即使是Jetty也可能太过了点，其附加值对Facebook所需要的没有意义。
• 持久化由MySQL, Memcached [3], Facebook 的 Cassandra [4], Hadoop 的 HBase [5] 完成。Memcached 使用了MySQL的内存Cache。Facebook 工程师承认他们的Cassandra 使用正在减少，因为他们更喜欢HBase，因为它的更简单的一致性模型，以到其MapReduce能力。
• 离线处理使用Hadoop 和 Hive。
• 日志，点击，feeds数据使用Scribe [6]，把其聚合并存在 HDFS，其使用Scribe-HDFS [7]，因而允许使用MapReduce进行扩展分析。
• BigPipe [8] 是他们的定制技术，用来加速页面显示。
• Varnish Cache [9]用作HTTP代理。他们用这个的原因是高速和有效率。 [10].
• 用来搞定用户上传的十亿张照片的存储，其由Haystack处理，Facebook自己开发了一个Ad-Hoc存储方案，其主要做了一些低层优化和“仅追加”写技术 [11].
• Facebook Messages 使用了自己的架构，其明显地构建在了一个动态集群的基础架构上。业务逻辑和持久化被封装在一个所谓的’Cell’。每个‘Cell’都处理一部分用户，新的‘Cell’可以因为访问热度被添加[12]。 持久化归档使用HBase [13]。
• Facebook Messages 的搜索引擎由存储在HBase中的一个倒置索引的构建。 [14]
• Facebook 搜索引擎实现细节据我所知目前是未知状态。
• Typeahead 搜索使用了一个定制的存储和检索逻辑。 [15]
• Chat 基于一个Epoll 服务器，这个服务器由Erlang 开发，由Thrift存取 [16]

关于那些供给给上述组件的资源，下面是一些信息和数量，但是有一些是未知的：

• Facebook估计有超过60,000 台服务器[16]。他们最新的数据中心在俄勒冈州的Prineville，其基于完全自定设计的硬件[17] 那是最近才公开的 Open Compute 项目[18]。
• 300 TB 的数据存在 Memcached 中处理 [19]
• 他们的Hadoop 和 Hive 集群由3000 服务器组成，每台服务器有8个核，32GB的内存，12TB的硬盘，全部有2万4千个CPU的核，96TB内存和36PB的硬盘。 [20]
• 每天有1000亿的点击量，500亿张照片， 3 万亿个对象被 Cache，每天130TB的日志（2010年7月的数据） [21]

参考引用
[1] HipHop for PHP: http://developers.facebook.com/blog/post/358
[2] Thrift: http://thrift.apache.org/
[3] Memcached: http://memcached.org/
[4] Cassandra: http://cassandra.apache.org/
[5] HBase: http://hbase.apache.org/
[6] Scribe: https://github.com/facebook/scribe
[7] Scribe-HDFS: http://hadoopblog.blogspot.com/2009/06/hdfs-scribe-integration.html
[8] BigPipe: http://www.facebook.com/notes/facebook-engineering/bigpipe-pipelining-web-pages-for-high-performance/389414033919
[9] Varnish Cache: http://www.varnish-cache.org/
[10] Facebook goes for Varnish: http://www.varnish-software.com/customers/facebook
[11] Needle in a haystack: efficient storage of billions of photos: http://www.facebook.com/note.php?note_id=76191543919
[12] Scaling the Messages Application Back End: http://www.facebook.com/note.php?note_id=10150148835363920
[13] The Underlying Technology of Messages: https://www.facebook.com/note.php?note_id=454991608919
[14] The Underlying Technology of Messages Tech Talk: http://www.facebook.com/video/video.php?v=690851516105
[15] Facebook’s typeahead search architecture: http://www.facebook.com/video/video.php?v=432864835468
[16] Facebook Chat: http://www.facebook.com/note.php?note_id=14218138919
[17] Who has the most Web Servers?: http://www.datacenterknowledge.com/archives/2009/05/14/whos-got-the-most-web-servers/
[18] Building Efficient Data Centers with the Open Compute Project: http://www.facebook.com/note.php?note_id=10150144039563920
[19] Open Compute Project: http://opencompute.org/
[20] Facebook’s architecture presentation at Devoxx 2010: http://www.devoxx.com
[21] Scaling Facebook to 500 millions users and beyond: http://www.facebook.com/note.php?note_id=409881258919

本文由陈皓翻译：原文出处：http://www.quora.com/What-is-Facebooks-architecture

From various readings and conversations I had, my understanding of Facebook’s current architecture is:

• Web front-end written in PHP. Facebook’s HipHop [1] then converts it to C++ and compiles it using g++, thus providing a high performance templating and Web logic execution layer
• Business logic is exposed as services using Thrift [2]. Some of these services are implemented in PHP, C++ or Java depending on service requirements (some other languages are probably used…)
• Services implemented in Java don’t use any usual enterprise application server but rather use Facebook’s custom application server. At first this can look as wheel reinvented but as these services are exposed and consumed only (or mostly) using Thrift, the overhead of Tomcat, or even Jetty, was probably too high with no significant added value for their need.
• Persistence is done using MySQL, Memcached [3], Facebook’s Cassandra [4], Hadoop’s HBase [5]. Memcached is used as a cache for MySQL as well as a general purpose cache. Facebook engineers admit that their use of Cassandra is currently decreasing as they now prefer HBase for its simpler consistency model and its MapReduce ability.
• Offline processing is done using Hadoop and Hive
• Data such as logging, clicks and feeds transit using Scribe [6] and are aggregating and stored in HDFS using Scribe-HDFS [7], thus allowing extended analysis using MapReduce
• BigPipe [8] is their custom technology to accelerate page rendering using a pipelining logic
• Varnish Cache [9] is used for HTTP proxying. They’ve prefered it for its high performance and efficiency [10].
• The storage of the billions of photos posted by the users is handled by Haystack, an ad-hoc storage solution developed by Facebook which brings low level optimizations and append-only writes [11].
• Facebook Messages is using its own architecture which is notably based on infrastructure sharding and dynamic cluster management. Business logic and persistence is encapsulated in so-called ‘Cell’. Each Cell handles a part of users ; new Cells can be added as popularity grows [12]. Persistence is achieved using HBase [13].
• Facebook Messages’ search engine is built with an inverted index stored in HBase [14]
• Facebook Search Engine’s implementation details are unknown as far as I know
• The typeahead search uses a custom storage and retrieval logic [15]
• Chat is based on an Epoll server developed in Erlang and accessed using Thrift [16]

About the resources provisioned for each of these components, some information and numbers are known:

• Facebook is estimated to own more than 60,000 servers [17]. Their recent datacenter in Prineville, Oregon is based on entirely self-designed hardware [18] that was recently unveiled as Open Compute Project [19].
• 300 TB of data is stored in Memcached processes [20]
• Their Hadoop and Hive cluster is made of 3000 servers with 8 cores, 32 GB RAM, 12 TB disks that is a total of 24k cores, 96 TB RAM and 36 PB disks [20]
• 100 billion hits per day, 50 billion photos, 3 trillion objects cached, 130 TB of logs per day as of july 2010 [21]

[1] HipHop for PHP: http://developers.facebook.com/b…
[2] Thrift: http://thrift.apache.org/
[3] Memcached: http://memcached.org/
[4] Cassandra: http://cassandra.apache.org/
[5] HBase: http://hbase.apache.org/
[6] Scribe: https://github.com/facebook/scribe
[7] Scribe-HDFS: http://hadoopblog.blogspot.com/2…
[8] BigPipe: http://www.facebook.com/notes/fa…
[9] Varnish Cache: http://www.varnish-cache.org/
[10] Facebook goes for Varnish: http://www.varnish-software.com/…
[11] Needle in a haystack: efficient storage of billions of photos: http://www.facebook.com/note.php…
[12] Scaling the Messages Application Back End: http://www.facebook.com/note.php…
[13] The Underlying Technology of Messages: https://www.facebook.com/note.ph…
[14] The Underlying Technology of Messages Tech Talk: http://www.facebook.com/video/vi…
[15] Facebook’s typeahead search architecture: http://www.facebook.com/video/vi…
[16] Facebook Chat: http://www.facebook.com/note.php…
[17] Who has the most Web Servers?: http://www.datacenterknowledge.c…
[18] Building Efficient Data Centers with the Open Compute Project: http://www.facebook.com/note.php…
[19] Open Compute Project: http://opencompute.org/
[20] Facebook’s architecture presentation at Devoxx 2010: http://www.devoxx.com
[21] Scaling Facebook to 500 millions users and beyond: http://www.facebook.com/note.php…

Related posts:

1. Facebook XHP:让PHP成为模板引擎
2. Facebook HipHop 源代码发布
3. Facebook图片存储架构的学习

比如这样的简单代码示例：

<?php

rquire “xphsrc/php-lib/init.php”;

$href = ‘http://www.facebook.com’;

echo <a href={$href}>Facebook</a>

第三行代码中的语法，其中echo后的不是字符串。 XHP不仅使前端代码更容易理解，还有助于防止跨站脚本攻击。事实上，Facebook Lite网站（快速简化版本的Facebook）就是完全用XHP写成的。

源代码地址：http://wiki.github.com/facebook/xhp/

Related posts:

1. Facebook HipHop 源代码发布
2. 在Windows上安装配置Redis及Python使用
3. phpQuery:像jQuery一样处理DOM

PHP是一种脚本语言，其好处是编程效率高，能够支持产品的快速迭代。但是与传统的编译语言相比，脚本语言的CPU和内存使用效率不好。随着Ajax技术的广泛采用，加上SNS对动态要求较高，这些缺点更显得突出。常见的办法是直接用C++重写PHP应用中比较复杂的部分，作为PHP扩展。 

HipHop将PHP代码转换为高度优化的C++代码，然后再用g++编译器编译。它可以保持语义等效地执行源代码，但为了提高性能，牺牲了一些很少用到的特性，比如eval()。 

HipHop开发中的主要困难在于，在PHP和C++这两种很不一样的语言之间怎么实现转换。虽然PHP也可以写一些很巧妙的动态特性，但是大多数PHP代码还是非常简单的。if (…) {…} else {..} 比foo($x) { include $x; } 肯定更常见。这为性能提高提供了机会。HipHop生成的代码尽可能地使用函数和变量的静态绑定。同时，还使用类型推演来选出变量最可能对应的某个类型，从而节省内存。 

转换过程分三步： 

1. 静态分析。收集声明关系和依赖关系等信息。 

2. 类型推演。选择最合适的类型，是C++的标量？还是String, Array, classes, Object或者Variant。 

3. 代码生成。大部分直接将PHP语句和表达式对应为C++的语句和表达式。 

HipHop在保持了PHP优点的同时，也兼得了C++的性能优势。项目总共有30万行代码，5000多个单元测试。所有这些都以PHP开源许可证形式发布到GitHub。 

http://github.com/facebook/hiphop-php

Related posts:

1. Facebook XHP:让PHP成为模板引擎
2. Facebook的系统架构
3. 国内搜索引擎关键词的解析方法