主页 >> 系统架构 > 架构大中型大流量解决方案

2013/03/24 | 星期日 分类:系统架构 | 没有评论 标签: , | 作者: | 1,324 views

架构大中型大流量解决方案

架构大中型大流量解决方案,没有相应的环境无法从实战中去总结经验,主要参考文章:《高并发高流量网站架构》ITPUB论坛 转载文章,实际出处无法查证,来源网络整理,没有实战经验,如下纯属“忽悠”

1.负载均衡:DNS负载均衡早期被广泛使用,优点是简单易用。
a.将多个地址配置成同一个域名,负载均衡就完成了。
b.稍微复杂一点的负载均衡,是反向代理,当外部有请求到代理服务器,代理服务器再将该请求均匀的转发到内网的服务器上。
缺点:如果某一台服务器发生了故障,而DNS的下一个刷新周期又没到,这样就可能导致某些用户无法访问站点的情况发生。而另一个缺点在于DNS负载均衡随机性太强,比如一段时间内众多访问都被指向同一个地址,而另外的地址却闲置,就造成了局部繁忙的不良现象。而且有时某处服务器正在运行其他应用而处于繁忙状态,DNS负载均衡也无从得知,而依旧平均的解析域名。

2.CDN( Content Delivery Network),内容分发网络也是大型网站必备的部署之一。
CDN的原理不难理解,就是将网页内容存放到离用户更近的缓存服务器上,减少路由,从而加快远距离的访问速度。

3.服务器优化:网站架构时考虑性能瓶颈,影响服务器处理速度的因素:网络连接,硬盘读写,内存空间,CPU速度等。
a.Socket优化,配置linux服务器可调节的内核参数;
b.硬盘级缓存,linux环境下一般使用Squid,Squid是一个高性能的代理缓存服务器;.
c.内存级缓存,内存级别的缓存是指将需要动态生成的内容暂时缓存在内存里,在一个可接受的延迟时间范围内,同样的请求不再动态生成,而是直接从内存中读取,最常用是:Memcached;
d.CPU与IO均衡,消耗大量的服务器端IO资源,像下载,视频播放等,消耗大量的服务器CPU资源,像视频格式转换,LOG统计等,均衡每一台机器的CPU和IO消耗,不仅可以获得更充分的服务器资源利用,而且还能够支持暂时的过载,遇到突发事件,访问流量剧增的时候, 实现得体的性能下降(Graceful performance degradation),而不是立即崩溃;
e.读写分离,网站的硬盘读写性能是整个网站性能提升的一个瓶颈的话,可以考虑将硬盘的读,写功能分开,分别进行优化,比如Mysql集群。

4.应用程序优化
a.服务器选择:不要一成不变的Apache,处理不同的需求时选择不同的服务器。
Apache 后台服务器(主要处理php及一些功能请求 如:中文url)
Nginx 前端服务器(利用它占用系统资源少得优势来处理静态页面大量请求)
Lighttpd 图片服务器总体来说,随着nginx功能得完善将使他成为今后web server得主流。
b.网站的可配置性,尽量做到修改配置文件后能实时生效,避免修改配置文件之后需要重启服务程序的情况;
c.封装和中间层思想,比如MVC架构,某一层架构发生变化不一致影响其他层;

5.扩容、容错处理
a.扩容,比如MySQL数据库集群,在逻辑层封装了所有的数据库连接及操作。当数据库存储架构发生改变的时候,如增加一台主库,将某些数据表独立成库,增加读取数据用的从库等,都只需要修改封装了的数据库操作类,.上层代码不用修改。
b.容错,对于服务器错误,一般采取冗余设计的方法来避免。对于存储服务器(主要是负责写入的服务器),可以使用RAID(冗余磁盘阵列);对于数据库(主要是负责写入的主库),可以采用双主库设计;对于提供服务的前台,则可以使用第四层交换的集群,由多台服务器同时提供服务,不仅分担了流量压力,同时还可以互相作为备份。

总结:一个高并发高流量的网站来,任何一个环节的瓶颈都会造成网站性能的下降,影响用户体验,进而造成巨大的经济损失。在全互联网层面,应该使用分布式设计,缩短网站与用户的网络距离,减少主干网上的流量,以及防止在网络意外情况下网站无法访问的问题。在局域网层面,应该使用服务器集群,一方面可以支撑更大的访问量,另一方面也作为冗余备份,防止服务器故障导致的网站无法访问。在单服务器层面,应该配置操作系统,文件系统及应用层软件,均衡各种资源的消耗,消除系统性能瓶颈,充分发挥服务器的潜能。在应用层,可以通过各种缓存来提升程序的效率,减少服务器资源消耗。另外,还需要合理设计应用层程序,为以后的需求变更,扩容做好准备。

  • 本文目前尚无任何评论.
    1. 本文目前尚无任何 trackbacks 和 pingbacks.