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 确实是一家一直致力于提高工程师幸福感的公司。

原文发布于微信公众号 - 包子铺里聊IT(baozitraining)

原文发表时间:2016-01-05

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏闰土大叔

月薪8k和月薪38K的程序员,差距在哪儿?

今天的文章,土哥打算分享一位「有着八年开发经验的全栈大佬」的职场建议,各位码农萌新,搬好小板凳,准备洗脑。(以下均以第一人称的口吻叙事)

1424
来自专栏华章科技

一位数据科学家的私房工具清单

近日北卡来罗纳大学CTO,一位数据科学家Jefferson Heard分享了多年来收集沉淀的数据分析工具集:

1042
来自专栏双十二技术哥

Android性能优化(十二)之我为什么写性能优化

从1月10号第一篇文章开始,到现在过去了4个月又20天,陆续写下了性能优化系列文章共计十二篇,大概一个月三篇的节奏。本篇文章是性能系列文章的最后一篇,没有新的大...

1202
来自专栏华章科技

大数据圈盘点:你不知道的15个新技术

下面一起来看看吸引眼球的十五项大数据公告。虽然罗列了很多,但还不是全部内容,只是最近在加利福尼亚州圣何塞市Strata + Hadoop World大会上亮相的...

1121
来自专栏程序员互动联盟

要想学会Kali linux事先需要掌握哪些知识?

算起来在linux上开发程序差不多有十几年的时间了,接触linux是从一本杂志上看到的,说到了linux系统如何的高效安全,于是在千方百计的搞了个linux系统...

6022
来自专栏北京马哥教育

SQL/NoSQL两大阵营激辩:谁更适合大数据

企业在着手推动大数据项目的过程中,经常会遇到这样一个关键性的决策难题——到底该使用哪种数据库方案?经过综合考量,最终的选项往往只剩下 SQL 与 NoSQL 两...

4667
来自专栏ytkah

微信小程序的好处及可能的不足

微信小程序是什么?小程序基于微信体系,在微信内部不用安装就能使用,体积不超过1 M。如果简单粗暴一点,小程序可以简单理解为——“微信应用”。 引用微信之父张小龙...

6245
来自专栏PPV课数据科学社区

【资讯】SQL/NoSQL两大阵营激辩:谁更适合大数据

目前企业在着手推动大数据项目的过程中,经常会遇到这样一个关键性的决策难题——到底该使用哪种数据库方案?经过综合考量,最终的选项往往只剩下SQL与NoS...

2613
来自专栏猿湿Xoong

你的微信,到底「连接」多少人?

1416
来自专栏互联网杂技

3D交互设计会是这个样子?

现在,VR和MR已经越来越热门了(影视剧里已经出现的太多了,比如《黑镜》),但现实是,我们对于虚拟交互的认知还是仅限于酷炫的特效,真正第一次成系统并实用的交互模...

3857

扫码关注云+社区

领取腾讯云代金券