分布式文件存储服务

背景：

分布式存储的需求不多说，主要说下为什么要在fastDFS上再做一层呢，暂时叫kano吧，随便取的；

1. 如果业务系统直接连FastDFS，FastDFS的storeage不能做到很好的管理，比如头像、证书、聊天图片等业务存储，容易交叉存储在各个Storeage分组；
2. 有些文件可能是长期存储的，有些文件可能是有时效的；
3. 后期FastDFS到底存了多少业务文件，不易整理，没有一个统一的记录的地方；
4. fastDFS有开源监控后台，但是还缺乏管理平台；

存储系统的定义

一方面方便文件管理，提供统一的文件管理接口（DFS一般只负责存储)，另一方面负责DFS监控；

主要功能：

1. 文件存储统一入口
2. 文件下载统一入口
3. 文件查询和管理
4. 存储的物理机器管理和监控

特性要求：

1. 分布式、无单点、可动态扩容
2. 支持多个FastDFS集群管理
3. 支持指定分组存储，方便服务器管理（区别fastDFS的group)
4. 文件下载的安全控制（如防止遍历、url过期机制）

架构

大致架构：

大致流程：

一些问题：

1. fastdfs包一层以后的性能，如上传（选用了dubbo hessian）和下载都经过了kano-service
2. FastDFS动态扩组后，文件处理和负载均衡
   如现有A、B组，存储已经快用完了，添加C组来扩容，如果使用剩余空最多来轮询，就会把上传的压力加到C组；
   
   

文件下载ID转换的nginx配置：

当用户访问URL  http://fs.static.xxx.com/1 时nginx会请求到API，API会返回一个头部参数为X-Accel-Redirect ，值为真实路径，nginx通过内部调用访问storage_server所在的nginx
#指定storage_server所在nginx的IP和端口
 upstream fastdfs-cluster {
server 192.168.1.125:80;
server 192.168.1.126:80;
}
 #指定API服务器的IP的端口
upstream efcproxy.server{
server 192.168.1.104:20705; 
} 
server {
listen 80; 
server_name fs.static.xxx.com;
charset utf-8;
access_log /var/log/nginx-access/fdfs.static.xxx.com.log main;
location / { 
proxy_pass http://efcproxy.server/w/idmap/;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
} 
location /G1/M00/{
proxy_pass http://fastdfs-cluster;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
} 
}

性能测试：

还没测