大型WEB站点架构设计文档.docx

该【大型WEB站点架构设计文档 】是由【花双韵芝】上传分享，文档一共【35】页，该文档可以免费在线阅读，需要了解更多关于【大型WEB站点架构设计文档 】的内容，可以使用淘豆网的站内搜索功能，选择自己适合的文档，以下文字是截取该文章内的部分文字，如需要获得完整电子版，请下载此文档到您的设备，方便您编辑和打印。1、HTML静态化其实大家都知道,效率最高、消耗最小的就是纯静态化的html页面,所以我们尽可能使我们的网站上的页面采用静态页面来实现,这个最简单的方法其实也是最有效的方法。可是对于大量内容并且频繁更新的网站,我们无法全部手动去挨个实现,于是出现了我们常有的信息发布系统CMS,像我们常接见的各个门户站点的新闻频道,甚至他们的其他频道,都是经过信息发布系统来管理和实现的,信息发布系统可以实现最简单的信息录入自动生成静态页面,还能具备频道管理、权限管理、自动抓取等功能,对于一个大型网站来说,拥有一套高效、可管理的CMS是必不可少的。除了门户和信息发布种类的网站,对于交互性要求很高的社区种类网站来说,尽可能的静态化也是提高性能的必要手段,将社区内的帖子、文章进行实时的静态化,有更新的时候再从头静态化也是大量使用的策略,像Mop的大杂烩就是使用了这样的策略,网易社区等也是如此。同时,html静态化也是某些缓存策略使用的手段,对于系统中频繁使用数据库查问可是内容更新很小的应用,能够考虑使用html静态化来实现,比方论坛中论坛的公用设置信息,这些信息目前的主流论坛都能够进行后台管理并且存储再数据库中,这些信息其实大量被前台程序调用,可是更新频次很小,能够考虑将这部分内容进行后台更新的时候进行静态化,这样防止了大量的数据库接见恳求。2、图片服务器分别大家知道,对于Web服务器来说,不论是Apache、IIS仍是其他容器,图片是最消耗费源的,于是我们有必要将图片与页面进行分别,这是基本上大型网站都会采用的策略,他们都有独立的图片服务器,甚至好多台图片服务器。这样的架构能够降低提供页面接见恳求的服务器系统压力,并且能够保证系统不会因为图片问题而崩溃,在应用服务器和图片服务器上,能够进行不同的配置优化,比方apache在配置ContentType的时候能够尽量少支持,尽可能少的LoadModule,保证更高的系统消耗和履行效率。3、数据库集群和库表散列大型网站都有复杂的应用,这些应用必须使用数据库,那么在面对大量接见的时候,数据库的瓶颈很快就能展现出来,这时一台数据库将很快无法知足应用,于是我们需要使用数据库集群或许库表散列。在数据库集群方面,好多半据库都有自己的解决方案,Oracle、Sybase等都有很好的方案,常用的MySQL提供的Master/Slave也是近似的方案,您使用了什么样的DB,就参照相应的解决方案来实施即可。上面提到的数据库集群由于在架构、成本、扩充性方面都会受到所采用DB种类的限制,于是我们需要从应用程序的角度来考虑改良系统架构,库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或许功能模块将数据库进行分别,不同的模块对应不同的数据库或许表,再按照一定的策略对某个页面或许功能进行更小的数据库散列,比方用户表,按照用户ID进行表散列,这样便可以低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构,将论坛的用户、设置、帖子等信息进行数据库分别,然后对帖子、用户按照板块和ID进行散列数据库和表,最终能够在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。4、缓存缓存一词搞技术的都接触过,好多地方用到缓存。网站架构和网站开发中的缓存也是特别重要。这里先叙述最基本的两种缓存。高级和散布式的缓存在后边叙述。架构方面的缓存,对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块,也能够使用外加的Squid模块进行缓存,这两种方式均能够有效的提高Apache的接见响应能力。网站程序开发方面的缓存,Linux上提供的MemoryCache是常用的缓存接口,能够在web开发中使用,比方用Java开发的时候便可以调用MemoryCache对一些数据进行缓存和通讯共享,一些大型社区使用了这样的架构。此外,在使用web语言开发的时候,各样语言基本都有自己的缓存模块和方法,PHP有Pear的Cache模块,Java就更多了,不是很熟悉,相信也肯定有。5、镜像镜像是大型网站常采用的提高性能和数据安全性的方式,镜像的技术能够解决不同网络接入商和地区带来的用户接见速度差别,之间的差别就促进了好多网站在教育网内搭建镜像站点,数据进行准时更新或许实时更新。在镜像的细节技术方面,这里不阐述太深,有好多专业的现成的解决架构和产品可选。也有低价的经过软件实现的思路,比方Linux上的rsync等工具。6、负载平衡负载平衡将是大型网站解决高负荷接见和大量并发恳求采用的终极解决办法。负载平衡技术发展了多年,有好多专业的服务提供商和产品能够选择,我个人接触过一些解决方法,其中有两个架构能够给大家做参照。7、硬件四层互换第四层互换使用第三层和第四层信息包的报头信息,根据应用区间辨别业务流,将整个区间段的业务流分派到合适的应用服务器进行办理。第四层互换功能就象是虚IP,指向物理服务器。它传输的业务服从的协议多种多样,有HTTP、FTP、NFS、或其他协议。这些业务在物理服务器基础上,需要复杂的载量平衡算法。在IP世界,业务种类由终端TCP或UDP端口地点来决定,在第四层互换中的应用区间则由源端和终端IP地点、TCP和UDP端口共同决定。在硬件四层互换产品领域,有一些著名的产品能够选择,比方Alteon、F5等,这些产品很昂贵,可是物有所值,能够提供特别优异的性能和很灵活的管理能力。Yahoo中国当初靠近2000台服务器使用了三四台Alteon就搞定了。8、软件四层互换大家知道了硬件四层互换机的原理后,鉴于OSI模型来实现的软件四层互换也就应运而生,这样的解决方案实现的原理一致,可是性能稍差。可是知足一定量的压力仍是应付自如的,有人说软件实现方式其实更灵活,办理能力完全看你配置的熟悉能力。软件四层互换我们能够使用Linux上常用的LVS来解决,LVS就是LinuxVirtualServer,他提供了基于心跳线heartbeat的实时灾难应付解决方案,提高系统的鲁棒性,同时可供了灵活的虚构VIP配置和管理功能,能够同时知足多种应用需求,这对于散布式的系统来说必不可少。一个典型的使用负载平衡的策略就是,在软件或许硬件四层互换的基础上搭建squid集群,这种思路在好多大型网站包括搜寻引擎上被采用,这样的架构低成本、高性能还有很强的扩充性,随时往架构里面增减节点都特别容易。这样的架构我准备空了特意详尽整理一下和大家探讨。对于大型网站来说,前面提到的每个方法可能都会被同时使用到,我这里介绍得比较浅易,详细实现过程中好多细节还需要大家慢慢熟悉和领会,有时一个很小的squid参数或许apache参数设置,对于系统性能的影响就会很大,希望大家一同议论,达到抛砖引玉之效。用squid做webcacheserver,而apache在squid的后边提供真切的web服务。自然使用这样的架构必须要保证主页上大多半都是静态页面。这就需要程序员的配合将页面在反应给客户端以前将页面全部变换成静态页面。基本看出sina和sohu对于频道等栏目都用了相同的技术,即squid来监听这些IP的80端口,而真切的webserver来监听此外一个端口。从用户的感觉上来说不会有任何的区别,而相对于将webserver直接和客户端连在一同的方式,这样的方式显然的节俭的带宽和服务器。用户接见的速度感觉也会更快。带宽:4000M/S(参照)服务器数量:60台左右Web服务器:Lighttpd,Apache,nginx应用服务器:Tomcat其他:Python,Java,MogileFS、ImageMagick等对于Squid与TomcatSquid与Tomcat似乎在Web站点的架构中较少看到。我首先是对Squid有点疑问,对此阿华的解释是"目前暂时还没找到效率比Squid高的缓存系统,原来命中率确实很差,以后在Squid前又装了层Lighttpd,鉴于url做hash,同一个图片始终会到同一台squid去,所以命中率彻底提高了"对于应用服务器层的Tomcat,现在Yupoo!技术人员也在渐渐用其他轻量级的东西替代,而YPWS/YPFS现在已经用Python进行开发了。名次解释:YPWS--YupooWebServerYPWS是用Python开发的一个小型Web服务器,提供基本的Web服务外,能够增加针对用户、图片、外链网站显示的逻辑判断,能够安装于任何有安闲资源的服务器中,碰到性能瓶颈时方便横向扩展。YPFS--YupooFileSystem与YPWS近似,YPFS也是鉴于这个Web服务器上开发的图片上传服务器。【Updated:有网友留言质疑Python的效率,Yupoo老大刘平阳在上写到"YPWS用Python自己写的,每台机器每秒能够办理294个恳求,现在压力几乎都在10%以下"】图片办理层接下来的ImageProcessServer负责办理用户上传的图片。使用的软件包也是ImageMagick,在上次存储升级的同时,对于锐化的比率也调整过了(我个人感觉,效果确实好了好多)。”Magickd“是图像办理的一个远程接口服务,能够安装在任何有安闲CPU资源的机器上,近似Memcached的服务方式。我们知道Flickr的缩略图功能原来是用ImageMagick软件包的,以后被雅虎收购后出于版权原因而不用了(?);EXIF与IPTCFlicke是用Perl抽取的,我是特别建议Yupoo!针对EXIF做些文章,这也是潜在产生受益的一个重点。图片存储层原来Yupoo!的存储采用了磁盘阵列柜,鉴于NFS方式的,随着数据量的增大,”Yupoo!开发部从07年6月份就开始着手研究一套大容量的、能知足Yupoo!此后发展需要的、安全可靠的存储系统“,看来Yupoo!系统比较有信心,也是满怀期待的,毕竟这要支撑以TB计算的海量图片的存储和管理。我们知道,一张图片除了原图外,还有不同尺寸的,这些图片统一存储在MogileFS中。对于其他部分,常有的Web网站必须软件都能看到,如MySQL、Memcached、Lighttpd等。Yupoo!一方面采用不少相对照较成熟的开源软件,一方面也在自行开发定制适合自己的架构组件。这也是一个Web企业所必需要走的一个途径。特别感谢一下Yupoo!阿华对于技术信息的分享,技术是共通的。下一个能爆料是哪家?--EOF--lighttpd+squid这套缓存是放在此外一个机房作为cdn的一个节点使用的,图中没描述清楚,给大家带来不便了。squid前端用lighttpd没用nginx,主假如用了这么久,没出啥大问题,所以就没想其他的了。URLHash的扩展性确实不好,能做的就是不轻易去增减服务器,,在效率方面,我能够给个测试数据,根据目前的接见日志模拟接见测试的结果是1台ypws,平均每秒办理294个恳求(加载所有的逻辑判断)。在可靠性上,还不没详细的数据,目前运行1个多月还没有任何异样。lvs每个节点上都装nginx,主假如为了反向代理及办理静态内容,可是apache已显得不是那么必需,准备渐渐去掉。我们办理图片都是即时的,我们目前多半以上的服务器都装了magickd服务,用来分担图片办理恳求。每日数以千万计的Blog内容中,实时的热点是什么?Tailrank这个WebStartup致力于回答这个问题。特意爆料网站架构的ToddHoff对KevinBurton进行了采访。于是我们能认识一下Tailrank架构的一些信息。每小时索引2400万的Blog与Feed,内容办理能力为160-200Mbps,IO写入大概在10-15MBps。每个月要办理52T之多的原始数据。Tailrank所用的爬虫现在已经成为一个独立产品:spinn3r。