大型互联网网站架构

构建高性能Web站点

http://download.csdn.net/download/E_wsq/2613845

http://download.csdn.net/download/E_wsq/2613845

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

转：

千万级的注册用户，千万级的帖子，nTB级的附件，还有巨大的日访问量，大型网站采用什么系统架构保证性能和稳定性？

首先讨论一下大型网站需要注意和考虑的问题。

• 数据库海量数据处理：负载量不大的情况下select、delete和update是响应很迅速的，最多加几个索引就可以搞定，但千万级的注册用户和一个设计不好的多对多关系将带来非常严重的性能问题。另外在高UPDATE的情况下，更新一个聚焦索引的时间基本上是不可忍受的。索引和更新是一对天生的冤家。
• 高并发死锁：平时我们感觉不到，但数据库死锁在高并发的情况下的出现的概率是非常高的。
• 文件存储的问题：大型网站有海量图片数据、视频数据、文件数据等等，他们如何存储并被有效索引？高并发的情况下IO的瓶颈问题会迅速显现。也许用RAID和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者海南的访问速度如何解决?如果做分布式，那么我们的文件索引以及架构该如何规划。

接下来讨论大型网站的底层系统架构，来有效的解决上述问题。

毋庸置疑，对于规模稍大的网站来说，其背后必然是一个服务器集群来提供网站服务，例如，2004年eBay的服务器有2400台，估计现在更多。当然，数据库也必然要和应用服务分开，有单独的数据库服务器集群。对于像淘宝网这样规模的网站而言，就是应用也分成很多组。

下面，就从服务器操作系统与Web服务器、数据库、服务器集群与负载均衡、缓存、独立的图片服务器、其它等几个方面来分析大型网站的系统架构。

服务器操作系统与Web服务器

最底层首先是操作系统。好的操作系统能提高好的性能、稳定性和安全性，而这些对大型网站的性能、安全性和稳定性都是至关重要的。

• 淘宝网（阿里巴巴）: Linux操作系统 + Web 服务器: Apache
• 新浪：FreeBSD + Web 服务器：Apache
• Yahoo：FreeBSD + Web 服务器：自己的
• Google: 部分Linux + Web 服务器：自己的
• 百度：Linux + Web 服务器: Apache
• 网易：Linux + Web 服务器: Apache
• eBay: Windows Server 2003/8 (大量) + Web 服务器：Microsoft IIS
• MySpace: Windows Server 2003/8 + Web 服务器：Microsoft IIS

由此可见，开源操作系统做Web应用是首选已经是一个既定事实。在开源操作系统中Linux和FreeBSD差不太多，很难说哪个一定比另外一个要优秀很多、能够全面的超越对手，应该是各有所长。但熟悉Linux的技术人员更多些，利于系统管理、优化等，所以Linux使用更广泛。而Windows Server和IIS虽然有的网站使用，但不开源，而且需要购买微软的一系列应用产品，限制了其使用。总之，开源操作系统，尤其是Linux做Web应用是首选已经是一个既定事实。

常用的系统架构是:

• Linux + Apache + PHP + MySQL
• Linux + Apache + Java (WebSphere) + Oracle
• Windows Server 2003/2008 + IIS + C#/ASP.NET + 数据库

数据库

因为是千万人同时访问的网站，所以一般是有很多个数据库同时工作的，说明白一点就是数据库集群和并发控制，数据分布到地理位置不同的数据中心，以免发生断电事故。

主流的数据库有Sun的是MySQL和Oracle。

Oracle是一款优秀的、广泛采用的商业数据库管理软件。有很强大的功能和安全性，可以处理相对海量的数据。而MySQL是一款非常优秀的开源数据库管理软件，非常适合用多台PC Server组成多点的存储节点阵列(这里我所指的不是MySQL自身提供的集群功能)，每单位的数据存储成本也非常的低廉。用多台PC Server安装MySQL组成一个存储节点阵列，通过MySQL自身的Replication或者应用自身的处理，可以很好的保证容错(允许部分节点失效)，保证应用的健壮性和可靠性。可以这么说，在关系数据库管理系统的选择上，可以考虑应用本身的情况来决定。

