优秀工作总结范文：大型网站架构设计及技术总结

1、大型网站架构设计及技术总结随着中国大型IT企业信息化速度的加快，大部分应用的数据量 和访问量都急剧增加，大型企业网站正面临性能和高数据访问量 的压力，而且对存储、安全以及信息检索等等方面都提出了更高 的要求?本文中，我想通过几个国外大型 IT企业及网站的成功案例，从 Wet技术人员角度探讨如何积极地应对国内大型网站即将面临的 扩展（主要是技术方面，而较少涉及管理及营销等方面）矛盾。一、国外大型IT网站的成功之道（一）MySpace今天，MySpace已经成为全球众口皆碑的社区网站之王。尽管一 流和营销和管理经验自然是每个 IT企业取得成功的首要因素， 但是本节中我们却抛弃这一点，而主要着眼于探

2、讨在数次面临系 统扩张的紧急关头MySpace是如何从技术方面采取应对策略的。 第一代架构一添置更多的 Web服务器MySpace最初的系统很小，只有两台 Web服务器（分担处理用户 请求的工作量）和一个数据库服务器（所有数据都存储在这一个 地方）。那时使用的是Dell双CPU 4G内存的系统。在早期阶段， MySpace基本是通过添置更多 Web服务器来对付用户暴增问题 的。但到在2004年早期，在 MySpace用户数增长到五十万后， 其数据库服务器已经开始疲于奔命了。第二代架构一增加数据库服务器范文写作与增加Web服务器不同，增加数据库并没那么简单。如 果一个站点由多个数据库支持， 设计

3、者必须考虑的是，如何在保 证数据一致性的前提下让多个数据库分担压力。MySpace运行在三个SQL Server数据库服务器上一一个为主， 所有的新数据都向它提交， 然后由它复制到其它两个；另两个数 据库服务器全力向用户供给数据，用以在博客和个人资料栏显 示。这种方式在一段时间内效果很好一一只要增加数据库服务 器，加大硬盘，就可以应对用户数和访问量的增加。这一次的数据库架构按照垂直分割模式设计，不同的数据库服务于站点的不同功能，如登录、用户资料和博客。垂直分割策略利 于多个数据库分担访问压力，当用户要求增加新功能时，MySpace 只需要投入新的数据库加以支持。 在账户到达二百万后，MySpa

4、ce 还从存储设备与数据库服务器直接交互的方式切换到SAN （存储区域网络）一用高带宽、专门设计的网络将大量磁盘存储设备连 接在一起，而数据库连接到SAN这项措施极大提升了系统性能、 正常运行时间和可靠性。然而，当用户继续增加到三百万后，垂 直分割策略也变得难以维持下去。第三代架构一转到分布式计算架构几经折腾，最终，MySpace将目光移到分布式计算架构一一它在 物理上分布的众多服务器， 整体必须逻辑上等同于单台机器。 拿 数据库来说，思想汇报专题就不能再像过去那样将应用拆分，再 以不同数据库分别支持，而必须将整个站点看作一个应用。 现在， 数据库模型里只有一个用户表，支持博客、个人资料和其他

5、核心功能的数据都存储在相同数据库。既然所有的核心数据逻辑上都组织到一个数据库，那么MySpace必须找到新的办法以分担负荷一一显然，运行在普通硬件上的单个数据库服务器是无能为力的。这次，不再按站点功能和应用分割数据库，MySpace开始将它的用户按每百万一组分割，然后将 各组的全部数据分别存入独立的SQLServer实例。目前，MySpace的每台数据库服务器实际运行两个SQL Server实例，也就是说每台服务器服务大约二百万用户。据MySpace的技术人员说，以 后还可以按照这种模式以更小粒度划分架构，从而优化负荷分 担。第四代架构一求助于微软方案2005年早期，账户达到九百万，MySpa

6、ce开始用微软的C#编写ASP.NET程序。在收到一定成效后，MySpace开始大规模迁移到ASP.NET账户达到一千万时，MySpace再次遭遇存储瓶颈问题。SAN的引 入解决了早期一些性能问题， 但站点目前的要求已经开始周期性 超越SAN的I/O容量一一即它从磁盘存储系统读写数据的极限速 度。最全面的范文参考写作网站第五代架构一增加数据缓存层并转到支持64位处理器的 SQL Serv（转 载 于:wW :大型网站架构设计及技术总结）er 20052005年春天，MySpace账户 达到一千七百万，MySpace又启用了新的策略以减轻存储系统压 力，即增加数据缓存层位于Web服务器和数据库服

