将演进历程讲的很清楚。
使用rsync做文件增量同步，或者NFS做网络共享存储都搞过，这种还是适应偏传统的普通场合，应对移动互联网的大并发感觉力不从心。
CDN和云存储没有用过，不做评论了。
我们当前的方案是自己做的file_server，提供HTTP的上传、下载接口，单点。
流程是：用户A通过HTTP上传文件到file_server，file_server将其存储到磁盘，生成文件地址，返给A，A将文件地址发给业务服务，入库。
我当前在规划的方案也是在原基础上扩展，设计出的架构如图片所示，请帮指点下不足的地方。新方案有如下特点：
1.客户端缓存服务地址，由客户端进行业务数据路由，这样就路由方案来说整体改动最小，服务端不需要做额外的工作
2.file_server支持动态扩容，且扩容后不影响路由规则，保证业务数据的单调性，用户对某个文件的请求一定会落到存储该文件的服务上去
3.文件地址使用domain而不是ip，当某台服务所在主机ip变动时，客户端只需要修改其domain和ip的映射配置即可，能解决数据库内使用ip:path/file的方式在这种情况下导致文件找不到的问题
4.file_server几乎是无状态的，分布式部署，可以随意增减，提升并发性能
5.每个file_server可以做成热备，双机之间使用共享存储，保证高可用，图上没有画出来。

引用：JackJiang 发表于 2019-07-04 18:52
你这种架构灵活性好差，不管是磁盘变动还是域名变动，都会导致你数据读取的变动，维护太麻烦。

你考虑 ...

是的，您说的问题，确实存在。
数据库里存的是domain1:path/file1这种绝对地址，domain发生变动后，从库里拿出的地址去读取数据会有问题。
客户端调用需要多做一些工作，登录的时候从登录服务那里拿到file_server的服务列表，缓存domain信息，上传文件时候不需要domain，PUT(file)，随机选一个domain，获取文件从库拿出domain1:path/file1，GET(domain, file)。
改造思路是总体改造成本最低，不是最优，有些偷懒

至于对客户端透明的方案，上午我又想了下，可以参考mongos的方案。
客户端只需要PUT(FILE), GET(FILE)，文件的寻址由服务端处理。
您看下这里还有什么不妥的地方，谢谢了

您说的问题，确实存在。
当前改造的思路是总体最小成本，而不是最优，所以并没有做太多的设计。想偷懒
下面是新的方案，参考了mongos