《大型Web站点构建技术初探》由会员分享，可在线阅读，更多相关《大型Web站点构建技术初探（23页珍藏版）》请在金锄头文库上搜索。
1、大型Web2.0站点构建技术初探Web2.0的兴起，掀起了互联网新一轮的网络创业大潮。以用户为导向的新网站建设概念，细分了网站功能和用户群，不仅成功的造就了一大批新生的网站，也极大的方便了上网的人们。但Web2.0以用户为导向的理念，使得新生的网站有了新的特点高并发，高流量，数据量大，逻辑复杂等，对网站建设也提出了新的要求。 本文围绕高并发高流量的网站架构设计问题，主要研究讨论了以下内容： 首先在整个网络的高度讨论了使用镜像网站，CDN内容分发网络等技术对负载均衡带来的便利及各自的优缺点比较。然后在局域网层次对第四层交换技术，包括硬件解决方案F5和软件解决方案LVS，进行了简单的讨论。接下来在
2、单服务器层次，本文着重讨论了单台服务器的Socket优化，硬盘级缓存技术，内存级缓存技术，CPU与IO平衡技术（即以运算为主的程序与以数据读写为主的程序搭配部署），读写分离技术等。在应用层，本文介绍了一些大型网站常用的技术，以及选择使用该技术的理由。最后，在架构的高度讨论了网站扩容，容错等问题。 本文以理论与实践相结合的形式，结合作者实际工作中得到的经验，具有较广泛的适用性。1 引言1.1 互联网的发展最近十年间，互联网已经从一个单纯的用于科研的，用来传递静态文档的美国内部网络，发展成了一个应用于各行各业的，传送着海量多媒体及动态信息的全球网络。从规模上看，互联网在主机数、带宽、上网人数等方面
3、几乎一直保持着指数增长的趋势，2006年7月，互联网上共有主机439，286，364台，WWW 站点数量达到 96，854，877个 1。全球上网人口在2004 年达到 7 亿 2900万 2，中国的上网人数在 2006 年 12 月达到了约 1亿3700 万3。另一方面，互联网所传递的内容也发生了巨大的变化，早期互联网以静态、文本的公共信息为主要内容，而目前的互联网则传递着大量的动态、多媒体及人性化的信息，人们不仅可以通过 互联网阅读到动态生成的信息，而且可以通过它使用电子商务、即时通信、网上游戏等交互性很强的服务。因此，可以说互联网已经不再仅仅是一个信息共享网络，而已经成为了一个无所不在的
4、交互式服务的平台。 1.2 互联网网站建设的新趋势互联网不断扩大的规模，日益增长的用户群，以及web2.04的兴起，对互联网网站建设提出了新的要求: 高性能和高可扩展性。2000 年 5 月，访问量排名世界第一（统计数据来源5）的Yahoo 6声称其日页浏览数达到 6 亿 2500 万，即每秒约 30，000 次HTTP 请求(按每个页面浏览平均产生 4 次请求计算) 。这样大规模的访问量对服务的性能提出了非常高的要求。更为重要的是， 互联网受众的广泛性，使得成功的互联网服务的访问量增长潜力和速度非常大，因此服务系统必须具有非常好的可扩展性，以应付将来可能的服务增长。支持高度并发的访问。高度并
5、发的访问对服务的存储与并发能力提出了很高的要求，当前主流的超标量和超流水线处理器能处理的并发请求数是有限的，因为随着并发数的上升，进程调度的开销会很快上升。互联网广域网的本质决定了其访问的延迟时间较长，因此一个请求完成时间也较长，按从请求产生到页面下载完成 3 秒计算， Yahoo 在 2000 年 5 月时平均有 90，000 个并发请求。而且对于较复杂的服务，服务器往往要维护用户会话的信息，例如一个互联网网站如果每天有 100 万次用户会话，每次 20分钟的话，那平均同时就会有约 14000 个并发会话。高可用性。互联网服务的全球性决定了其每天 24 小时都会有用户访问，因此任何服务的停止
6、都会对用户造成影响。而对于电子商务等应用，暂时的服务中止则意味着客户的永久失去及大量的经济损失，例如71999 年 6 月的一次 22小时的网站不可访问，对此网站的 380万用户的忠诚度造成巨大影响，使得 Ebay 公司不得不支付了近500万美元用于补偿客户的损失，而该公司的市值同期下降了 40 亿美元8。因此，关键互联网应用的可用性要求非常高。1.3 新浪播客的简介以YouTube9为代表的微视频分享网站近来方兴未艾，仅2006年一年，国内就出现近百家仿YouTube的微视频分享网站10，试图复制YouTube的成功模式。此类网站可以说是Web2.0概念下的代表网站，具有Web2.0网站所有
7、典型特征：高并发，高流量，数据量大，逻辑复杂，用户分散等等。新浪11作为国内最大的门户网站，在2005年成功运作新浪博客的基础上，于2006年底推出了新浪播客服务。新浪播客作为国内门户网站中第一个微视频分享服务的网站，依靠新浪网站及新浪博客的巨大人气资源，在推出后不到半年的时间内，取得了巨大的成功：同类网站中上传视频数量第一、流量增长最快、用户数最多12，所有这些成绩的取得的背后，是巨大的硬件投入，良好的架构支撑和灵活的应用层软件设计。本文是作者在新浪爱问搜索部门实习及参与新浪播客开发的经验和教训的回顾，是作者对一般高并发高流量网站架构的总结和抽象。2、 Flickr的幕后故事我们都看到 Fl
8、ickr 的成功，而又有多少精英们了解过 Flickr 背后的过程是多么充满艰险。 Flickr 是全 CGI 的动态构架，并以一种 .gne 的脚本作为 CGI 程序语言。不管网站制作菜鸟还是高手都会疑惑：gne 是哪种程序语言？答案：gne 不是一种语言，Flickr 是以极为经典的 PHP + MySQL 方式实现的，在被 Yahoo 收购服务器搬入美国之前，使用了 21 台（69.90.111.101-121） Apache/PHP 做 Web、23 台图片服务器、另有 MySQL 服务器组成的数据库集群的服务器数量未知。现在估计使用的是 Yahoo 的负载均衡系统，对外只有一个 We
9、b 的 IP 和图片服务器的 IP 了。 那为何 .php 的文件要改成 .gne 呢？以往有大型网站为向后兼容性考虑，隐藏以程序语言命名的脚本文件扩展名，比如 Baidu 隐藏了 .php（Google 的 http 服务器是自己写的，整合了脚本程序，个别页面是 .py-Python）；还有一些网站是改成自己网站名相关的扩展名，如 MSN 的群组则是 .msnw，榕树下是 .rs。 那 Flickr 的 gne 是什么意思？我在维基百科的 Flickr 条目上找到了答案(中文 Flickr 条目上没有写明) 。原来 GNE 是 Game NeverEnding 的缩写，Flickr 的开发者
10、 Ludicorp 在 2002-2004 年一直在开发这套以 Game NerverEnding 为名称的大型多人在线角色扮演游戏-一套基于浏览器的 Web 游戏系统，个人以为应该就是当年九城的虚拟城市。但是开发近 3 年后该计划不得不破产，最终只发布了一个 Beta 版，而 Ludicorp 将这套系统稍加移植，就有了 Flickr。呵呵，原来 gne 是一个项目的名称。关于 GNE 的一些连接：http:/del.icio.us/schee/gne。 早期的 Flickr 想做成在类似聊天室的地方让网友分享、交流自己的照片，注重社区形式和保护照片不被外部引用（见徐子涵2004年的文章），
11、可能是看到了 Hello 的模式吧。但是聪明的 Flickr 团队不久就改变了策略，淡化了传统的社区形式-如聊天室、而加强了现在使其功成名就的 Tag 组织形式，一种更自由更随兴更轻松好玩的大社区形式，或者叫它广义社区吧，我随便叫的，可能太学究，看着别太在意就是了。另外，将原来照片只能在 Flash 内浏览的限制区除了，并大力推荐用户将照片引用到自己的 Blog，这无疑对于挑战传统相册系统有决定性意义。减少 Flash 后的网页更多地引进了新兴的 Ajax 技术，使界面操作变得非常 Cool。 这就是 Flickr 的历史，清晰地看到了他们对于优秀产品的执著。有了技术和经验积累，加上不断坚持，
12、总有一天时来运转，你的产品会成为新潮流的里程碑。 还有一句话要告诉 Yupoo 等：把 Flickr 想成一个有 Tag 功能的在线相册就已经错远了；复制粘贴者们想当然将 Flickr 去其糟粕取其精华，结果无关紧要的拿来了，将令人激动的优点都去掉了，结果剩下什么？ 3、 YouTube 的架构扩展在西雅图扩展性的技术研讨会上，YouTube 的 Cuong Do 做了关于 YouTube Scalability 的报告。视频内容在 Google Video 上有(地址)，可惜国内用户看不到。 Kyle Cordes 对这个视频中的内容做了介绍。里面有不少技术性的内容。值得分享一下。(Kyle
13、 Cordes 的介绍是本文的主要来源) 简单的说 YouTube 的数据流量, 一天的YouTube流量相当于发送750亿封电子邮件., 2006 年中就有消息说每日 PV 超过 1 亿,现在? 更夸张了,每天有10亿次下载以及6,5000次上传, 真假姑且不论, 的确是超乎寻常的海量. 国内的互联网应用,但从数据量来看,怕是只有 有这个规模. 但技术上和 YouTube 就没法子比了. 3.1 Web 服务器 YouTube 出于开发速度的考虑，大部分代码都是 Python 开发的。Web 服务器有部分是 Apache， 用 FastCGI 模式。对于视频内容则用 Lighttpd 。据
14、我所知，MySpace 也有部分服务器用 Lighttpd ，但量不大。YouTube 是 Lighttpd 最成功的案例。(国内用 Lighttpd 站点不多，豆瓣用的比较舒服。by Fenng) 3.2 视频 视频的缩略图(Thumbnails)给服务器带来了很大的挑战。每个视频平均有4个缩略图，而每个 Web 页面上更是有多个，每秒钟因为这个带来的磁盘 IO 请求太大。YouTube 技术人员启用了单独的服务器群组来承担这个压力，并且针对 Cache 和 OS 做了部分优化。另一方面，缩略图请求的压力导致 Lighttpd 性能下降。通过 Hack Lighttpd 增加更多的 work
15、er 线程很大程度解决了问题。而最新的解决方案是起用了 Google 的 BigTable， 这下子从性能、容错、缓存上都有更好表现。看人家这收购的，好钢用在了刀刃上。 出于冗余的考虑，每个视频文件放在一组迷你 Cluster 上，所谓 迷你 Cluster 就是一组具有相同内容的服务器。最火的视频放在 CDN 上，这样自己的服务器只需要承担一些漏网的随即访问即可。YouTube 使用简单、廉价、通用的硬件，这一点和 Google 风格倒是一致。至于维护手段，也都是常见的工具，如 rsync, SSH 等，只不过人家更手熟罢了。 3.3 数据库 YouTube 用 MySQL 存储元数据-用户
16、信息、视频信息什么的。数据库服务器曾经一度遇到 SWAP 颠簸的问题，解决办法是删掉了 SWAP 分区! 管用。 最初的 DB 只有 10 块硬盘，RAID 10 ，后来追加了一组 RAID 1。够省的。这一波 Web 2.0 公司很少有用 Oracle 的(我知道的只有 Bebo,参见这里). 在扩展性方面，路线也是和其他站点类似，复制，分散 IO。最终的解决之道是分区,这个不是数据库层面的表分区，而是业务层面的分区(在用户名字或者 ID 上做文章,应用程序控制查找机制) YouTube 也用 Memcached. 很想了解一下国内 Web 2.0 网站的数据信息,有谁可以提供一点 ? 4、 mixi.jp：使用开源软件搭建的可扩展SNS网站Mixi目前是日本
