一、前言
每一个小团队都是希望发展壮大的~~~
现在几乎任何一个网站、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