一、前言
每一个小团队都是希望发展壮大的~~~
现在几乎任何一个网站、Nativ App、Web
App等都有图片展示的功能,对于图片功能从下至上都是很重要的。必须要具有前瞻性的规划好图片服务器,当然这并不是说一上来就搞很NB的架构,至少具备一定扩展性。虽然各种架构设计都有,在这里我只是谈谈我的想法。
二、需求
1.原始图片上传到服务器
2.根据业务把图片压缩到指定尺寸,这一需求无论何时都有可能发生变化,同一个图片你不知道什么时候产品经理会说要加另一种尺寸!
3.多个前端服务器要共享图片
三、架构设计及实现
1.初步架构
1) 用户A从Web1上传的图片,在Web2…WebN上都能正常访问,采用NFS(有钱的可以使用专业的存储设备)
2)图片直接从WebN上返回给用户的速度,已经快WebN->图片服务器->用户,WebN上做缓存
3)图片需要满足各种尺寸,采用保存原始图,动态压缩小图的方式,替代上传时的压缩图片的操作
4)便于迁移和多图片节点,图片目录独立于项目目录,使用新域名访问,有条件的可以使用新的独立域名访问(独立域名好于二级域名的原因可以在网上找到一堆)
2.架构变迁
上图箭头表示数据流向,作为一个小团队来说,此时的设计已经完全满足了。
3.架构实现
1)用户上传,直接保存原始图,在Web前端的项目里,不对图片作处理,直接保存到“共享文件系统服务器”
2)存储路径设计
A. 共享文件系统里面,按项目目录管理,比如/var/static/img/photo 就代表项目photo
B. 文件名采用对Unix时间戳的md5
C. 目录前缀可取文件名的前一位或两位
/upload/origin/c/b/cb123fa34243242aa….png,取决于项目的大小,origin代表原始大小
upload代表项目目录的upload目录,作为软连接的标识
3)访问图片 比如80×80的大小
http://img1.xiongchuan.org/photo/upload/80×80/c/b/cb123fa34243242aa….png
4)图片服务器处理并返回图片
A. 配置Web Server的404页面到,图片目录里面的404.php
B. 当图片不存在时,命中404.php,此程序根据REDIRECT_URL(来源URL),匹配得到项目名:photo,尺寸:80×80,文件路
径:/c/b/cb123fa34243242aa….png,此时就可以根据photo项目的配置,读取数据,缓存到
img1.xiongchuan.org图片目录下,再按尺寸80×80压缩,并保存在图片目录下,然后返回结果
C. 再次访问图片时,图片存在直接经过Web Server返回,不再调用PHP
D. XImageServer 就是根据上面的设计进行的实现,可以方便使用
4.负载扩展
图片服务器,需要把很轻松的增加 XImageServer 的图片目录即可,前端使用LVS或Nginx作负载均衡,此种方式避免了使用的,图片主动推送方式作负载均衡,操作非常简单。
四、使用建议
1.图片尺寸经常变化,解决此类问题非常适合
2.Web端上传变的异常简单,不需要很复杂的图片处理程序
3.架构原理通用,可以根据此原理,实现自己特有的图片服务器
4.此架构适合团队发展期间,主要是为了解决从程序员到运维开发难度和运维成本
5.当项目发展到一定时期(哪个时期?例如你资金充足)可以使用世面上的CDN,如友拍云等,能够轻松迁移。
==================================================================
之前使用的项目,开源地址:https://gitcafe.com/xiongchuan86/XImageServer