大型互联网网站架构心得之一:分(转)
add by zhj: 作者的两篇文章主要讲网站架构过程中问题的三种解决方法:切分、合并、换。
切分:切分主要是指将一台服务器的负荷由多台服务器组成的集群承担,提高响应速度,这就是所谓的分布式。按粒度从粗到细分为按业务切分、按访问的资源切分、每种资源按某个方面进一步切分。按业务切分——将网站业务进行切分,将比较独立的业务单独分出来,这样一个大网站化解为多个小网站,每个网站单独部署。按访问的资源切分——概括的说,我们将资源分为静态资源、应用程序、数据库三部分,每种资源放在一个服务器集群上,这样就有了静态资源服务器集群、应用程序服务器集群、数据库服务器集群,要注意的是数据库服务器集群会有数据一致性的问题。每种资源按某个方面进一步切分——如静态资源按类型进一步切分为图片资源、音视频资源,数据库按操作类型(读、写)分离。
合并:主要是为了减少访问次数,我们可以把一些访问合并,比如我们使用Django框架时,如果想获取表A及关联表B的数据,那最好用QuerySet.select_related() and prefetch_related(),如果不这样的话,那获取A的记录后,遍历这些记录时,还要每次查询关联表B的记录,这就大大增加了数据库查询次数。
换:一般是空间换时间,比如缓存,即使使用了集群,对于单台服务器而言,瓶颈无外乎在网络、CPU、内存、磁盘上,最容易出现瓶颈的是IO,所以要用缓存,将硬盘访问转为内存访问,提高访问速度,如每台静态资源服务器可以缓存访问过的资源,再如将数据库返回的数据缓存起来,这部分占用的内存开销比较大,所以常把他们放在单独的服务器上,即数据库Cache服务器集群,它也面临数据一致性的问题。
其它:数据库分区分表,SQL语句的优化等。
下面是原文,原文地址:http://blog.csdn.net/lovecherry/article/details/2564096
我们知道,对于一个大型网站来说,可伸缩性是非常重要的,怎么样在纵向和横向有良好的可伸缩性,就需要在做架构设计的时候考虑到一个分的原则,我想在多个方面说一下怎么分:
首先是横向的分:
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. 网络:我们知道,网络的通讯是比较慢的,比磁盘还慢,如果是做分布式缓存,分布式计算的话,要考虑到物理服务器之间网络通讯的时间,当然,在流量大
了以后,这可以提高系统的接纳能力一个等级。静态内容可以借助CDN分担一部分,在做服务器假设的时候还要考虑中国特色的电信网通情况以及防火墙。
对数据库服务器来说:
其实还是水平分割和纵向分割,一个二维表,水平分割就是横过来切一刀,纵向分割就是竖直切一刀:
1、纵向分割就是,我们不同的应用可以分到不同的DB中,不同的实例中,或者说把某个拥有很多字段的表拆分成小表。
2、横向分割就是,某些应用可能不负载,比如用户注册,但是用户表会非常大,可以把大表分开。可以采用表分区,数据存储在不同文件上,然后再部署到独立物
理服务器增加IO吞吐以改善读写性能,土一点的做法就是自己定期把老的数据存档。表分区的另外一个优势可以增加数据查询速度,因为我们的页索引可以有多层
了,就像一个文件夹中的文件不要太多,多分几层文件夹一样。
3、还可以通过数据库镜像、复制订阅、事物日志,把读写分开到不同的镜像物理数据库上,一般来说够用,如果还不行可以用硬件来实现数据库的负载均衡。当然,对于BI,我们可能还会有数据仓库。
架构上考虑到了这些之后,流量大了,就可以在这个的基础上再去调整或者做WEB服务器或者应用服务器的负载均衡。很多时候我们都是在重复发现问题-》找到瓶颈-》解决这个过程。
典型的架构如下:
动态WEB服务器配好点的CPU,静态WEB服务器和文件服务器磁盘好点
应用服务器内存大点,缓存服务器也是,数据库服务器当然内存和CPU都要好