大型网站架构 图片服务器分离hsywymi3.docx

大型网站架构 图片服务器分离 介绍 现在很多的网站上都会用到大量的图片，而图片是网页传输中占主要的数据量,也是影响网站性能的主要因素。因此很多网站都会将图片存储从网站中分离出来，另外架构一个或多个服务器来存储图片，将图片放到一个虚拟目录中，而网页上的图片都用一个URL地址来指向这些服务器上的图片的地址，这样的话网站的性能就明显提高了，图片服务器(ImageServer)的概念也就产生了。 图片服务器的优势 分担Web服务器的I/O负载-将耗费资源的图片服务分离出来，提高服务器的性能和稳定性。 能够专门对图片服务器进行优化-为图片服务设置有针对性的缓存方案，减少带宽成本，提高访问速度。 提高网站的可扩展性-通过增加图片服务器，提高图片吞吐能力。 图片服务器的注意事项 选择适合图片存储的物理介质和文件系统 使用物理上独立的服务器 如果拥有多台图片服务器，要考虑服务器之间的图片同步问题 使用独立域名 制定合理的缓存策略 使用图片处理模块对用户上传的图片进行再加工 图片服务器的架构 图片是网站中必不可少的一个组成部分，随着网站的不断发展，对图片的处理也将随着访问的增长，图片的增加提出不断改进的需求， 网站初期，所有的一切都从简图片所存在的位置通常会在站点下的Images文件夹。 随着访问的增加，IIS压力的增大，开始做拆分，将图片文件夹作为单独站点提取出来如 HYPERLINK http://images.***.com/ http://images.***.com/(可能根据需要会拆分成多个图片服务器，与具体业务环境相关)，拆分之后很好的将单个IIS应用池的压力分担到2个乃至多个上，大大提高访问瓶颈。随着访问的进一步增加，服务器压力已经无法支撑，这时我们需要将图片站点作为独立服务器存在。在访问图片的过程中，我们可能会面临一个图片有多个图片尺寸的需求，前期我们通常会在保存页面的过程中保存我们需要的各个尺寸图片，但随着所需尺寸的不同，保存图片时需要的尺寸越来越多，这时我们如何应对？ IIS服务器的并发访问意味着随着用户的进一步增加，我们单台图片服务器已经不足以应对了，此时我们如何进一步扩展？ 如上图所示，我们此时可针对这两个问题做出统一解决方案，在前端添加squid缓存服务器，添加一台或者多台动态切图服务器。Squid或者Nginx代理缓存服务器能够极大的提升图片系统的并发访问，使系统突破现有限制。动态切图服务器主要的作用是针对不同尺寸的图片访问调取原图临时生成符合需求的图片并返回。原图的存储区可以与图片服务放在一起，也可以讲图片放于单独的服务器上。 在此种结构中，并发的最大访问限制将是squid或者其他代理服务器的系统瓶颈，当切图服务压力增大时，只需添加相应切图服务器即可，图片存储区的增长也可通过添加硬盘或者服务器进行解决。 如果您的站点访问量还在进一步增长，squid的访问瓶颈即将被突破，这时我们又该如何应对呢？ 如上图所示，采用多台Squid或Nginx服务器，在前端添加F5或LVS负载均衡(同时还可开启缓存功能)。此时将极大提升访问的并发量，可以根据情况随时调配服务器。当然此时也存在一定的瑕疵，那就是可能在多台Squid上存在同一张图片，因为访问图片时可能第一次分到squid1，在F5过期后第二次访问到squid2或者别的，当然相对并发问题的解决，此种少量的冗余完全在我们的允许范围之内。在做了这许多的工作后，如果条件允许对图片服务器做下CDN，那将会对您站点的图片访问质量有更大的提升。 图片存储架构 部署独立图片服务器的必要性 我们知道，无论对于Apache还是IIS，图片始终是最消耗系统资源的，如果将图片服务和应用服务放在同一个服务器的话，应用服务器很容易会因为图片的高I/O负载而崩溃，因此对于有些大型网站项目，我们有必要将图片服务器和应用服务器分离。部署独立的图片服务器（甚至是服务器集群）是大型网站图片存储解决方案中最基础的，因为有了独立的图片服务器后，我们才能对图片服务器做更有针对性的性能优化，比如从硬件角度说，图片服务器可以配置高端的硬盘，7200转的换成15000转的，而CPU却只要一般就可以了；从软件角度说，可以为图片服务器配置特殊的文件系统来满足对图片的I/O请求，如淘宝的TFS，就很好地解决了大规模小图片文件带来的I/O噩梦，同时，我们也可以采用nginx、squid来代理图片请求等等。 采用独立域名 注意，这里是指独立域名，不是子域哦，比如图片服务器用了的域名，而不是用二级域名，这是为什么呢？个人觉得原因主要有以下几点： 1、同一域名下浏览器的并发连接数有限制，一般在2 - 6之间，下图列举了各个浏览器的并发连接数（下图供参考） 这样，我们如果给图片服务器配置独立的域名，那么在一个页面中加载图片时，