dilu

文件系统，我理解就是图片视频之类的静态资源呗？假设是这样的话那就很简单啊 甚至都不用停机

首先，假定原本的数据源为 A ，新的数据源为 B ，对 A 和 B 的操作主要就是读和写嘛～

对于读，可以先不用修改，返回的地址不同就行了，例如 A 返回的是 a.xxx.com/y.jpg B 返回的是 b.xxx.com/z.jpg

对于写，可以设置一个开关，第一步先双写一段时间，返回的读地址是 A 的，经过一段时间可以按流量返回读 B 的地址。

经过一段时间的验证，确认数据源 B 是稳定的之后，改写的开关，改为只写到 B ，只返回 B 的地址。当然此时 A 依然可以访问。

同时，想办法把 A 的文件拷贝到 B ，这个随便你怎么搞都行，主要成本在流量费上。假设有千兆的同步速度，平均稳定在 100Mb/s 的话，10*1024*1024/100/3600 约等于 29 小时，速度还算可以的。

再验证一段时间，数据源 B 完全没问题之后，把之前指向 A 域名的全部更新为指向 B ，再过一段时间确认没问题了再彻底下掉 A 即可。

我觉得#4 说的非常正确，语言好学但是对应的 infrastructure 是非常吃经验和水平的事，就拿 go 来说当然简单，但是 go 本身不支持热更新(虽然有一些包能做到)，那你就需要 2 台机器，每次先从负载上摘流一台然后更新一台，非常麻烦。

所以我更推荐 php/python ，最大的好处是对运维的要求低，并且即使不用 redis 之类的缓存，直接操作数据库，性能也不会很弱，最起码在你产品起来之前性能绝对够用。你可以搞个什么 bt 面板或者 1pannel 之类的，就完全不用运维了。你甚至可以直接把代码扔到一些支持 php/python 的虚拟空间上直接跑，心智负担更低。至于性能，相信我，真的够用。等到不够用的那天你也有足够的资本招人重构了。

当然如果你就是想做个玩具，就是为了玩玩，我推荐 go/java

能给你最大的建议就是千万别自组，不然维护的活就落在你身上了，并且一旦出了问题你就是全责。

建议直接联系各大服务器厂商，让他们给你定制存储服务器方案，ISICI 算是一个特别常见的协议，所以你既可以找传统的服务器厂商例如 Dell Hp 也可以找群晖威联通这种做 nas 的商家，他们也有商用方案的提供。


千万别自组老铁！！！！！！！

不需要吧，国内的这些云有竞价实例的，虽然说是只有 1 小时的竞价保护，但是大部分时间都能连用大半天的足够使用了，只保留一台公网 ip 其他的全部不要公网，走内网即可，成本算下来跟电费差不多了。还省的买机器。