做者:孔凡勇php
如今几乎任何一个网站、Web App以及移动APP等应用都须要有图片展现的功能,对于图片功能从下至上都是很重要的。必需要具备前瞻性的规划好图片服务器,图片的上传和下载速度相当重要,固然这并非说一上来就搞很NB的架构,至少具有必定扩展性和稳定性。虽然各类架构设计都有,在这里我只是谈谈个人一些我的想法。前端
对于图片服务器来讲IO无疑是消耗资源最为严重的,对于web应用来讲须要将图片服务器作必定的分离,不然极可能由于图片服务器的IO负载致使应用崩溃。所以尤为对于大型网站和应用来讲,很是有必要将图片服务器和应用服务器分离,构建独立的图片服务器集群,构建独立的图片服务器其主要优点:node
1)分担Web服务器的I/O负载-将耗费资源的图片服务分离出来,提升服务器的性能和稳定性。python
2)可以专门对图片服务器进行优化-为图片服务设置有针对性的缓存方案,减小带宽网络成本,提升访问速度。nginx
3)提升网站的可扩展性-经过增长图片服务器,提升图片服务吞吐能力。web
从传统互联网的web1.0,历经web2.0时代以及发展到如今的web3.0,随着图片存储规模的增长,图片服务器的架构也在逐渐发生变化,如下主要论述三个阶段的图片服务器架构演进。正则表达式
初始阶段数据库
在介绍初始阶段的早期的小型图片服务器架构以前,首先让咱们了解一下NFS技术,NFS是Network File System的缩写,即网络文件系统。NFS是由Sun开发并发展起来的一项用于在不一样机器,不一样操做系统之间经过网络互相分享各自的文件。NFS server也能够看做是一个FILE SERVER,用于在UNIX类系统之间共享文件,能够轻松的挂载(mount)到一个目录上,操做起来就像本地文件同样的方便。apache
若是不想在每台图片服务器同步全部图片,那么NFS是最简单的文件共享方式。NFS是个分布式的客户机/服务器文件系统,NFS的实质在于用户间计算机的共享,用户能够联结到共享计算机并象访问本地硬盘同样访问共享计算机上的文件。具体实现思路是:编程
1)全部前端web服务器都经过nfs挂载3台图片服务器export出来的目录,以接收web服务器写入的图片。而后[图片1]服务器挂载另外两台图片服务器的export目录到本地给apache对外提供访问。
2) 用户上传图片
用户经过Internet访问页面提交上传请求post到web服务器,web服务器处理完图片后由web服务器拷贝到对应的mount本地目录。
3)用户访问图片
用户访问图片时,经过[图片1]这台图片服务器来读取相应mount目录里边的图片。
以上架构存在的问题:
1)性能:现有结构过分依赖nfs,当图片服务器的nfs服务器有问题时,可能影响到前端web服务器。NFS的问题主要是锁的问题. 很容易形成死锁, 只有硬件重启才能解决。尤为当图片达到必定的量级后,nfs会有严重的性能问题。
2)高可用:对外提供下载的图片服务器只有一台,容易出现单点故障。
3) 扩展性:图片服务器之间的依赖过多,并且横向扩展余地不够。
4) 存储:web服务器上传热点不可控,形成现有图片服务器空间占用不均衡。
5) 安全性:nfs方式对于拥有web服务器的密码的人来讲,能够随意修改nfs里边的内容,安全级别不高。
固然图片服务器的图片同步能够不采用NFS,也能够采用ftp或rsync,采用ftp这样的话每一个图片服务器就都保存一份图片的副本,也起到了备份的做用。可是缺点是将图片ftp到服务器比较耗时,若是使用异步方式去同步图片的话又会有延时,不过通常的小图片文件也还好了。使用rsync同步,当数据文件达到必定的量级后,每次rsync扫描会耗时好久也会带来必定的延时性。
发展阶段
当网站达到必定的规模后,对图片服务器的性能和稳定性有必定的要求后,上述NFS图片服务架构面临着挑战,严重的依赖NFS,并且系统存在单点机器容易出现故障,须要对总体架构进行升级。因而出现了上图图片服务器架构,出现了分布式的图片存储。
其实现的具体思路以下:
1)用户上传图片到web服务器后,web服务器处理完图片,而后再由前端web服务器把图片post到到[图片1]、[图片2]…[图片N]其中的一个,图片服务器接收到post过来的图片,而后把图片写入到本地磁盘并返回对应成功状态码。前端web服务器根据返回状态码决定对应操做,若是成功的话,处理生成各尺寸的缩略图、打水印,把图片服务器对应的ID和对应图片路径写入DB数据库。
2) 上传控制
咱们须要调节上传时,只须要修改web服务器post到的目的图片服务器的ID,就能够控制上传到哪台图片存储服务器,对应的图片存储服务器只须要安装nginx同时提供一个python或者php服务接收并保存图片,若是不想不想开启python或者php服务,也能够编写一个nginx扩展模块。
3) 用户访问流程
用户访问页面的时候,根据请求图片的URL到对应图片服务器去访问图片。
如: http://imgN.xxx.com/image1.jpg
此阶段的图片服务器架构,增长了负载均衡和分布式图片存储,可以在必定程度上解决并发访问量高和存储量大的问题。负载均衡在有必定财力的状况下能够考虑F5硬负载,固然也能够考虑使用开源的LVS软负载(同时还可开启缓存功能)。此时将极大提高访问的并发量,能够根据状况随时调配服务器。固然此时也存在必定的瑕疵,那就是可能在多台Squid上存在同一张图片,由于访问图片时可能第一次分到squid1,在LVS过时后第二次访问到squid2或者别的,固然相对并发问题的解决,此种少许的冗余彻底在咱们的容许范围以内。在该系统架构中二级缓存可使用squid也能够考虑使用varnish或者traffic server,对于cache的开源软件选型要考率如下几点
1)性能:varnish自己的技术上优点要高于squid,它采用了“Visual Page Cache”技术,在内存的利用上,Varnish比Squid具备优点,它避免了Squid频繁在内存、磁盘中交换文件,性能要比Squid高。varnish是不能cache到本地硬盘上的。还有强大的经过Varnish管理端口,可使用正则表达式快速、批量地清除部分缓存。nginx是用第三方模块ncache作的缓冲,其性能基本达到varnish,但在架构中nginx通常做为反向(静态文件如今用nginx的不少,并发能支持到2万+)。在静态架构中,若是前端直接面对的是cdn活着前端了4层负载的话,彻底用nginx的cache就够了。
2)避免文件系统式的缓存,在文件数据量很是大的状况下,文件系统的性能不好,像squid,nginx的proxy_store,proxy_cache之类的方式缓存,当缓存的量级上来后,性能将不能知足要求。开源的traffic server直接用裸盘缓存,是一个不错的选择,国内大规模应用并公布出来的主要是淘宝,并非由于它作的差,而是开源时间晚。Traffic Server 在 Yahoo 内部使用了超过 4 年,主要用于 CDN 服务,CDN 用于分发特定的HTTP 内容,一般是静态的内容如图片、JavaScript、CSS。固然使用leveldb之类的作缓存,我估计也能达到很好的效果。
3)稳定性:squid做为老牌劲旅缓存,其稳定性更可靠一些,从我身边一些使用者反馈来看varnish偶尔会出现crash的状况。Traffic Server在雅虎目前使用期间也没有出现已知的数据损坏状况,其稳定性相对也比较可靠,对于将来我其实更期待Traffic Server在国内可以拥有更多的用户。
以上图片服务架构设计消除了早期的NFS依赖以及单点问题,时可以均衡图片服务器的空间,提升了图片服务器的安全性等问题,可是又带来一个问题是图片服务器的横向扩展冗余问题。只想在普通的硬盘上存储,首先仍是要考虑一下物理硬盘的实际处理能力。是 7200 转的仍是 15000 转的,实际表现差异就很大。至于文件系统选择xfs、ext三、ext4仍是reiserFs,须要作一些性能方面的测试,从官方的一些测试数据来看,reiserFs更适合存储一些小图片文件。建立文件系统的时候 Inode 问题也要加以考虑,选择合适大小的 inode size ,由于Linux 为每一个文件分配一个称为索引节点的号码inode,能够将inode简单理解成一个指针,它永远指向本文件的具体存储位置。一个文件系统容许的inode节点数是有限的,若是文件数量太多,即便每一个文件都是0字节的空文件,系统最终也会由于节点空间耗尽而不能再建立文件,所以须要在空间和速度上作取舍,构造合理的文件目录索引。
云存储阶段
2011年李彦宏在百度联盟峰会上就提到过互联网的读图时代已经到来,图片服务早已成为一个互联网应用中占比很大的部分,对图片的处理能力也相应地变成企业和开发者的一项基本技能,图片的下载和上传速度显得更加剧要,要想处理好图片,须要面对的三个主要问题是:大流量、高并发、海量存储。
阿里云存储服务(OpenStorageService,简称OSS),是阿里云对外提供的海量,安全,低成本,高可靠的云存储服务。用户能够经过简单的 REST接口,在任什么时候间、任何地点上传和下载数据,也可使用WEB页面对数据进行管理。同时,OSS提供Java、Python、PHP SDK,简化用户的编程。基于OSS,用户能够搭建出各类多媒体分享网站、网盘、我的企业数据备份等基于大规模数据的服务。在如下图片云存储主要以阿里云的云存储OSS为切入点介绍,上图为OSS云存储的简单架构示意图。
真正意义上的“云存储”,不是存储而是提供云服务,使用云存储服务的主要优点有如下几点:
1)用户无需了解存储设备的类型、接口、存储介质等。
2)无需关心数据的存储路径。
3)无需对存储设备进行管理、维护。
4)无需考虑数据备份和容灾
5)简单接入云存储,尽情享受存储服务。