前言
最近稍微留意了一下各个文件存储系统的协议，发现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以后还得有下载时候需要回调给业务系统一个扣除金币的操作。
