Facebook谷歌等是如何应对大规模系统架构的？

大家一定都对 系统架构不陌生，尤其是对于有5-10年或者更多经验的老 码农。西方理论界管系统架构变迁叫做“System Architecture Evolution”。在这篇文章中，我们可以从一些大公司身上了解到许多宝贵的经验来关于设计一个大容量，高并发，分布式的系统。 
 
本期主要介绍国外大型网站如facebook, 谷歌, ebay等，至于国内的典范，请参考淘宝的《 十年磨一剑：淘宝技术架构发展 》。 
 
 
我们知道，在大规模、高并发系统的设计中，最常用的技术就是分层和缓存。一个业务流程通过不同的服务组装起来，这就是SOA设计的思路吧。在应用层可以考虑使用集中式缓存或者分布式缓存来减少数据库的访问压力。每个系统可以进行水平集群，提供无状态的服务，可以水平无线扩展，数据库层面，主要就是用到垂直分库，水平分库，读写分离，热备份等技术，提高数据库的读写能力。 
 
下面就让我们来看看 各大主流公司的系统架构是如何搭建的。 
 
首先是ebay 
ebay主要经历了从V1到V4的四个系统架构版本。读者们可见下面这张图 （从1999年到2006年，ebay的注册用户几乎增加了20倍，达到2亿多，现在仍然在增加）：

 
 
在ebay的V1版本，ebay采用的是FREEBSD + APACHE + PERL +DGBM，这是一个比较原始的模型，而且相对比较简单，操作系统，应用 服务器，web服务器 以及 数据库服务器都是在同一台机器中，网络结构在物理上只有一层。整个网站有四个域名，每个域名对应不同的应用，每组应用对应一台服务器。 
 
ebay的V2版本期间主要是从1999-2004年，V2主要是由四类freeBSD服务器，并且开始采用ORACLE服务器，数据库服务器和web服务器分开。程序逻辑上面已经开始分层，也就是我们常说的mvc3层结构， 编程语言采用C++，那个时候java刚兴起，没有来得及采用。服务器方面，多台服务器组成一个 servler pool(服务池)，通过一个负载均衡服务器来分别转发请求到不同的服务器。关于备份，增加了一台数据库服务器作为 备份服务器。数据库方面，对部分数据库进行读写分离，同时对Item(物品条目)数据库进行水平拆分，也就是说一个表分成几个多表，对同一类数据，按照key值的不同数据分配到不同的数据库中，增加查询速度。ebay V2的架构变迁，主要是通过服务器的添加，数据库的垂直拆分以及水平拆分。关于各组件通信方面，通过事件驱动队列和传输管道，连接起所有的组件。 
 
ebay的V3版本则全部采用的是 J2EE这种流行的企业级编程框架来写。他们也进行了大量的架构重构，比如模块复用和解耦。V3版本在数据库层面上面做了更加优化的设计。 
 
下面来看看谷歌 
Google是可扩展性系统设计之王。Google一直的目标就是构建高性能高可扩展性的基础设施来支持它们的产品。Google 系统架构可以大致分成三层： 

• 产品应用层：搜索，广告，电子邮件，地图，视频，聊天，博客
• 基础设施层：GFS，MapReduce和BigTable
• 计算平台层：分布在一堆不同的数据中心中一堆机器
• 确保公司里的人以很小的代价、能很容易地部署起他所需要的系统
• 重视单个应用的成本，将更多的钱投到能防止日志数据丢失的硬件上，而不是其他什么方面。 
  

 
 
许多公司与Google的想法并不相同，他们把基础设施看成负担，但是谷歌不。谷歌大力投资各种基础设施，比如谷歌街景，不是所有的和谷歌一样财力的公司都能愿意去做的。基础设施的建设为谷歌后期的发展奠定了雄厚的基础和极高的准入门槛。这点和中国目前的发展类似。 
 
擅长平台的构建。比如：改善了文件系统就可以让所有项目都立即而且透明地（指上层开发者和使用者都无需操心）获益。如果每个项目都使用不同的文件系统，那么在整个技术栈上的改进将不会带来持续不断的增益。谷歌的平台可谓是多种多样，更不要说现在也即将加入云服务商的行列。 
 
自动自动还是自动。谷歌试着让自己的所有软件、系统都尽量自动化，这样无形中可以省去大量的人工成本。要知道，欧美的人工成本可不是一般的贵。建立自管理系统，让工作不需要停机进行。谷歌可以说是对学术界最友好的公司之一了，学术界有很多很棒的思想，只不过还没有进入生产环境。你现在看到Google所做的事情其实都并不新鲜，只是没有大规模部署而已。谷歌很多东西都是基于学术界许多很牛的paper而出的产品化的东西。 
 
 
Google未来方向 

• 支持地理位置上分布的集群
• 为所有数据创建一个单独的全局名字空间，当前的数据是由各个集群分开的处理的。
• 更多和更好的自动化数据迁移和计算工具
• 解决当使用网络划分来做广域备份时的一致性问题(例如：保持服务即使一个集群离线维护或由于一些损耗问题) 
  

 
 
Facebook 
Facebook当年是出自于哈佛学生宿舍的产品。当初只是注重于功能上的实现，而并没有考虑太多大规模并发以及日后的扩展。一个好的例子就是图片，Facebook现在（文章撰写时）每秒需要服务12亿张图片。Uploader会将文件储存为NFS格式，而原数据将会保存在 MySQL中。这个方案只用了3个月，但是这并不重要，在上市时间上他们赢得了巨大的竞争优势，同样功能上的特点比深思扩展方案来的更加重要。第二代则使用了不同的访问方式对其进行优化，鉴于较小的图片访问频度会比较高，所以对其使用了缓存，他们同样开始使用CDN（内容分发网络）。第三代则是一个overlay系统，让Facebook可以在原有的文件系统上使用BLOB存储。图片被存储到一个二进制的BLOB，因为你清楚BLOB中图片的字节偏移量，所以每张图片对磁盘只进行一次IO操作。 
 
Facebook的页面从刚创立的时候扎克伯格写的，到现在，都用 PHP开发。后端有用各种语言开发的service。它们之间用跨语言的thrift RPC通信(Scribe也是建立在Thrift之上)。Facebook花费了大把的时间去优化PHP，最终完成了HipHop的编写，完成了PHP到C++的转换，这为他们节省了大量的内存和CPU开销。完全重写一门语言要求的是你的业务真正需要这样的重写，否则这样的定制化只是盲目的。当然，没有人说facebook的重写是盲目的。facebook的设计原则是模块化原则、整合化原则、清晰化原则，其架构设计的目标是简单、高效。facebook的架构是基于LAMP，差不多是用LAMP实现的最大的动态站点，以下是facebook架构图概览： 
 
 
 
 
不难发现，这些 大公司的系统架构都有以下共同的6大理念 （ 总结web架构 ）： 
 

1. 保持简单——随着时间推移，复杂性会自然出现。
2. 自动化一切——包括灾难恢复。
3. 不断迭代——想扩展到更高水平？必须准备好忍痛弃用现在能工作的某个组件。
4. 选择合适的工具——但也不怕自己动手打造。
5. 使用缓存——在适当的地方。
6. 根据场景，在数据的一致性和可用性之间做取舍。

 
 
也许这6点就是软件IT巨头们针对系统架构日渐成熟的一个做法。 
 
码农社区 - 专注于WEB开发（ http://w3croom.com/read.php?tid-4313.html ）