Facebook 的技术故事
如同每一个大型IT公司，Facebook 的技术架构演化史也是极为丰富。和 Google 一切 Infrastructure 从零研发的策略不同，最初的 Facebook 更像是典型的 Startup，尽可能地使用开源解决方案。
Facebook CEO Zuckerberg 在2005年回到母校哈佛大学给校友们讲了一堂课，其中提到了早期公司的技术架构。视频链接请点击”阅读原文“。
从 LAMP 一路走来
如 Zuckerberg 所讲，一开始，大概在 2004 年，Facebook 就是一个单纯的 LAMP 架构的小网站，用户信息保存在一张名为 info 的表里面……
他还提到了在一些早期用户增长时他们做的一些诸如 Sharding/Cache 等如今已经成为标配的提升 Scalability 的手段。时至今日，Facebook 依旧在使用 PHP 和 MySQL，但是当初的开源方案都经过了无数次的重写和架构优化。
随着用户数量的增加，单库单表早已没法满足存储和响应速度的需求。大约在 2006 年，Facebook 开始按照学校或者用户 id 把用户的数据映射到不同的数据库存储。久而久之这个映射函数就变得复杂无比，难以维护。
再后来数据库抗不住了，连接数超出了 MySQL 的承受范围，于是 Memcached 出场，MySQL 不再直接服务于应用服务器。Memcached 的查询非常快，从此响应进入毫秒时代。
不断进步
接下来的几年，同步 IO 劣势凸显，异步 IO 大展宏图，异步处理将网络程序带入了异步时代。从那时起，Facebook 中越来越多的新代码使用异步 IO，老代码也渐渐被重构。
为了让网页响应更快，Facebook 把一些和渲染网页无关的工作异步化了，在 PHP 语言中增加了一些新的功能，比如 “Post-Send Processing”，在页面返回之后处理一些发消息、清理等任务，还有 “Async” 用于支持 PHP 的函数延迟、重试、分布式。
2008 年，Facebook 的机器开始出现 CPU 负载较高的问题，这种已经是 PHP 语言层面的问题了，那时候一位中国工程师开始做 HipHop 的相关工作，就是把 PHP 翻译成 C++，然后编译执行。从此Facebook PHP的执行速度提升了几十倍，这也是Facebook技术史上最关键的一个成就。
2011 年，Hadoop 进入 Facebook 的技术栈，大数据处理框架开始火热。Facebook 把所有的日志全都记录在了 HDFS 上，而且对 Hive / Pig 等 Hadoop 系开源开发也贡献很多。
2014 年，Facebook 搞出了著名的 HHVM，一个 PHP 的 JIT 虚拟机，用于取代之前的 HipHop. 然而 HHVM 并没有带来比 HipHop 高出许多的性能提升，原因是 GCC 本身的代码优化已经足够强大了，能够把 HipHop 生成的不优化的 C++ 代码优化成高效的机器码，JIT 也不是万能药，不是用了它代码效率就能飞跃。
Too big to fail
可以看到，Facebook 在很长的一段时间内，其实都是在为早期的选择的 PHP 和 MySQL 做补丁和性能优化。
有朋友会问 Facebook 为什么不在用户迅速增长的情况下改用如今一些更为流行，更容易 Scale 的技术栈？笔者以为，当有些事物发展到一定规模时，或许就无法承受放弃的代价 — “too big to fail”.
今天的 Facebook，技术架构已经非常复杂。除以 PHP，MySQL，Memcached 为基础的应用层外，又多出了很多数据存储、数据处理、数据查询的解决方案。所有这些技术积累最终成功地将 Facebook 推至如今的体量。
如前文所述，Facebook 开源了很多内部使用的系统，考虑到 Facebook 是以数据为中心的公司，所以这些数据处理软件显得尤为重要，以下列举一些比较知名的例子：
- Scribe: Facebook 内部开发的开源，用来并发收集，处理实时 log;
- HBase: Google BigTable 的开源版本，Facebook 如今用来存储海量的用户 Event，Messenger的消息等；
- Hive: 早期 Facebook 大量使用的 Hadoop 查询工具，使用 Map-Reduce 机制；
- Presto：Facebook 如今大量使用的分布式查询工具，同样建立在 HDFS 基础上，由于没有使用 Map-Reduce 机制而大大提高了查询速度；
以上提到的技术栈只是 Facebook 框架的核心部分，根据 Facebook 的业务规模、业务需求多样化，没有任意一个方案是能够满足所有需求的。
工程师的价值
在互联网的早期，或许 SQL Database 可以作为数据处理的终极法宝，既当存储，又响应查询，甚至当 Cache 用。但如今，移动互联网产品的数据量和并发量，让 ”一招鲜吃遍天“ 变得不再可能。
根据 CAP Theorem 所述，所有的技术解决方案最终需要根据实际业务做出相应的权衡和折中，而笔者认为这也从技术角度回答了很多非行业人士的疑问：“Facebook 就是一个网站，都上线了，为什么还要招那么多工程师？” 在 Facebook 的用户量级，任何新业务的开发、原有业务的修改都浸注着工程师的智慧和努力，这也是 Hacker 们的价值。
值得一提的是，在文化上，Facebook 还尽可能的保持 “Hack“ 精神：工程师拥有决定方案的话语权。因此只要你能够快速解决问题，就可以得到同事们的尊重。从这个角度看，Facebook 确实是一家一直致力于提高工程师幸福感的公司。