MySQL数据库服务器的master-slave模式，利用数据库服务器在主从服务器间进行同步，应用只把数据写到主服务器，而读数据时则根据负载选择一台从服务器或者主服务器来读取，将数据按不同策略划分到不同的服务器（组）上，分散数据库压力。

服务器集群与负载均衡

服务器群集中每个服务结点运行一个所需服务器程序的独立拷贝，而网络负载均衡则将工作负载在这些主机间进行分配。负载均衡建立在现有网络结构之上，它提供了一种廉价有效的方法扩展服务器带宽和增加吞吐量，加强网络数据处理能力，提高网络的灵活性和可用性。它主要完成以下任务:解决网络拥塞问题，服务就近提供，实现地理位置无关性 ;为用户提供更好的访问质量;提高服务器响应速度;提高服务器及其他资源的利用效率;避免了网络关键部位出现单点失效。

常用的服务器集群和数据库集群负载均衡实现方法：

• Citrix NetScaler的硬件负载均衡交换机做服务器集群的负载均衡。
• MySQL Proxy做MySQL服务器集群的负载均衡并实现读写分离。其实现读写分离的基本原理是让主数据库处理事务性查询，而从数据库处理SELECT查询。数据库复制被用来把事务性查询导致的变更同步到集群中的从数据库。
• CDN (Content Delivery Network): 几乎在各大网站都有使用该技术。例如，使得你的网站在各省市访问更快，其原理是采取了分布式网络缓存结构（即国际上流行的web cache技术），通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的cache服务器内，通过DNS负载均衡的技术，判断用户来源就近访问cache服务器取得所需的内容，解决Internet网络拥塞状况，提高用户访问网站的响应速度，如同提供了多个分布在各地的加速器，以达到快速、可冗余的为多个网站加速的目的。

缓存

众所周知，使用缓存能有效应对大负载，减少数据库的压力，并显著提高多层应用程序的性能，如果某个用户多次请求同一资源，则可以从缓存返回该资源，从而避免了重新从服务器或数据库请求该资源而产生的系统开销。缓存可以通过减少获取请求的资源所需的时间，提高应用程序性能。缓存还可以通过减少到服务器的往返次数，降低网络通信量。尽管缓存可以提高性能，但它也增加了返回到应用程序的资源可能变得陈旧的风险。这意味着，返回的资源可能与假设没有使用缓存的情况下，服务器有可能发送的资源并不完全相同(即取得“脏数据”)。 

即便如此，简单的缓存策略也能大大提升网站性能。例如，Youtube把首页最新的视频列表缓存60秒，也就是说60秒内并发的request都是从缓存读取的，大大减少了数据库压力。再加上CDN，使得Youtube首页的并发访问速度很快。 

单机内存缓存、文件缓存、数据库缓存等的策略都是可以很简单的实现的，例如可以使用微软的Caching Application Block，但如何在集群环境中使多个缓存、多层缓存并保存同步是个重大问题。大型网站一般都使用缓存服务器群，并使用多层缓存。业内最常用的有：

