Facebook内部的代码发布

公司的代码发布是在网页操作的。最近修复了几个性能问题，问题产生的一个原因是Web后端服务器增长到80多台，在并行发布时突然产生太多进程让系统变慢。需要限制并发的进程数目。随着服务器数目增长，集中式发布的发布时间会越来越长，发布服务器的CPU、磁盘IO、网络IO的负载也会持续增长。

早就听说Facebook使用了点对点（P2P）的发布方式，我想P2P方式可以把负载分布在所有服务器上，避免发布服务器成为瓶颈。正好看到了这篇文章：A behind-the-scenes look at Facebook release engineering，就想学习下Facebook是怎么发布代码的。这篇文章是2012年4月发出的；我对我感兴趣的核心内容做个摘要。

Facebook用公司研发的HipHop，把PHP转译成C++代码，之后再编译为原生二进制文件，性能大幅提升，可以让服务器的CPU负载降低50%。但是这种模式下，整个Facebook的代码（不包括静态资源）是一个1.5 GB大的独立的文件。正是因为这个庞大的文件，才让Facebook的发布这么特殊，这也不难理解Facebook要用P2P部署了。Facebook用的是BitTorrent，我们下载Ubuntu的ISO镜像时候也用BT，因为用BT比普通下载快。

Facebook小规模改进的部署每天一次，每次约需30分钟，15分钟用来生成这个大文件，15分钟用来部署。较大规模的部署每周一次。一天一次，一次半小时，尽管作者对Facebook未来将要做的改进描述为"more agile"，但我觉得这样的发布频率实在不能算是agile。未来发布的改进是要做出PHP的HipHop虚拟机，把PHP编译成字节码，由虚拟机来执行。这样就可以增量发布，而不用发布一个巨大的文件了，发布时间也可由现在的30分钟缩短到几分钟。

可见P2P发布是Facebook独特的环境下产生的解决方案，普通项目的增量式发布是不需要这样的高科技的。

因为这篇文章是一年多前的，现在看到的HipHop的GitHub页面已经叫Virtual Machine了。不知Facebook现在的发布变成什么样了？原文对整个发布过程做了全面的描述，感兴趣的可参考原文。