• Home
• kafka0102的侧面照

分享“The Four Meta Secrets of Scaling at Facebook”

Posted in architecture on 六月 20th, 2010 by kafka0102

在highscalability.com上翻看最新的文章，一文 The Four Meta Secrets of Scaling at Facebook 很不错。下面做些简要的中文介绍并续上自己的解读。Facebook的规模及技术水平不消我多说，其对开源社区的贡献更是有目共睹。“The FourMeta Secrets of Scaling atFacebook”不是关于Facebook的技术架构方面的细节，而是在扩展并发展Facebook这样的大规模高复杂增长速度快的网站过程中，积累的4点有借鉴意义的观点。

1、 Scaling takes Iteration

Facebook也是从小网站发展起来的，尽管它的发展速度快得惊人，而它的技术也随着产品的发展不断迭代，尽管其间也有着适应性的阵痛。选择技术，不必选择最好的，要选择最合适的。以Facebook为例，它应该是这个星球上最大规模使用PHP的网站了。PHP的简单使其成为多数网站的选择，但上点规模的网站都会为PHP的低性能而困扰。以发展眼光来看，网站初期使用PHP仍是很好的选择，当它不再适用网站规模时，再去考虑如何扩展它。

Facebook的图片系统的衍变过程也是个极好的例子。关于Facebook的图片系统，很早之前就有相关文章的介绍。就它的图片系统来说，技术含金量不能说很闪亮，但效果上应该是满足它的需要。Facebook的图片系统主要经历了3次衍变。第一阶段：图片以NFS方式存储，元数据保存在Mysql中，读写都是直接来的，很简单的文件存储实现方式。第二阶段：数据量和访问量激增，需要对系统做优化，前端加上CDN，后端加上Memcached，但存储结构不做改变。第三阶段：尽管CDN和Cache的效果很好，但NFS不适合存储大规模的小文件，这使得Facebook开发了自己的自定义格式的文件存储–Haystack（详情请参考文章 http://perspectives.mvdirona.com/2008/06/30/FacebookNeedleInAHaystackEfficientStorageOfBillionsOfPhotos.aspx ）。

2. Don’t Over Design

过渡设计是技术人员经常犯的毛病。由于对技术的偏爱，技术人员往往会不顾实际的需求而不合理的使用技术。在做新系统时，技术人员往往是凭经验或是现有产品的影响力来评估新系统上线后的规模，并在做设计时会再锦上添花的过渡考虑它的规模，结果使用了最快的语言（比如C）、最快的存储系统（比如自己山寨的文件系统），把系统的设计、实现做得很复杂，但系统的灵活性却变得很差。而往往糟糕的情况是，系统上线后发现效果不好，结果产品的功能需要做很多改变或改进，但技术上的复杂性使得系统不能轻易的应对变化，最终产品因为过渡设计变得积重难返。

像Facebook这样的规模，相信很多公司不会使用PHP+Memcached+Mysql这样的大众化组合，但Facebook至今在总体架构上还保持着这样的简单性。当PHP的低性能不能满足Facebook，它没有转向像C/C++这样性能好但开发效率低的语言，而是对PHP做hack，开发出HipHop。使用PHP的网站朋友们，可以跟下HipHop，这个东西做好了会是解决PHP性能问题的杀手锏。

3. Choose the right tool for the job, but realize that your choice comes with overhead.

一说到技术选型，我就想到山寨一词。山寨的轮子无论在大公司还是小公司都多多少少存在，而惯见的理由是，自己造的轮子技术自有，有问题自己能解决，有需求自己可添加。而看开源社区，轮子也是多得是，但如果能青出于蓝胜于蓝，这样的轮子也值得鼓励。最怕的是，造轮子的人对已有轮子的优缺点都没有搞清楚，就开始瞎搞一个，大公司有人力有资源还好说，小公司就很难经得起这种折腾，造轮子容易，维护轮子可能就麻烦了。话又说回来，想要一个轮子完美的适合自己也不太现实，了解轮子的优缺点，发挥其优点，规避或改进其缺点是更好的选择。对于那些成熟的开源工具，我们在评估它们时往往会觉得它们太庞大太重，总想造个轻型的适合自己的轮子；但当自己的轮子被更大范围的使用，结果也会发现它也在变庞大变重。

在技术选型方面，可以尝试新的东西，但在做大规模转型时要慎重，要做好充分的技术评估。像在Java社区，SSH取代之前的EJB大行其道，但这样的一个技术栈显然要比JSP+Servlet+JDBC复杂很多，并且从中能有多少收益也值得商榷，而盲目的追求技术的先进性而不考虑其成本及团队的人力，结果技术本身成为产品成长的负担。像这两年风风火火的NOSQL，可选的实现层出不穷，但现实的说，解决同样的问题，如果能把Mysql用好，那些NOSQL产品是不必要的。当然，如果团队中有NOSQL方面的人才，自然可以针对应用场景做最合适的选择。就像PHP、Python、Ruby、Java等都能做网站，都有成功的案例，但是一个团队到底使用什么开发语言，还是综合考量的结果。

4. Get the culture right

建设好的开发团队绝对可以大书特书，并且困扰着诸多团队的管理层。团队文化这里提到3点：Movefast（能“敏捷”的应对变化，包括产品的功能方面，技术适应网站规模方面等等）、HugeImpact（在技术团队里，有时人多不一定好办事，重要的是要精兵良将，甚至有时个人英雄能够带动整个团队）、Bebold（对技术人员来说，要勇于试错，敢于尝试新东西，也敢于创造新东西，但不要盲目）。

个人感觉，好的团队要能激发团队人员的热情，能给团员发挥的空间和时间。像在Facebook，一个人并不是固定成某个不变的角色，每个人都可以接触系统的方方面面，提出自己的想法，并有机会改进现有系统的某些方面。如果把技术人员固定在自己的一亩三分地，往往使得团队人员之间没什么技术融合，团队成员的技术面狭窄，整个团队的战斗力也会下降。