大型网站架构设计及技术总结文档格式.docx
- 文档编号:15085093
- 上传时间:2022-10-27
- 格式:DOCX
- 页数:9
- 大小:24.68KB
大型网站架构设计及技术总结文档格式.docx
《大型网站架构设计及技术总结文档格式.docx》由会员分享,可在线阅读,更多相关《大型网站架构设计及技术总结文档格式.docx(9页珍藏版)》请在冰豆网上搜索。
那时使用的是Dell双CPU、4G内存的系统。
在早期阶段,MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。
但到在20XX年早期,在MySpace用户数增长到五十万后,其数据库服务器已经开始疲于奔命了。
第二代架构—增加数据库服务器
与增加Web服务器不同,增加数据库并没那么简单。
如果一个站点由多个数据库支持,设计者必须考虑的是,如何在保证数据一致性的前提下让多个数据库分担压力。
MySpace运行在三个SQLServer数据库服务器上—一个为主,所有的新数据都向它提交,然后由它复制到其它两个;
另两个数据库服务器全力向用户供给数据,用以在博客和个人资料栏显示。
这种方式在一段时间内效果很好——只要增加数据库服务器,加大硬盘,就可以应对用户数和访问量的增加。
这一次的数据库架构按照垂直分割模式设计,不同的数据库服务于站点的不同功能,如登录、用户资料和博客。
垂直分割策略利于多个数据库分担访问压力,当用户要求增加新功能时,MySpace只需要投入新的数据库加以支持。
在账户到达二百万后,MySpace还从存储设备与数据库服务器直接交互的方式切换到SAN(存储区域网络)—用高带宽、专门设计的网络将大量磁盘存储设备连接在一起,而数据库连接到SAN。
这项措施极大提升了系统性能、正常运行时间和可靠性。
然而,当用户继续增加到三百万后,垂直分割策略也变得难以维持下去。
第三代架构—转到分布式计算架构
几经折腾,最终,MySpace将目光移到分布式计算架构——它在物理上分布的众多服务器,整体必须逻辑上等同于单台机器。
拿数据库来说,思想汇报专题就不能再像过去那样将应用拆分,再以不同数据库分别支持,而必须将整个站点看作一个应用。
现在,数据库模型里只有一个用户表,支持博客、个人资料和其他核心功能的数
据都存储在相同数据库。
既然所有的核心数据逻辑上都组织到一个数据库,那么MySpace必须找到新的办法以分担负荷——显然,运行在普通硬件上的单个数据库服务器是无能为力的。
这次,不再按站点功能和应用分割数据库,MySpace开始将它的用户按每百万一组分割,然后将各组的全部数据分别存入独立的SQLServer实例。
目前,MySpace的每台数据库服务器实际运行两个SQLServer实例,也就是说每台服务器服务大约二百万用户。
据MySpace的技术人员说,以后还可以按照这种模式以更小粒度划分架构,从而优化负荷分担。
第四代架构—求助于微软方案
20XX年早期,账户达到九百万,MySpace开始用微软的C#编写ASP.NET程序。
在收到一定成效后,MySpace开始大规模迁移到ASP.NET。
账户达到一千万时,MySpace再次遭遇存储瓶颈问题。
SAN的引入解决了早期一些性能问题,但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。
20XX年中期,服务账户数达到两千六百万时,MySpace因为我们对内存的渴求而切换到了还处于beta测试的支持64位处理器的SQLServer20XX。
升级到SQLServer20XX和64位WindowsServer20XX后,MySpace每台服务器配备了32G内存,后于20XX年再次将配置标准提升到64G。
事实上,MySpace的Web服务器和数据库仍然经常发生超负荷,其用户频繁遭遇“意外错误”和“站点离线维护”等告示,他们不得不在论坛抱怨不停?
MySpace正是在这样不断重构站点软件、数据库和存储系统中,才一步步走到今天。
事实上,MySpace已经成功解决了很多系统扩展性问题,其中存在相当的经验值得我们借鉴。
MySpace系统架构到目前为止保持了相对稳定,但其技术人员仍然在为SQLServer支持的同时连接数等方面继续攻坚,尽可能把事情做到最好。
(二)Amazon
亚马逊书店无疑是电子商务发展的里程碑。
20XX年到现在,世界网络业腥风血雨。
Amazon曾经成为网络泡沫的头号代表。
如今,当这个“最大的泡沫”用几经易改的数字把自己变成了坚实的IT巨人。
历览Amazon发展过程,其成功经验在于,它创造性地进行了电子商务中每一环节的探索,包括系统平台的建设,程序编写、网站设立、配送系统等等方面。
用Amazon当家人贝索斯的话说就是,“在现实世界的商店最有力的武器就是地
段,地段,地段,而对于我们来说最重要的三件事就是技术,技术,技术。
”
(三)eBay
其成功的奥秘可以列举为以下几点:
①敢为天下先—在网络尚不普及的时代,eBay率先进入网络拍卖领域;
②依托虚拟商场所产生的特有的“零库存”是eBay公司取得成功的另一个重要原因。
该公司的核心业务没有任何库存风险,所有的商品都是由客户提供,它只需要负责提供虚拟的拍卖平台—网络和软件。
所以,eBay公司的财务报表上不会出现“库存费用”和“保管费用”等。
③自eBay公司成立开始,它就一直遵循两条“黄金原则”:
建设虚拟社区,给网民以家的感觉;
保证网站稳定安全地运行。
二、国内大型网站开发时的几点建议
从本节开始,我们将结合国内外大型IT网站在技术扩展方面的沉痛教训和成功经验,探讨在如今刚刚开始的Web2.0时代如何应对国内网站即将面临的数据访问量增加(甚至是急剧膨胀)的问题,并提出一些供参考的策略和建议。
(四)搭建科学的系统架构
构建大型的商业网站绝对不可能像构建普通的小型网站一样一蹴而就,需要从严格的软件工程管理的角度进行认真规划,有步骤有逻辑地进行开发。
对于大型网站来说,所采用的技术涉及面极其广泛,从硬件到软件、编程语言、数据库、Web服务器、防火墙等各个领域都有了很高的要求,已经不是原来简单的html静态网站所能比拟的。
以著名的Yahoo!
为例,他们的每一个大型网站工程都需要大量相应专业人员的参与。
(五)页面静态化
可不要小看纯静态化的HTML页面!
其实在很多情况下,HTML往往意味着“效率最高、消耗最小”,所以我们尽可能使我们的网站上的页面采用静态页面来实现。
但是,对于大量内容并且频繁更新的网站,我们无法全部手动实现,因此可以开发相应的自动化更新工具,例如我们常见的信息发布系统CMS。
像我们经常访问的各个门户站点的新闻频道,甚至他们的其他频道,都是通过信息发布系统来管理和实现的。
信息发布系统可以实现最简单的信息录入自动生成静态页面,还能具备频道管理、权限管理、自动抓取等功能,对于一个大型网站来说,拥有一套高效、可管理的CMS是必不可少的。
(六)存储问题
存储也是一个大问题,一种是小文件的存储,比如图片这类;
另一种是大文件的存储,比如搜索引擎的索引。
大家知道,对于Web服务器来说,不管是Apache、IIS还是其他容器,图片是最消耗资源的,于是我们有必要将图片与页面进行分离,这是基本上大型网站都会采用的策略,他们都有独立的图片服务器,甚至很多台图片服务器。
这样的架构可以降低提供页面访问请求的服务器系统压力,并且可以保证系统不会因为图片问题而崩溃,在应用服务器和图片服务器上,可以进行不同的配置优化以保证更
高的系统消耗和执行效率。
(七)数据库技术—集群和库表散列
对于大型网站而言,使用大型的数据库服务器是必须的事情。
但是,在面对大量访问的时候,数据库的瓶颈仍然会显现出来,这时一台数据库将很快无法满足应用,于是我们需要借助于数据库集群或者库表散列技术。
在数据库集群方面,很多数据库厂商都有自己的解决方案,Oracle、Sybase、SQLServer等都有很好的方案,常用的MySQL提供的Master/Slave也是类似的方案。
因此,你使用了什么样的数据库,就参考相应的解决方案来实施即可。
上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用数据库类型的限制,于是我们需要从应用程序的角度来考虑改善系统架构,其中,库表散列是常用并且最有效的解决方案。
我们在应用程序中安装业务和应用或者功能模块将数据库进行分离,不同的模块对应不同的数据库或者表,再按照一定的策略对某个页面或者功能进行更小的数据库散列,比如用户表,按照用户ID进行表散列,这样就能够低成本的提升系统的性能并且有很好的扩展性。
在这一方面一个现成的例子就是搜狐。
它的论坛就是采用了这样的架构,将论坛的用户、设置、帖子等信息进行数据库分离,然后对帖子、用户按照板块和ID进行散列数据库和表,最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。
(八)缓存策略
这绝对不单指低级的缓存技术相关的编程,应从整个架构角度着眼,深入研究Web服务器、数据库服务器的各层级的缓冲策略,最后才是低级的缓冲技术的编程。
不同的Web服务器、数据库服务器及Web编程语言都有自己不同的缓冲策略。
例如数据库存储方面,SQLServe20XX中的主动式缓存机制,Oracle数据的cachegroup技术,Hibernate的缓存包括Session的缓存和SessionFactory的缓存;
Web服务器方面,Apache提供了自己的缓存模块,也可以使用外加的Squid模块进行缓存,这两种方式均可以有效的提高Apache的访问响应能力,IIS缓冲器技术;
至于web开发语言,所用缓存技术更存在很大不同,例如ASP.NET2.0中提出了两种缓存应用程序数据和缓存服务页输出的策略,这两种缓存技术相互独立但不相互排斥,PHP有Pear的Cache模块,等等。
(九)镜像
镜像是大型网站常采用的提高性能和数据安全性的方式,镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异。
在镜像的细节技术方面,这里不阐述太深,有很多专业的现成的解决架构和产品可选。
也有廉价的通过软件实现的思路,比如Linux上的rsync等工具。
(十)负载均衡
负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。
负载均衡技术发展了多年,有很多专业的服务提供商和产品可以选择,基于LAMP
解决方案的Lighttped+Squid是相当不错的解决负载均衡和加速系统的有效方式。
(十一)硬件四层交换
第四层交换使用第三层和第四层信息包的报头信息,根据应用区间识别业务流,将整个区间段的业务流分配到合适的应用服务器进行处理。
第四层交换功能就象是虚IP,指向物理服务器。
它传输的业务服从的协议多种多样,有HTTP、FTP、NFS、Telnet或其他协议。
这些业务在物理服务器基础上,需要复杂的载量平衡算法。
在IP世界,业务类型由终端TCP或UDP端口地址来决定,在第四层交换中的应用区间则由源端和终端IP地址、TCP和
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 大型 网站 架构 设计 技术 总结