图片是网站中必不可少的一个组成部分，随着网站的不断发展，对图片的处理也将随着访问的增长，图片的增加提出不断改进的需求。

         网站初期，所有的一切都从简图片所存在的位置通常会在站点下的Images文件夹。

         随着访问的增加，IIS压力的增大，开始做拆分，将图片文件夹作为单独站点提取出来如http://images.***.com/(可能根据需要会拆分成多个图片服务器，与具体业务环境相关)，拆分之后很好的将单个IIS应用池的压力分担到2个乃至多个上，大大提高访问瓶颈。

         随着访问的进一步增加，服务器压力已经无法支撑，这时我们需要将图片站点作为独立服务器存在。

         在访问图片的过程中，我们可能会面临一个图片有多个图片尺寸的需求，前期我们通常会在保存页面的过程中保存我们需要的各个尺寸图片，但随着所需尺寸的不同，保存图片时需要的尺寸越来越多，这时我们如何应对？

         IIS服务器的并发访问意味着随着用户的进一步增加，我们单台图片服务器已经不足以应对了，此时我们如何进一步扩展？

         如上图所示，我们此时可针对这两个问题做出统一解决方案，在前端添加squid缓存服务器，添加一台或者多台动态切图服务器。

         Squid或者Nginx代理缓存服务器能够极大的提升图片系统的并发访问，使系统突破现有限制。动态切图服务器主要的作用是针对不同尺寸的图片访问调取原图临时生成符合需求的图片并返回。原图的存储区可以与图片服务放在一起，也可以讲图片放于单独的服务器上。

         在此种结构中，并发的最大访问限制将是squid或者其他代理服务器的系统瓶颈，当切图服务压力增大时，只需添加相应切图服务器即可，图片存储区的增长也可通过添加硬盘或者服务器进行解决。

         如果您的站点访问量还在进一步增长，squid的访问瓶颈即将被突破，这时我们又该如何应对呢？

         如上图所示，采用多台Squid或Nginx服务器，在前端添加F5或LVS负载均衡(同时还可开启缓存功能)。此时将极大提升访问的并发量，可以根据情况随时调配服务器。当然此时也存在一定的瑕疵，那就是可能在多台Squid上存在同一张图片，因为访问图片时可能第一次分到squid1，在F5过期后第二次访问到squid2或者别的，当然相对并发问题的解决，此种少量的冗余完全在我们的允许范围之内。

         在做了这许多的工作后，如果条件允许对图片服务器做下CDN，那将会对您站点的图片访问质量有更大的提升。