在主流的Web站点中，图片往往是不可或缺的页面元素，尤其在大型网站中，几乎都将面临“海量图片资源”的存储、访问等相关技术问题。在针对图片服务器的架构扩展中，也会历经很多曲折甚至是血泪教训（尤其是早期规划不足，造成后期架构上很难兼容和扩展）。
本文将以一个真实垂直门户网站的发展历程，向大家娓娓道来。
构建在Windows平台之上的网站，往往会被业内众多技术认为很“保守”，甚至会有点。很大部分原因，是由于微软技术体系的封闭和部分技术人员的短视造成的（当然，主要还是人的问题）。由于长期缺乏开源支持，所以很多人只能“闭门造车”，这样很容易形成思维局限性和短板。以图片服务器为例子，如果前期没有容量规划和可扩展的设计，那么随着图片文件的不断增多和访问量的上升，由于在性能、容错/容灾、扩展性等方面的设计不足，后续将会给开发、运维工作带来很多问题，严重时甚至会影响到网站业务正常运作和互联网公司的发展（这绝不是在危言耸听）。
很多公司之所以选择Windows（.NET）平台来构建网站和图片服务器，很大部分由创始团队的技术背景决定的，早期的技术人员可能更熟悉.NET，或者团队的负责人认为Windows/.NET的易用性、“短平快”的开发模式、人才成本等方面都比较符合创业初期的团队，自然就选择了Windows。后期业务发展到一定规模，也很难轻易将整体架构迁移到其它开源平台上了。当然，对于构建大规模互联网，更建议首选开源架构，因为有很多成熟的案例和开源生态的支持（也会有很多坑，就看是你自己最先去踩坑，还是在别人踩了修复之后你再用），避免重复造轮子和支出高额授权费用。对于迁移难度较大的应用，个人比较推荐Linux、Mono、Jexus、Mysql、Memcahed、Redis……混搭的架构，同样能支撑具有高并发访问和大数据量等特点的互联网应用。
单机时代的图片服务器架构（集中式）
初创时期由于时间紧迫，开发人员水平也很有限等原因。所以通常就直接在website文件所在的目录下，建立1个upload子目录，用于保存用户上传的图片文件。如果按业务再细分，可以在upload目录下再建立不同的子目录来区分。例如：upload\QA,upload\Face等。
在数据库表中保存的也是”upload/qa/test.jpg”这类相对路径。
用户的访问方式如下：
http://www.yourdomain.com/upload/qa/test.jpg
程序上传和写入方式：
程序员A通过在web.config中配置物理目录D:\Web\yourdomain\upload 然后通过stream的方式写入文件；
程序员B通过Server.MapPath等方式，根据相对路径获取物理目录 然后也通过stream的方式写入文件。
优点：实现起来最简单，无需任何复杂技术，就能成功将用户上传的文件写入指定目录。保存数据库记录和访问起来倒是也很方便。
缺点：上传方式混乱，严重不利于网站的扩展。
针对上述最原始的架构，主要面临着如下问题：
- 随着upload目录中文件越来越多，所在分区（例如D盘）如果出现容量不足，则很难扩容。只能停机后更换更大容量的存储设备，再将旧数据导入。
- 在部署新版本（部署新版本前通过需要备份）和日常备份website文件的时候，需要同时操作upload目录中的文件，如果考虑到访问量上升，后边部署由多台Web服务器组成的负载均衡集群，集群节点之间如果做好文件实时同步将是个难题。
集群时代的图片服务器架构（实时同步）
在website站点下面，新建一个名为upload的虚拟目录，由于虚拟目录的灵活性，能在一定程度上取代物理目录，并兼容原有的图片上传和访问方式。用户的访问方式依然是：
http://www.yourdomain.com/upload/qa/test.jpg
优点：配置更加灵活，也能兼容老版本的上传和访问方式。
因为虚拟目录，可以指向本地任意盘符下的任意目录。这样一来，还可以通过接入外置存储，来进行单机的容量扩展。
缺点：部署成由多台Web服务器组成的集群，各个Web服务器（集群节点）之间（虚拟目录下的）需要实时的去同步文件，由于同步效率和实时性的限制，很难保证某一时刻各节点上文件是完全一致的。
基本架构如下图所示：
从上图可看出，整个Web服务器架构已经具备“可扩展、高可用”了，主要问题和瓶颈都集中在多台服务器之间的文件同步上。
上述架构中只能在这几台Web服务器上互相“增量同步”，这样一来，就不支持文件的“删除、更新”操作的同步了。
早期的想法是，在应用程序层面做控制，当用户请求在web1服务器进行上传写入的同时，也同步去调用其它web服务器上的上传接口，这显然是得不偿失的。所以我们选择使用Rsync类的软件来做定时文件同步的，从而省去了“重复造轮子”的成本，也降低了风险性。
同步操作里面，一般有比较经典的两种模型，即推拉模型：所谓“拉”，就是指轮询地去获取更新，所谓推，就是发生更改后主动的“推”给其它机器。当然，也可以采用加高级的事件通知机制来完成此类动作。
在高并发写入的场景中，同步都会出现效率和实时性问题，而且大量文件同步也是很消耗系统和带宽资源的（跨网段则更明显）。
集群时代的图片服务器架构改进(共享存储)
沿用虚拟目录的方式，通过UNC（网络路径）的方式实现共享存储（将upload虚拟目录指向UNC）
用户的访问方式1：
http://www.yourdomain.com/upload/qa/test.jpg
用户的访问方式2（可以配置独立域名）：
http://img.yourdomain.com/upload/qa/test.jpg
支持UNC所在server上配置独立域名指向，并配置轻量级的web服务器，来实现独立图片服务器。
优点： 通过UNC（网络路径）的方式来进行读写操作，可以避免多服务器之间同步相关的问题。相对来讲很灵活，也支持扩容/扩展。支持配置成独立图片服务器和域名访问，也完整兼容旧版本的访问规则。
缺点 ：但是UNC配置有些繁琐，而且会造成一定的（读写和安全）性能损失。可能会出现“单点故障”。如果存储级别没有raid或者更高级的灾备措施，还会造成数据丢失。
基本架构如下图所示：
在早期的很多基于Linux开源架构的网站中，如果不想同步图片，可能会利用NFS来实现。事实证明，NFS在高并发读写和海量存储方面，效率上存在一定问题，并非最佳的选择，所以大部分互联网公司都不会使用NFS来实现此类应用。当然，也可以通过Windows自带的DFS来实现，缺点是“配置复杂，效率未知，而且缺乏资料大量的实际案例”。另外，也有一些公司采用FTP或Samba来实现。
上面提到的几种架构，在上传/下载操作时，都经过了Web服务器（虽然共享存储的这种架构，也可以配置独立域名和站点来提供图片访问，但上传写入仍然得经过Web服务器上的应用程序来处理），这对Web服务器来讲无疑是造成巨大的压力。所以，更建议使用独立的图片服务器和独立的域名，来提供用户图片的上传和访问。
独立图片服务器/独立域名的好处
- 图片访问是很消耗服务器资源的（因为会涉及到操作系统的上下文