7、务器之间，其唯一职能是在内存中建立被频繁请求数据对象的副本，如此一来，不访问数据库也可以向 Web应用供给数据。2005年中期，服务账户数达到两千六百万时，MySpace因为我们 对内存的渴求而切换到了还处于 beta测试的支持64位处理器的SQL Server 2005。升级到 SQL Server 2005 和 64 位 Windows Server 2003后，MySpace每台服务器配备了 32G内存，后于2006 年再次将配置标准提升到 64G事实上，MySpace的Web服务器和数据库仍然经常发生超负荷， 其用户频繁遭遇“意外错误”和“站点离线维护”等告示，他们不得不在论坛抱怨不停

8、？MySpace正是在这样不断重构站点软件、数据库和存储系统中， 才一步步走到今天。事实上，MySpace已经成功解决了很多系统 扩展性问题，其中存在相当的经验值得我们借鉴。MySpace系统架构到目前为止保持了相对稳定，但其技术人员仍然在为SQLServer支持的同时连接数等方面继续攻坚，尽可能把事情做到 最好。（二）Amaz on亚马逊书店无疑是电子商务发展的里程碑。2000年到现在，世界网络业腥风血雨。Amazon曾经成为网络泡沫的头号代表。如 今，当这个“最大的泡沫”用几经易改的数字把自己变成了坚实的IT巨人。历览Amazon发展过程，其成功经验在于，它创造性地进行了电 子商务中每一环

9、节的探索，包括系统平台的建设，程序编写、网 站设立、配送系统等等方面。用Amazo n当家人贝索斯的话说就是，“在现实世界的商店最有力的武器就是地段，地段，地段，而对于我们来说最重要的三件事就是技术，技术，技术。”（三）eBayeBay是世界闻名的拍卖网站，eBay公司通信部主管凯文？帕斯格 拉夫认为，“ eBay成功的最重要原因在于公司管理和服务。” 其成功的奥秘可以列举为以下几点：敢为天下先一在网络尚不普及的时代，eBay率先进入网络拍卖领域；依托虚拟商场所产生的特有的“零库存”是 eBay公 司取得成功的另一个重要原因。 该公司的核心业务没有任何库存 风险，所有的商品都是由客户提供， 它

10、只需要负责提供虚拟的拍 卖平台一网络和软件。所以，eBay公司的财务报表上不会出现“库存费用”和“保管费用”等。自eBay公司成立开始，它就一直遵循两条“黄金原则”：建 设虚拟社区，给网民以家的感觉；保证网站稳定安全地运行。二、国内大型网站开发时的几点建议从本节开始，我们将结合国内外大型IT网站在技术扩展方面的 沉痛教训和成功经验，探讨在如今刚刚开始的 Web2.0时代如何 应对国内网站即将面临的数据访问量增加 （甚至是急剧膨胀）的 问题，并提出一些供参考的策略和建议。（四）搭建科学的系统架构构建大型的商业网站绝对不可能像构建普通的小型网站一样一蹴而就，需要从严格的软件工程管理的角度进行认真规

11、划，有步骤有逻辑地进行开发。对于大型网站来说，所采用的技术涉及面 极其广泛，从硬件到软件、编程语言、数据库、Web服务器、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。以著名的Y ahoo!为例，他们的每一个大型网站工程都需要大量相应专业人员的参与。（五）页面静态化可不要小看纯静态化的 HTML页面！其实在很多情况下，HTML主 往意味着“效率最高、消耗最小”，所以我们尽可能使我们的网 站上的页面采用静态页面来实现。但是，对于大量内容并且频繁 更新的网站，我们无法全部手动实现，因此可以开发相应的自动 化更新工具，例如我们常见的信息发布系统CMS像我们经常访问的

12、各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的。 信息发布系统可以实现最简单的 信息录入自动生成静态页面，还能具备频道管理、权限管理、自 动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理 的CMS是必不可少的。（六）存储问题存储也是一个大问题，一种是小文件的存储，比如图片这类；另 一种是大文件的存储，比如搜索引擎的索引。大家知道，对于 Web服务器来说，不管是 Apache、IIS还是其他 容器，图片是最消耗资源的，于是我们有必要将图片与页面进行 分离，这是基本上大型网站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。 这样的架构可以降低