• Squid cache，Squid服务器群，把它作为web服务器端前置cache服务器缓存相关请求来提高web服务器速度。Squid将大部分静态资源(图片，js，css等）缓存起来，直接返回给访问者，减少应用服务器的负载
• memcache，memcache服务器群，一款分布式缓存产品，很多大型网站在应用; 它可以应对任意多个连接，使用非阻塞的网络IO。由于它的工作机制是在内存中开辟一块空间，然后建立一个HashTable，Memcached自管理这些HashTable。因为通常网站应用程序中最耗费时间的任务是数据在数据库的检索，而多个用户查询相同的SQL时，数据库压力会增大，而通过memcache的查询缓存命中，数据直接从memcache内存中取，每次缓存命中将替换到数据库服务器的一次往返，到达数据库服务器的请求更少，间接地提高了数据库服务器的性能，从而使应用程序运行得更快。它通过基于内存缓存对象来减少数据库查询的方式改善网站系统的反应，其最吸引人的一个特性就是支持分布式部署。有关memcache，以下文章可以参考：参考1，参考2，参考3官方站点。
• e-Accelerator，比较特殊，PHP的缓存和加速器。是一个免费开源的PHP加速、优化、编译和动态缓存的项目，它可以通过缓存PHP代码编译后的结果来提高PHP脚本的性能，使得一向很复杂和离我们很远的 PHP脚本编译问题完全得到解决。通过使用eAccelerator，可以优化你的PHP代码执行速度，降低服务器负载，可以提高PHP应用执行速度最高达10倍。

独立的图片服务器

无论从管理上，还是从性能上看，只要有可能，尽量部署独立的图片服务器。这几乎成为常识了。具备独立的图片服务器或者服务器集群后，在 Web 服务器上就可以有针对性的进行配置优化。

其他

一个互联网应用，除了服务器的操作系统，Web Server软件，应用服务器软件，数据库软件外，我们还会涉及到一些其他的系统，比如一些中间件系统、文件存储系统（图片服务器，视频服务器，管理服务器，RSS和广告服务器等等）、全文检索、搜索、等等。会在以后介绍。

 

转自：http://www.cnblogs.com/Mainz/archive/2009/04/28/1445424.html

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

我们知道，对于一个大型网站来说，可伸缩性是非常重要的，怎么样在纵向和横向有良好的可伸缩性，就需要在做架构设计的时候考虑到一个分的原则，我想在多个方面说一下怎么分：


　　首先是横向的分：


　　1. 大的网站化解为多个小网站：当我们一个网站有多个功能的时候，可以考虑把这个网站拆分成几个小模块，每一个模块可以是一个网站，这样的话我们到时候就可以很灵活地去把这些网站部署到不同的服务器上。


　　2. 静态动态分离：静态文件和动态文件最好分离开成2个网站，我们知道静态网站和动态网站对服务器来说压力的侧重不同，前者可能重IO后者重CPU，那么我们在选择硬件的时候也可以有侧重，而且静态和动态内容的缓存策略也不一样。典型的应用，我们一般会有独立的文件或图片服务器。而且，使用不用的域名还可以提高浏览器并行加载的能力。


　　3. 按照功能来分：比如有一个模块是负责上传的，上传操作很消耗时间，如果和其它应用混在一起的话很可能，一点点访问就会使服务器瘫痪，这种特殊的模块应该分开。安全的不安全的也要分开，还需要考虑到以后SSL的购买。


　　4. 我们不一定要全部用自己的服务器，搜索、报表可以依靠别人的服务，比如google的搜索和报表服务，自己做的不一定比得过别人，服务器带宽都省了。


　　其次是纵向的分：


　　1. 文件也相当于数据库，IO的流量可能比数据库还大，这也算是纵向级别的访问，上传的文件图片一定要和WEB服务器分开。当然，数据库和网站都放在一个服务器上的很少了，这是最基本的。


　　2. 对于涉及到数据库访问的动态程序来说，我们可以使用一个中间层(所谓的应用层或逻辑层)来访问数据库(部署在独立的服务器上)，最大的好处就是缓存和灵活性。缓存的内存占用比较大，我们要把它和网站进程分开，而且这样做我们可以很方便的去改变一些数据访问的策略，即使到时候数据库有分布的话在这里可以做一个调配工作，这样灵活性就很大了。还有好处是中间层可以做电线网通桥梁，可能网通访问双线再访问电信会比网通直接访问电信服务器快。


　　有人说我不分，我可以做负载均衡，对，是可以的，但是如果分的话，同样的10台机器肯定比不分10台机器可以承受更多的访问量，而且对硬件的需求可能不会很高，因为知道需要哪个硬件特别好。争取让每一个服务期都不空闲，又都不是太忙，合理进行组合调整和扩充，这样的系统伸缩性就高了，能根据访问量来调整的前提就是之前有考虑到分，分的好处是灵活性、伸缩性、隔离性以及安全性。


　　对服务器来说，我们有几点是要长期观察的，任何一点都可能是瓶颈：


　　1. CPU：动态文件的解析需要比较多的CPU，CPU出现瓶颈就要看是不是哪个功能过长时间占用线程，如果是就分出去。或者就是每一个请求处理时间不长，但是访问量很高，那么就加服务器。CPU是好东西，不能让他干等，不做事情。


　　2. 内存：缓存从IIS进程独立出去，一般对WEB服务器来说内存不够的情况不是很多。内存比磁盘快，要合理利用。


　　3. 磁盘IO：用性能监视器找到哪些文件IO特别大，找到了就分到独立的一组文件服务器上去，或者直接做CDN。磁盘慢，大规模读取数据的应用靠缓存，大规模写入数据的应用可以靠队列来降低突发的并发。


　　4. 网络：我们知道，网络的通讯是比较慢的，比磁盘还慢，如果是做分布式缓存，分布式计算的话，要考虑到物理服务器之间网络通讯的时间，当然，在流量大了以后，这可以提高系统的接纳能力一个等级。静态内容可以借助CSD分担一部分，在做服务器假设的时候还要考虑中国特色的电信网通情况以及防火墙。


　　对SQL SERVER数据库服务器来说：


　　其实还是水平分割和纵向分割，一个二维表，水平分割就是横过来切一刀，纵向分割就是竖直切一刀：


　　1、纵向分割就是，我们不同的应用可以分到不同的DB中，不同的实例中，或者说把某个拥有很多字段的表拆分成小表。


　　2、横向分割就是，某些应用可能不负载，比如用户注册，但是用户表会非常大，可以把大表分开。可以采用表分区，数据存储在不同文件上，然后再部署到独立物理服务器增加IO吞吐以改善读写性能，土一点的做法就是自己定期把老的数据存档。表分区的另外一个优势可以增加数据查询速度，因为我们的页索引可以有多层了，就像一个文件夹中的文件不要太多，多分几层文件夹一样。


　　3、还可以通过数据库镜像、复制订阅、事物日志，把读写分开到不同的镜像物理数据库上，一般来说够用，如果还不行可以用硬件来实现数据库的负载均衡。当然，对于BI，我们可能还会有数据仓库。


　　架构上考虑到了这些之后，流量大了，就可以在这个的基础上再去调整或者做WEB服务器或者应用服务器的负载均衡。很多时候我们都是在重复发现问题-》找到瓶颈-》解决这个过程。


　　动态WEB服务器配好点的CPU，静态WEB服务器和文件服务器磁盘好点


　　应用服务器内存大点，缓存服务器也是，数据库服务器当然内存和CPU都要好


　　上次说的“分”是一个比较大的原则也是一个比较高层的原则，这次我想说一下其它两个原则：并与换。


　　并为什么要分?是因为我们希望通过分来提高系统的承载能力，那并又是并什么呢?我想了一下有几个方面可以并：


　　1. 合并用户请求，最基本的就是合并CSS/图片/脚本，还可以合并页面。不过合并就可能产生流量的浪费，需要有一个平衡点。


　　2. 合并接口的粒度，如果做分布式应用的话，我们可能不会直接访问数据库而是调用应用层提供的接口，由于是网络调用，代价比较大，因此在设计的时候尽量提供粒度比较粗的接口，一次调用返回比较多的数据，而不是细化到添加删除修改的层次。


　　3. 合并接口的部署，对于频繁的跨机器调用可以考虑有一些数据冗余，把跨网络的服务编程进程间通讯，甚至转到客户端来做。比如论坛发贴时候脏词的过滤，直接调用应用层提供的接口(跨机器)是可以的，但是可能代价比较大，可以把这个接口使用IPC方式部署在本机。


　　换时间换空间，空间换时间是常见的做法，具体一点说：


　　1. 缓存。缓存的重要性早计算机的硬件中就有重要的体现。对于网站，有很多种缓存，可以是客户端资源的缓存，可以是页面输出缓存，也可以是应用层的数据缓存，目的都是一样的，或是减少了服务器请求次数，或是减少了请求的处理过程，或是减少了数据库的访问次数。当然，生成静态文件也可以算是一种缓存。不访问磁盘固然不可能，但是我们要极大限度降低磁盘访问的机会。


　　2. 有的时候为了获取极快的响应，我们还会不惜代价采用重复计算。比如，我们的某个操作很可能会由于网络问题等原因响应比较慢，在设计的时候可以有一个统一的处理接口，由这个接口分发到不同的服务器去异步实现这个操作，哪个服务器先返回了结果我们就用这个结果，然后杀死其他服务器的冗余操作。


　　3. 网站一般追求比较快的响应，一般不太会在比较高的层次用时间来换取空间，但是在一些用户独有数据的处理算法上可能还是会考虑到空间的节省问题。


　　4. 有的时候我们会用一些聚合表来存放聚合数据，也就是进行一些预计算提高复杂计算(比如报表)的性能。当然，对于数据分析，构建多维数据库也是一种不错的选择。


　　有很多网友留言说说的比较粗，没有什么具体的东西。我觉得架构这个东西很难去说具体怎么做，因为具体实施的时候要看情况去应用的，由于没有完美的东西，所以做架构通常是去做一个平衡，很可能某一个侧重不同会影响到架构的实施。希望我的这些文章能给大家一个提示的作用，看了之后如果你觉得“这点我倒没有考虑到，以后要注意”那或许就是最大的帮助了，下面我想说一些其它方面的问题，每一条都很零散，算是一个补充吧：


　　1. 到底是采用已有的东西还是自己去做需要详细考虑的，采用别人的东西可能比较稳定，但是自己的控制少了一点，采用自己做的东西可以很灵活，但是可能会问题比较多。不管怎么样，我们在采用一个第三方框架的时候务必要进行缜密的调查，看到他的不足，否则项目很可能在后期被这个框架制约，反之，决定自己去做一个框架的时候也要看到自己需要什么其他框架不能提供的东西。


　　2. 数据传输的时候可以做压缩，但要考虑到压缩解压缩需要CPU资源，在IO(磁盘，带宽，传输能力)和CPU之间有一个平衡的考虑。


　　3. 理想的可伸缩性架构是可以自由增加或替换服务器，无需去停机维护或做很大的调整。在使用一个统一的调度中心来调度这些服务器，分配请求的时候，我们要考虑一下调度服务器能承受多少流量。


　　4. 使用大量的廉价服务器还是少量的高配服务器?如何根据需求来组合服务器发挥最大作用。


　　5. 对于分布式构架，我们尽量让每一个节点保持简单的逻辑，尽量减少同一层次节点之间的依赖，另外。需要有统一的地方来管理所有的节点。


　　6. 功能分解、使用异步进行整合、故障转移、失效保护。


　　7. 软件的架构升级和计算机硬件的架构升级很像，可能有一段时期，我们是在慢慢提高整体能力，2年也才提高了几倍，之后发现只有通过某种彻底的架构改变才能提高数十倍的能力，升级之后，我们或许又会遇到其他问题。就像CPU，是简单提高主频还是彻底更换架构。


　　8. 数据方面，读写分离、数据库分隔、功能划分、缓存、镜像。


　　9. 硬件网络上的架构很重要，但软件开发中的一些细节不可忽略，好的架构不意味着不需要代码审阅。


原文出自【比特网】，转载请保留原文链接：http://server.chinabyte.com/475/9030475.shtml