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

《大型网站图片服务器架构的演进》要点：
本文介绍了大型网站图片服务器架构的演进，希望对您有用。如果有疑问，可以联系我们。

在主流的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的方式写入文件.

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

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

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

1. 随着upload目录中文件越来越多,所在分区(例如D盘)如果出现容量不足,则很难扩容.只能停机后更换更大容量的存储设备,再将旧数据导入.
2. 在部署新版本(部署新版本前通过需要备份)和日常备份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或者更高级的灾备措施,还会造成数据丢失.

基本架构如下图所示：

（编辑：ASP站长网）