做为使用最广泛, 最最基础的图床服务, 业界几乎每家大点的公司可能都有自己的解决方案.具体到某一家厂商, 对于图片存储的需求的层次 决定 图片服务系统设计的结构, 简要的分几个层次吧：
初级: 还有些人在乎的中小网站.
图片偏多, 需要简单的组织和管理.
一般可能还是把图片存储到文件系统里面 按照目录+ 文件的组织形式. 本地 或者 NFS 的文件系统里面, 这里是我理解的一些小点:- 不要使用中文, 空格, 特殊字符...之类的做文件名!!!
- 对于UGC网站, 不拿用户上传的图片文件名做为文件名直接存储.
- 用户的文件名会各种不规范, 容易有冲突, 另外存起来.
- 按 时间 / 用户 等业务逻辑做目录的划分.
- 更利于组织和管理, 避免冲突文件名导致覆盖(用户头像存储等Case).
- 也避免一个目录下文件过多, 导致查询性能
- 必要时可能要多级的目录.
- 避免过长的文件名.
- 避免修改文件内容
- 修改后的图片存为另一个图片
- 为缩略图做预处理
- 最好是就只用特定的几个尺寸.
- 不能满足需求的话, 可以预存大, 中, 小, 原图等几个级, 其他尺寸由邻近级去实时转换.
- 不同尺寸的文件, 而且大小之间可以相互换算.
- Eg: 图片大小命名的目录.
- 不要用连续递增的数字做文件id
- 避免图片被直接遍历爬走了
- logo 等常用图片独立存储.
- 避免文件路径的变更.
- 各处本地缓存, 引用 都会失效...
中级: 适合较大型的网站
普通的文件系统已经不能很好满足需求了:- 运维管理的考虑
- 超过单机的容易, 多机来存储导致各种图片的增减, 管理成本非常的大
- 性能的考虑
- 文件系统的开销过大
- 多次的IO和网络交互
- 成本的考虑
- 容灾的考虑
这个一般使用 通用的对象存储, 类似S3的服务, 会增加一些CDN之类的.
在组织管理这一块, 虽然不再是本地的文件系统, 但是原理和想法 和 前面基本一样.
高级: 适合大型的网站
相对于更强调通用性和业务灵活性的S3存储服务, 图片服务的文件名一般都是专有的规则, 因为就这个单一的服务就已经足够的大, 值得去做一些专门的定制和优化.
比如说:- 存储信息直接Encode进文件名, 省去文件名到存储路径的查询.
- 更好的缓存支持, CDN的调度
- 极端热点的处理
- 冷数据的淘汰和Archive
- 专门的硬件支持 (针对图片访问特别的机器定制.)
- ...