马瑞海@济南

关于高负载、大访问量的门户型web1.0网站的体系结构会涉及到诸如front-end cache，clustered database，proxy server，cdn等技术，随着web2.0的温度越来越high，web2.0的一些代表性网站的体系结构也被晒了出来，我公司的郝国梁同学在他的个人博客上进行了简单的整理，我这儿转载。顺便插播广告：我公司近期将推出IT垂直门户解决方案，包含了WoodPlow CMS+业务系统（经销商管理系统+产品报价系统）定制化很强，欢迎垂询：QQ：8269925 MSN:maruihai@live.com  Mail:support@simpond.com

案例1：豆瓣

      豆瓣是由阿北(杨勃)花4个多月时间(很神速，关键是胸有成竹)，基于linux+lighttpd+fastcgi+python+quixote+mysql架构部署的web2.0网站，豆瓣的搜索引擎使用twisted，这个是豆瓣的后台，书的价格以及比较信息都是在此之上搜索各大购物网站而来的，mysql用了innodb和myisam两种引擎，读/写频繁的用innodb，读多写少、写多读少(比如log)或者需要full text index的用myisam，replication/cluster做数据复制和集群，晚上用mysqldump做backup。

        案例2：youtube

       出于开发效率的考虑，youtube的大部分代码都是python的，web server有两种，一种是apache+fastcgi，另一种是lighttpd(主要做为视频内容服务器)，youtube可能是lighttpd最好的案例。youtube每一个视频都有4个缩略图(Thumbnails)，这个缩略图的产生对服务器的负载是个极大的考验，每一秒都给disk的i/o带来压力，youtube采用了独立的服务器culuster来应对这方面的压力，也对操作系统和缓存做了优化。另外，缩略图的request也导致了lighttpd性能下降，通过 Hack Lighttpd 增加更多的 worker thread很大程度解决了这个问题，被google收购以后，开始使用google的存储法宝bigtable，一下子提升了在performance、redundancy、cache等方面的表现。(看来这次收购还是效果颇大)出于redundancy的考虑，每一个video都放到一组mini cluster上，这组mini cluster上存储了相同内容的视频，the hotest video放在了cdn上，使压力分布到不同的节点上，非热门的，访问量不高的自己进行单独处理。维护的工具也是常见的rsync(同步工具)、ssh(远程登录)等。数据库上，youtube跟很多web2.0的站点一样，偏向使用mysql，主要是存储一些meta data，诸如视频信息、图片信息、用户信息等。youtube通过删除swap交换分区来解决数据库遇到的swap颠簸问题。

         youtube最初的 DB 只有 10 块硬盘，后来追加了一组 RAID1。在扩展性方面，采用的是主流的方式，master/slave复制(replication)，分散IO。最终的解决之道是是业务层面的分区(在用户名字或者 ID 上做文章,应用程序控制查找机制)，而不是物理上的数据库层面的表分区。youtube也用了memcached。

       案例3：myspace

       myspace有6500万的订阅者(还在上升)，是因特网上增长最快的网站之一，每天还有260，000新用户注册。它经常因为性能问题而受指责，MySpace不得不处理其他网站很少碰到的或大或小的一些问题。它们是怎么做的呢？ 使用的平台是 ASP.NET 2.0 + Windows + IIS + SQL Server ，myspace 每天处理15亿的页面查看，白天处理230万并发的用户，在50万用户的时候，采用简单的磕磕绊绊的体系结构，100万用户时进行了痛苦的垂直分割解决伸缩性，300万用户时Scale-Out 胜过Scale-Up（按比例增加）， 900万用户的时候，站点迁移到ASP.NET，增加了虚拟存储，260万用户的时候myspace采用了64位技术，当小于300万个帐号的时候，他们使用了一种数据库体系结构，围绕着垂直分割的概念，提供不同服务比如界面登录，用户资料和博客等的网站的各部分都有单独的数据库。 垂直分割方案有助于分开数据库读和写的工作量，并且当用户需要一个新特征时，MySpace 将会加入一个新的在线数据库来支持它。MySpace 从直接使用附着于它的数据库的服务器的存储设备转换到一个存储区域网络（SAN），里面大量的磁盘存储设备由一个高速，专用网络联系到一块，同时数据库连接到SAN。到SAN的改变提高了性能，正常运行时间和可靠性。 当超过300万个帐号的时候， 垂直分割解决方案就不好使了，因为它们重复了一些水平的信息像跨过所有垂直片的用户帐号。有这么多的重复它会使系统变慢，肯定要失败。个人应用比如Web站点子部分上的博客将会增长到对于单独一个数据库服务器来说太大的程度，在逻辑上重组所有核心数据到一个数据库里
，把它的用户基本信息分成100万帐号一个的块，然后把所有有键的数据放到SQL Server不同实例的这些帐号中，在 900万-1700万帐号这个阶段， 迁移到ASP.NET后，使用了比先前的体系结构更少的资源。150个服务器运行新的代码就能够做原来246个服务器做的同样的工作。 再看看存储瓶颈，实施SAN解决了原来的一些性能问题，但是现在Web站点的需求开始间歇性地超过了SAN的I/O能力，它从磁盘存储读写的速度 ，使用每个数据库100个帐号的分开方式达到了极限，因为这已经超过了极限；迁移到一个虚拟存储体系结构，那里整个SAN被当作一个大的存储池来对待，不需要特定的磁盘为特定的应用服务。现在MySpace在设备上从相对新的SAN厂商，3PARdata方面已经标准化了。增加了一个高速缓存层，服务器放在Web服务器和数据库服务器之间，它唯一的工作就是捕获内存中频繁访问的数据对象的副本，然后把它们用于Web应用，不需要数据库查询。 超过2600万注册帐号后，开始迁移到64位SQL server以解决它们的内存瓶颈问题。它们的标准数据库服务器配置使用64GB的RAM。

      Myspace的经验告诉我们：你可以使用微软的技术构建大型网站；从一开始就应该使用缓存；高速缓存是一个更好的地方存储临时数据，比如Web站点上跟踪一个特定用户的会话产生的临时文件，就不再需要记录到数据库里；嵌入OS特征来检测拒绝服务攻击会产生无法解释的错误；把数据分布到地理位置不同的数据中心，以免发生断电事故。从开始就考虑使用虚拟存储/簇文件系统。它能让你大量并行IO访问，而且不需要任何重组就能够增加所需要的磁盘。

       案例4：linkedin