闲聊文件存储的设计

故事

文件上传（如图片）等几乎是每个项目的标配了。

不管用不用第三方存储，相信不少团队都会针对文件上传、下载单独封装一个服务。

这里面的细节设计就多种多样了。

对于安全级别低的项目，有客户端直接访问文件服务，上传直接返回可访问的url的（也不用考虑删除，企业内部系统，没多少数据，硬盘值几个钱🤡）。

这种简单粗暴，说实话也挺省事的，哈哈

有安全级别较高的，上传下载都靠业务系统中转，业务系统里先按用户权限进行校验，通过后才返回文件流。

观点

关于文件服务（假设已经有了七牛云等oss，这里只讨论文件服务与业务系统集成的部分），我感觉设计点主要就两个。

一是垃圾清理，二是权限。

垃圾清理

垃圾清理相对来说是个比较简单的事，就是业务数据都删掉了，这个文件如果也不需要了，就该把这个文件也一并清理掉。
不然日积月累也会有非常多的游离文件，白白浪费存储。
但这其实也没什么技术难度，只是大家单纯不想费力气去做而已。
毕竟对于大多数数据量不大的小系统来说，影响不大，三五年后自己都不在这个公司了🤡。

权限

权限才是件麻烦事。

如果张三把自己访问的图片url复制出来发给本没有权限的李四，李四访问的时候请求该被拦截掉。
我是倾向于把文件服务当一个大硬盘+扩展服务来用的。
客户端对文件服务是无感知的，始终请求业务系统。业务系统校验权限通过后，就去文件服务读取文件流再返回给客户端。

所谓大硬盘的意思就是，业务系统无需关注文件存储的容量、备份、高可用等问题。
所谓扩展服务的意思就是，文件服务可以额外扩展一些图片压缩、水印、格式转换（word转pdf）等。

举个例子，一个销售订单里附有一个图片，根据当前登录账号动态加水印。
张三访问的时候图片上的水印是张三。李四访问的时候图片上的水印是李四。

如果张三直接把图片的url拷贝出来给其他人， 因为该url是业务系统提供的，所以其他人直接访问url的时候依旧会触发登录拦截。 发给本没有权限的王五，王五照样是不可访问。
发给有权限的李四，李四访问的时候水印也是李四的。

如果你觉得本文对你有帮助或不错，可略表心意，请我喝一杯冰可乐。 ☕