13、提供页 面访问请求的服务器系统压力， 并且可以保证系统不会因为图片 问题而崩溃，在应用服务器和图片服务器上，可以进行不同的配置优化以保证更 高的系统消耗和执行效率。（七）数据库技术一集群和库表散列对于大型网站而言，使用大型的数据库服务器是必须的事情。但是，在面对大量访问的时候，数据库的瓶颈仍然会显现出来，这 时一台数据库将很快无法满足应用，于是我们需要借助于数据库 集群或者库表散列技术。在数据库集群方面，很多数据库厂商都有自己的解决方案，Oracle、Sybase、SQLServer等都有很好的方案，常用的 MySQL提供的Master/Slave也是类似的方案。因此，你使用了什么样的数据库，

14、就参考相应的解决方案来实施即可。上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用数据库类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，其中，库表散列是常用并且最有效的解决方案。 我们在应用程序中安装业务和应用或者功能模块将数据库进行 分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且 有很好的扩展性。在这一方面一个现成的例子就是搜狐。它的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进 行数据库分离，然后对帖子、用户按照板块和ID进行散列数据

15、库和表，最终可以在配置文件中进行简单的配置便能让系统随时 增加一台低成本的数据库进来补充系统性能。（八）缓存策略这绝对不单指低级的缓存技术相关的编程，应从整个架构角度着眼，深入研究 Web服务器、数据库服务器的各层级的缓冲策略， 最后才是低级的缓冲技术的编程。不同的Web服务器、数据库服务器及Web编程语言都有自己不同的缓冲策略。例如数据库存储方面，SQLServe 2005中的主动式缓存机制，Oracle数据的cache group 技术，Hibernate 的缓存包括 Session 的缓存和 SessionFactory 的缓存；Web服务器方面，Apache提供了自己 的缓存模块，也可

16、以使用外加的Squid模块进行缓存，这两种方 式均可以有效的提高 Apache的访问响应能力，IIS缓冲器技术； 至于web开发语言，所用缓存技术更存在很大不同，例如ASP.NET 2.0中提出了两种缓存应用程序数据和缓存服务页输出的策略，这两种缓存技术相互独立但不相互排斥，PHP有Pear的Cache模块，等等。（九）镜像镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的 解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux 上的 rsync 等工具。（十）负载均

17、衡负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，基于LAMP解决方案的Lighttped+Squid 是相当不错的解决负载均衡和加 速系统的有效方式。（十一）硬件四层交换第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器 进行处理。第四层交换功能就象是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTR FTP NFS Tel net或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端 TCP或UD

18、P端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口静态化，效率最高，消耗最小的就是纯静态化的 html 页面,所以我们尽可能使我们的网站上的页面采用静态页面来实 现，这个最简单的方法其实也是最有效的方法，但是对于大量内 容并且频繁更新的网站，我们无法全部手动去挨个实现 ，于是出 现了我们常见的信息发布系统CMS,像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来 管理和实现的，信息发布系统可以实现最简单的信息录入自动生 成静态页面，还能具备频道管理，权限管理，自动抓取等功能，对 于一个大型网站来说，拥有一套高效，可管理的CMS是必

19、不可少 的，除了门户和信息发布类型的网站 ，对于交互性要求很高的社 区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子，文章进行实时的静态化，有更新的时候再重新静 态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策 略,网易社区等也是如此同时，html静态化也是某些缓存策略使 用的手段，对于系统中频繁使用数据库查询但是内容更新很小的 应用，可以考虑使用html静态化来实现，比如论坛中论坛的公 用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以 考虑将这部分内容进行后台更新的时候进行 静态化,这

20、样避免了大量的数据库访问请求；、图片服务器分离: 对 Web服务器来说，不管是Apache,IIS 还是其他容器，图片是 最消耗资源的，于是我们 有必要将图片与页面进行分离，这是基 本上大型网站都会采用的策略,他们都有独立的图片服务器，甚至很多台图片服务器，这样的 架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不 会因为图片问题而崩溃，在应用服务器和图片服务器 上,可以进行不同的配置优化，比如 apache在配置 ContentType的时候可以尽量少支持,尽可能少的LoadModule, 保证更高的系统消耗和执行效率；三、数据库集群和库表散列：大型网站都有复杂的应用，这些应用必须使用数据库，那么在面 对大量访问的时候,数据库的瓶颈很快就能显现出来,这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者 库表散列，在数据库集群方面，很多数据库都有自己的解决方案,Oracle,Sybase 等都有很好的方案，常用的MySQL提供的 Master/Slave 也是类似的方案，您使用了什么样的DB,就参考相应的解决方案来实施即可，上面提到的数据库集群由于在架构 成本,扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并 且最有效的解决方案，我们