网址：
在主流网站中，图片往往是不可或缺的页面元素。尤其是大型网站，几乎都会面临“海量图片资源”的存储和访问相关的技术问题。在镜像服务器的架构扩展中，也会有很多曲折甚至血泪（尤其是前期缺乏规划，导致后期架构难以兼容和扩展）。
本文将告诉大家一个真正的垂直门户网站的开发过程。
建立在平台上的网站，往往被业内很多技术认为“保守”，甚至有点“保守”。很大一部分原因是由于微软技术体系的封闭和一些技术人员的短视（当然主要是人为问题）。由于长期缺乏开源支持，很多人只能“闭门造车”，容易形成思维局限和缺点。以镜像服务器为例，如果前期没有容量规划和可扩展设计，那么随着镜像文件的不断增加和访问量的增加，由于在性能、容错/容灾方面的设计不足，以及可扩展性，
很多公司之所以选择（.NET）平台搭建网站和图片服务器，很大程度上是由创始团队的技术背景决定的。早期的技术人员可能对.NET比较熟悉，或者组长认为/.NET好用。在易用性、“短、平、快”的开发模式，以及人才成本方面，更符合业务初期的团队，自然选择。后来，当业务发展到一定规模时，很难将整体架构轻松迁移到其他开源平台上。当然，对于构建大型互联网来说，更推荐首选开源架构，因为有很多成熟的案例和开源生态的支持（也会有很多坑，就看你是先踩坑，还是别人先踩修复。您再次使用它），以避免重新发明轮子并支付高昂的许可费用。对于难以迁移的应用，我个人推荐Linux、Mono、Nexus、Mysql、Redis等，架构也可以支持高并发、大数据量的互联网应用。
单机时代的图像服务器架构（集中式）
初期，由于时间限制，开发者水平也很有限等原因。因此，通常会在文件所在目录下直接创建一个子目录，用于保存用户上传的图片文件。如果按业务细分，可以在目录下创建不同的子目录进行区分。例如：\QA、\Face 等。
“/qa/test.jpg”等相对路径也保存在数据库表中。
用户访问如下：
程序上传和写入方法：
程序员A通过在web中配置物理目录D:\Web\\来写入文件。
程序员 B 根据相对路径通过 . 以此类推，然后也通过.
优点：最容易实现，不需要任何复杂的技术就可以将用户上传的文件成功写入指定目录。保存数据库记录和访问它们也非常方便。
缺点：上传方式混乱，严重不利于网站的扩展。
对于上面提到的最原始的架构，主要面临以下问题：
由于目录中的文件越来越多，如果容量不足，很难扩展分区（如D盘）的容量。只能在关机后更换容量更大的存储设备，然后再导入旧数据。
部署新版本（部署新版本前需要备份）和每日备份文件时，需要同时操作目录下的文件。如果考虑到流量的增加，后面会部署一个由多个web服务器组成的负载均衡集群，集群节点之间很难实时同步文件。
集群时代的图像服务器架构（实时同步）
在该站点下方，创建一个名为的新虚拟目录。由于虚拟目录的灵活性，在一定程度上可以替代物理目录，兼容原有的图片上传和访问方式。用户的访问方式依然是：
优点：配置更灵活，也兼容老版本的上传和访问方式。
由于是虚拟目录，它可以指向任何本地驱动器号下的任何目录。这样，您也可以通过访问外部存储来扩展单机容量。
缺点：部署为多个web服务器组成的集群，每个web服务器（集群节点）（虚拟目录下）之间需要实时去同步文件。由于同步效率和实时性的限制，很难保证一定的时间。每个节点上的文件完全相同。
基本架构如下图所示：
从上图可以看出，整个web服务器架构已经具备“可扩展性和高可用”，主要问题和瓶颈集中在多台服务器之间的文件同步上。
在上述架构中，只有这些web服务器可以相互“增量同步”，因此不支持文件的“删除和更新”操作的同步。
早期的想法是在应用程序级别进行控制。当用户在web1服务器上请求上传和写入时，它也会同步调用其他web服务器上的上传接口，这显然得不偿失。因此，我们选择使用类rsync的软件进行定期的文件同步，既节省了“复制轮子”的成本，又降低了风险。
在同步操作中，一般有两种经典模型，即推挽模型：所谓“拉”是指轮询获取更新，所谓“推送”是在发生变化后主动“推送”到其他机器发生。当然，也可以使用高级的事件通知机制来完成这样的动作。
在高并发写入的场景下，同步会有效率和实时性的问题，而且大量文件的同步也会消耗系统和带宽资源（跨网段更明显）。
集群时代图像服务器架构改进（共享存储）
遵循虚拟目录的方式，通过UNC（网络路径）实现共享存储（将虚拟目录指向UNC）
用户访问方式一：
用户访问方式2（可配置独立域名）：
支持在UNC位置配置独立域名，配置轻量级Web服务器实现独立镜像服务器。
优点：读写操作是通过UNC（网络路径）的方式进行的，可以避免多台服务器之间的同步问题。相对来说非常灵活，也支持扩容/扩容。支持配置为独立镜像服务器和域名访问，也完全兼容旧版本的访问规则。
缺点：但是UNC配置有点麻烦，会造成一定的（读、写、安全）性能损失。可能存在“单点故障”。如果存储层面没有raid或者更高级的容灾措施，也会造成数据丢失。
基本架构如下图所示：
在很多早期基于Linux开源架构的网站中，如果不想同步图片，可以使用NFS来实现。事实证明，NFS在高并发读写和海量存储方面存在一定的效率问题，并不是最好的选择，所以大部分互联网公司不会使用NFS来实现这样的应用。当然也可以通过内置的 DFS 来实现，但缺点是“配置复杂，效率未知，缺乏大量数据的实际案例”。此外，还有一些公司使用FTP或Samba来实现。
上述架构在上传/下载操作时都经过web （虽然这种共享存储的架构也可以配置独立的域名和站点来提供图片访问，但是上传和写入还是要经过web 。服务器），这无疑是对Web服务器的巨大压力。因此，更推荐使用独立的图片服务器和独立的域名来提供用户图片的上传和访问。
专用映像服务器/专用域名的好处
图像访问在服务器上非常耗费资源（因为它涉及操作系统的上下文切换和磁盘 I/O 操作）。分离后，Web/App 服务器可以更加专注于动态处理能力。
独立存储，更方便扩容、容灾和数据迁移。
浏览器（同域名下）并发策略限制，性能损失。
访问图片时，请求信息中总是包含信息，同样会造成性能损失。
方便图片访问请求的负载均衡，方便应用各种缓存策略（HTTP、Proxy Cache等）cdn加速会索引图片吗，更方便迁移到CDN。
…
