华纳云：WindowsPlatform网站图片服务器架构的演变。

建立在 Windows平台之上的网站，很多行业的架构师都会认为它是“保守的”。大多数原因是由于微软技术系统的封闭和部分技术员的目光短浅。长期以来缺乏对开源软件的支持，因此只能“闭门造车”，这样很容易形成思维的局限和缺陷。以图片服务器为例，如果前期没有容量规划和可扩展设计，那么随着图片文件的不断增加和访问量的增加，由于设计中在性能、容错/容灾、扩展性等方面的缺陷，后续的开发、运营工作将出现许多问题，严重时甚至会影响到网站的正常运行和互联网公司的发展(这绝不是危言耸听)。

为什么选择 Windows平台来构建网站和图片服务器，主要是因为创始团队的技术背景，早期的技术人员可能对. NET比较熟悉，或者主管认为 Windows/. NET的易用性、“短而快”的开发模式、人才成本等方面与创业初期的团队比较匹配，自然选择 Windows。在业务扩展到一定规模之后，要将整个体系结构迁移到其他平台也非常困难。当然，在构建大规模互联网时，最好选择开放源码架构，因为有许多成熟的例子和开放源码生态的支持，可以避免重复工作和花费授权成本。在难以移植的应用中，比较推荐 Linux、 Mono、 Mysql、 Memcahed…混合架构，它们同样支持高并发访问和大数据。为什么选择 Windows平台来构建网站和图片服务器，主要是因为创始团队的技术背景，早期的技术人员可能对. NET比较熟悉，或者主管认为 Windows/. NET的易用性、“短而快”的开发模式、人才成本等方面与创业初期的团队比较匹配，自然选择 Windows。在业务扩展到一定规模之后，要将整个体系结构迁移到其他平台也非常困难。当然，在构建大规模互联网时，最好选择开放源码架构，因为有许多成熟的例子和开放源码生态的支持，可以避免重复工作和花费授权成本。在难以移植的应用中，比较推荐 Linux、 Mono、 Mysql、 Memcahed…混合架构，它们同样支持高并发访问和大数据。

单机时代的图片服务器架构（集中式）

创业初期由于时间紧迫，开发者的数量有限等原因。因此，一般直接在 website文件所在的目录下，建立一个 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的方式写入文件。

优点：实现起来最简单，无需任何复杂技术，就能成功将用户上传的文件写入指定目录。保存数据库记录和访问起来倒是也很方便。

缺点：上传方式混乱，严重不利于网站的扩展。

针对上述最原始的架构，主要面临着如下问题：

随着上传目录中文件数量的增加，如果容量不足，很难扩展分区(如磁盘D)的容量。您只能在停机后更换容量更大的存储设备，然后导入旧数据。在部署新版本(部署新版本前需要备份)和每天备份网站文件时，需要同时操作上传目录中的文件。如果在后台部署由多个Web服务器组成的负载均衡集群，集群节点之间的文件实时同步将是一个难题。
　　集群时代的图片服务器架构（实时同步）

在网站下，创建一个名为upload的新虚拟目录。由于虚拟目录的灵活性，可以在一定程度上代替物理目录，并且与原有的图片上传和访问方式兼容。用户的访问方式还是:http://www.yourdomain.com/upload/qa/test.jpg.优势:配置更灵活，可以兼容旧版的上传和访问方式。由于虚拟目录，您可以指向任何本地驱动器号下的任何目录。通过这种方式，可以通过访问外部存储来扩展单台机器的容量。

缺点:当部署在由多个网络服务器组成的集群中时，网络服务器(集群节点)(在虚拟目录下)之间需要文件的实时去同步。由于同步效率和实时性的限制，很难保证每个节点上的文件在某个时间完全一致。

基本架构如下图所示：

从上图可以看出，整个Web服务器架构是“可扩展、高可用”的，主要问题和瓶颈集中在多台服务器之间的文件同步上。在上述架构中，只有这些Web服务器可以彼此“增量同步”，因此不支持文件“删除和更新”操作的同步。

早期的想法是，当用户请求在web1服务器上上传写的时候，也同步调用其他web服务器上的上传接口，显然是不付费的。所以我们选择使用Rsync软件定期同步文件，节省了“重复制作轮子”的成本，降低了风险。早期的想法是，当用户请求在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服务器造成了很大的压力。因此，建议使用独立的图片服务器和独立的域名为用户提供上传和访问图片的功能。。

独立图片服务器/独立域名的好处

映像访问消耗服务器资源(因为涉及操作系统上下文切换和磁盘I/O操作)。分离后，Web/App服务器可以专注于动态处理。独立存储更便于容量扩展、灾难恢复和数据迁移。浏览器(同域名下)并发策略限制，性能损失。在访问图片时，cookie信息总是包含在请求信息中，这也会导致性能损失。方便负载均衡图片访问请求，应用各种缓存策略(HTTP Header，Proxy Cache等)。)并迁移到CDN。
　　…

我们可以使用Lighttpd或者Nginx等轻量级的web服务器来架构独立图片服务器。

当前的图片服务器架构（分布式文件系统+CDN）

