前言
最近稍微留意了一下各个文件存储系统的协议,发现minio是LGPLV3, 而fastdfs 是GPL3,这些协议其实对于商业应用是一个大坑。故而寻找一些代替品。
go-fastdfs就是其中之一,官网在:
go-fastdfs
具体应用
其实可以直接查看官网教程的。
下面简单提一下大概流程,重点提一下有些业务需求的满足以及二次开发[例如,md5直到,多url转发同一文件等]。
简要部署流程
编译
首先从 github上下载源代码:
https://github.com/sjqzhang/go-fastdfs
然后使用本身自带脚本:
build.sh
进行编译— 当然了,你也可以自行编译的。
得到:
ps:我额外添加了部分参数进去–因为需要适配业务需求的。。。请无视。
然后执行命令运行程序:
./fileserver server
然后在浏览器上可以看到:
任意传一个文件,有:
到这里其实一个简单的原型部署就已经完成了,剩下的其实就是添加启动脚本,关闭脚本,或者添加它作为系统服务开机启动,然后前台进行对接上传文件。
服务器部署用脚本
下面顺便补充一下脚本:
start.sh
#!/bin/sh
touch log.log
nohup ./fileserver server >> log.log 2>&1 &
tail -f log.log
stop.sh
#!/bin/sh
ps -ef|grep "./fileserver server" |grep -v grep|awk '{printf $2}'|xargs kill -9
ps -ef|grep "./fileserver server"
DATE=`date +%Y-%m-%d-%H-%M` #获取当前系统时间
mkdir logs
mv log.log logs/${DATE}_log.log
具体管理界面
目前这个版本是没有完善的管理界面的,
api倒是有:
https://sjqzhang.github.io/go-fastdfs/api.html
界面的话,可能是以下这个:
可以查看一下:
如果需要完善管理后台,又是一个工作量了。
不足/弥补之处
权限限制 回调不灵活
但这里要提一下一些问题,或者需要弥补的地方:
具体可以看看自动生成的配置文件:
其中有一份内容是:
上传时候验证方式有几种。。但是,个人感觉还是得根据业务系统来决定是否能够上传或者下载–
比如:每个会员有自己的存储空间,空间有大有小的,那么这种情况怎么算?万一超过了会员空间怎么算?
还有,上传完成了需要尽心回调通知业务服务器的-----客户端进行回调就很不靠谱了。
那就是1、需要回调。
不同的业务系统可能对后续操作不一样,
例如,场景1:
如果是会员成功上传了头像,这时候就需要通知系统进行头像审核了【头像也不是随便能上传的啊,一不小心内容有问题是要进去喝咖啡的】。
例如,场景2:
某个供应商上传了合同,需要通知甲方进行查看。 等等。
所以,其实文件上传成功与否其实也可以是决定下一步业务的关键点来的。
所以。。。嗯,估计重新加业务逻辑进去。
例如,场景3:
积分下载。
某个文件的下载是有权限的,不同会员角色,例如,level2才能进行下载,而且下载完毕以后要扣除一定数量的金币,level2的扣除10个金币,level3的扣除5个金币,level4或以上的免费。这个时候除了authToken以后还得有下载时候需要回调给业务系统一个扣除金币的操作。