图片服务器 大型网站图片服务器架构的演进

声明:版权归作者丁朗所有。转载请联系作者。

第一，碑文

在主流网站中，图片往往是不可或缺的页面元素，尤其是在大型网站中，几乎所有的图片都会面临“海量图片资源”的存储和访问等相关技术问题。图像服务器架构的扩展有很多波折，甚至是血泪。

二、单机时代的影像服务器架构

在初期，由于时间限制和开发者水平有限等原因。所以通常会在网站文件所在的目录下直接设置一个上传子目录，用来保存用户上传的图片文件。如果按业务细分，可以在上传目录下创建不同的子目录来区分。

例如uploadQA、uploadFace等。

相对路径如“upload/qa/test.jpg”也保存在数据库表中。

用户访问如下:

http://www.yourdomain.com/upload/qa/test.jpg

程序的上传和编写方法:

程序员A在web.config中配置物理目录D:Webyourdomainupload，然后将文件写入流。

程序员乙通过服务器根据相对路径获取物理目录。然后通过流的方式写入文件。

优点:实现最简单，用户上传的文件不需要任何复杂的技术就可以成功写入指定的目录。保存和访问数据库记录也很方便。

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

鉴于上述原始建筑，主要面临以下问题:

随着上传目录中文件越来越多，如果容量不足，很难扩展其所在分区的容量。您只能在停机后更换容量更大的存储设备，然后导入旧数据。

在部署新版本和每天备份网站文件时，需要同时操作上传目录中的文件。如果在后台部署由多个Web服务器组成的负载均衡集群，集群节点之间的文件实时同步将是一个难题。

第三，集群时代的镜像服务器架构

在网站下，创建一个名为upload的新虚拟目录。由于虚拟目录的灵活性，可以在一定程度上代替物理目录，并且与原有的图片上传和访问方式兼容。用户的访问方法仍然是:

http://www.yourdomain.com/upload/qa/test.jpg

优点:配置更灵活，也兼容旧版本的上传和访问方式。

由于虚拟目录，您可以指向任何本地驱动器号下的任何目录。通过这种方式，可以通过访问外部存储来扩展单台机器的容量。

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

基本架构如下图所示:

从上图可以看出，整个Web服务器架构是“可扩展、高可用”的，主要问题和瓶颈集中在多台服务器之间的文件同步上。

在上述架构中，只有这些Web服务器可以彼此“增量同步”，因此不支持文件“删除和更新”操作的同步。

早期的想法是，当用户请求在web1服务器上上传写的时候，也同步调用其他web服务器上的上传接口，显然是不付费的。所以我们选择使用Rsync软件定期同步文件，节省了“重复制作轮子”的成本，降低了风险。

在同步操作中，一般有两种经典模式，即推拉模式:所谓“拉”是指轮询获取更新，所谓“推”是指主动“推”更改到其他机器。当然，也可以使用高级事件通知机制来完成此类操作。

在高并发写的场景下，同步会出现效率和实时性的问题，大量的文件同步也会消耗系统和带宽资源。

第四，集群时代的映像服务器架构改进

遵循虚拟目录的方式，通过UNC实现共享存储

用户访问方法1:

http://www.yourdomain.com/upload/qa/test.jpg

用户访问模式2:

http://img.yourdomain.com/upload/qa/test.jpghttp://img.yourdomain.com/upload/qa/test.jpg

支持UNC服务器配置独立域名指向，配置轻量级web服务器实现独立图片服务器。

优点:读写操作由UNC执行，可以避免多台服务器之间的同步相关问题。相对灵活，也支持扩展/扩充。支持配置独立图片服务器和域名访问，也完全兼容旧版本的访问规则。

缺点:但是UNC配置有点繁琐，会造成一定的性能损失。可能会出现“单点故障”。如果存储级别没有raid或更高级别的灾难恢复措施，也会导致数据丢失。

基本架构如下图所示:

在很多早期基于Linux开源架构的网站，如果不想同步图片，可以用NFS。事实证明，NFS在高并发读写和海量存储效率上存在一些问题，不是最佳选择，所以大多数互联网公司不会使用NFS来实现这样的应用。当然也可以用Windows自带的DFS来实现，缺点是“配置复杂，效率未知，缺少大量数据的实际案例”。此外，有些公司使用FTP或Samba来实现。

以上提到的架构在上传/下载时都要经过Web服务器，这无疑给Web服务器造成了很大的压力。因此，建议使用独立的图片服务器和独立的域名为用户提供上传和访问图片的功能。

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

映像访问消耗服务器资源。分离后，Web/App服务器可以专注于动态处理。

独立存储，更方便做扩容、容灾和数据迁移。浏览器（相同域名下的）并发策略限制，性能损失。访问图片时，请求信息中总带cookie信息，也会造成性能损失。方便做图片访问请求的负载均衡，方便应用各种缓存策略（HTTP Header、Proxy Cache等），也更加方便迁移到CDN。

......

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

第六，当前的图像服务器架构

目前的图片服务器架构采用分布式文件系统+CDN

在构建目前的图片服务器架构之前，我们可以完全抛开web服务器，直接单独配置一个图片服务器/域名。但它面临以下问题:

旧图片数据怎么办？能否继续兼容旧图片路径访问规则？独立的图片服务器上需要提供单独的上传写入的接口（服务API对外发布），安全问题如何保证？同理，假如有多台独立图片服务器，是使用可扩展的共享存储方案，还是采用实时同步机制？

直到应用级DFS的普及，这个问题得到了简化:冗余备份，支持自动同步，支持线性扩展，支持主流语言的上传/下载/删除客户端API等。，有些支持文件索引，有些支持提供网络访问。

考虑到DFS的特点，客户端API语言支持，文档和案例，以及社区支持，最终选择FastDFS进行部署。

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

第七，解决方案如下:

首先关闭旧版本上传门户。通过rsync工具将旧图像数据一次性迁移到独立的图像服务器。在前端，使用ACL将旧图片对应的URL规则的请求匹配到，然后将请求直接转发到指定的web服务器列表，并在列表中的服务器上配置提供图片访问的站点，并添加缓存策略。这样，旧图片服务器被分离缓存，与旧图片访问规则兼容，提高了旧图片访问效率，避免了实时同步带来的问题。

总体结构如下:

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

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

由于商业CDN服务，我们没有考虑使用Squid/Vanish来构建预代理缓存。

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

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

综上所述，镜像服务器架构的扩展围绕着这些问题:

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