在构建当前的图片服务器架构之前，可以先彻底撇开web服务器，直接配置单独的图片服务器/域名。但面临如下的问题：

旧图片数据怎么办？能否继续兼容旧图片路径访问规则？
独立的图片服务器上需要提供单独的上传写入的接口（服务API对外发布），安全问题如何保证？
同理，假如有多台独立图片服务器，是使用可扩展的共享存储方案，还是采用实时同步机制？
　　直到应用级(非系统级)DFS(如FastDFS HDFS MogileFs MooseFS，TFS)的普及，这个问题得到了简化:冗余备份，支持自动同步，支持线性扩展，支持主流语言的上传/下载/删除客户端API等。，有些支持文件索引，有些支持提供网络访问。。

考虑到各DFS的特点，客户端API语言支持情况(需要支持C#)，文档和案例，以及社区的支持度，我们最终选择了FastDFS来部署。

唯一的问题是它可能与旧版本的访问规则不兼容。如果将旧图片一次性导入FastDFS，但由于旧图片的访问路径分布存储在不同业务数据库的各种表中，整体更新非常困难，所以必须兼容旧版本的访问规则。升级架构往往比制作一个全新的架构更困难，因为它与以前的版本兼容。在空中更换飞机发动机比制造飞机要困难得多

解决方案如下：

首先关闭旧版本上传门户(避免继续使用造成数据不一致)。通过rsync工具将旧图像数据一次性迁移到独立的图像服务器(即下图中描述的旧图像服务器)。在前端(七层代理，如Haproxy、Nginx)，使用ACL(访问规则控制)将旧图片对应的URL规则的请求(常规)匹配到，然后将请求直接转发到指定的web服务器列表，并在列表中的服务器上配置提供图片访问(Web模式)的站点，并添加缓存策略。这样，旧图片服务器被分离缓存，与旧图片访问规则兼容，提高了旧图片访问效率，避免了实时同步带来的问题。

整体架构如图：

虽然基于FastDFS的独立图片服务器集群架构已经很成熟，但是由于国内“南北互联”和IDC带宽成本的问题(图片非常耗费流量)，我们最终选择了商用的CDN技术，也非常容易实现，原理其实也很简单。这里我只简单介绍一下:

img域名cname发送到CDN厂商指定的域名。当用户请求访问图片时，CDN厂商提供智能DNS解析，并返回最近服务节点的地址(当然，可能还有其他更复杂的策略，比如负载情况、健康状态等。)给用户。用户请求到达指定的服务器节点，该节点提供类似于Squid/Vanish的代理缓存服务。如果第一次请求此路径，将从源站点获取图像资源并将其返回给客户端浏览器。如果它存在于缓存中，它将直接从缓存中获得，并返回给客户端浏览器以完成请求/响应过程。

由于采用了商用CDN服务，所以我们并没有考虑用Squid/Vanish来重复构建前置代理缓存。

上面的整个集群架构很容易横向扩展，可以满足一般垂直领域大型网站的图片服务需求(当然像淘宝那样超大型的可能性就另当别论了)。经过测试，提供映像访问的单个Nginx服务器(至强E5四核CPU、16G内存、SSD)可以承受数万个小型静态页面(压缩)的并发，没有任何压力。当然，由于镜像本身比纯文本的静态页面大得多，提供镜像访问的服务器的抗并发能力往往受限于磁盘的I/O处理能力和IDC提供的带宽。Nginx的抗并发能力很强，占用的资源很少，尤其是处理静态资源的时候，似乎不用太担心。可以根据实际流量的需求，通过调整Nginx参数、Linux内核调优、缓存策略等手段进行更大程度的优化，也可以通过增加服务器或升级服务器配置进行扩展。最直接的方式是购买更高级的存储设备和更大的带宽，以满足更大流量的需求。

值得一提的是，随着“云计算”的普及，也推荐使用“云存储”方案，既能帮你解决各种存储、扩容、备灾问题，又能加速CDN。最重要的是，价格不贵。。

总结，有关图片服务器架构扩展，大致围绕这些问题展开：

容量规划和扩展。数据同步、冗余和容灾。硬件设备的成本和可靠性(无论是普通机械硬盘、SSD，还是更高端的存储设备和解决方案)。文件系统的选择。根据文件特征(如文件大小、读/写比等。)，ext3/4或NFS/GFS/TFS被选为开源(分布式)文件系统。加速获取图片。采用商用CDN或自建代理缓存和web静态缓存架构。旧图片路径和访问规则的兼容性、应用层的可扩展性、上传和访问的性能和安全性等。容量规划和扩展。数据同步、冗余和容灾。硬件设备的成本和可靠性(无论是普通机械硬盘、SSD，还是更高端的存储设备和解决方案)。文件系统的选择。根据文件特征(如文件大小、读/写比等。)，ext3/4或NFS/GFS/TFS被选为开源(分布式)文件系统。加速获取图片。采用商用CDN或自建代理缓存和web静态缓存架构。旧图片路径和访问规则的兼容性、应用层的可扩展性、上传和访问的性能和安全性等。