背景
由于某业务需要，需要对文件上传服务进行一次架构调整，初步考虑几点：
- 水平扩展性：上传worker节点按需弹性部署
- 负载均衡：根据上传worker节点的状态随时均衡调度
- 高可用性：无单点问题，快速替换故障点
- 支持断点续传：即需要提供分片上传接口
- 支持秒传：对于上传过的相同文件直接响应完成
- 就近原则：通过离用户最近的区域节点上传文件，通过CDN节点下载文件
初步架构逻辑
架构图如图所示：
重点功能模块说明：
- 上传调度服务
(1)根据用户申请上传的文件判断是否秒传；
(2)根据用户所在ip及worker节点状态返回上传接口地址。 - 文件上传模块
(1) 接收用户上传的文件数据(文件/分片)；
(2) 合并分片/校验文件hash/写入临时存储；
(3) 定期上报worker节点负载/健康状态；
(4) 将已上传文件推送到待转移队列；
(5) 更新数据库文件表信息。 - 文件转移服务
(1) 将文件从临时存储转移到永久存储文件服务中；
(2) 更新数据库文件表信息。
技术点说明：
- 为什么需要临时存储和永久存储两级文件存储？
由于永久存储需要做文件校验和副本策略的步骤比较多，并且可能会跨机房传输；如果这样直接写入，用户可能会等待比较长的时间。
儿用户上传大文件时通过就近的worker节点上传，并持续append到就近的存储服务后，这个时候用户就可以下载了，用户体验较好。 - 文件转移服务的作用
既然有了两级存储服务，那就需要开启一个文件转移服务来异步将文件进行持续转移，并且根据需要删除临时存储内的文件；因此临时存储容量可以维持在比较稳定的规模。 - 数据库用于存放文件存储位置
文件未转移时，存储的地址是临时存储中的路径；
文件转以后，存储的地址是永久存储中的路径；
这样文件下载服务总是有效的。 - 关于分块合并
这里需要一整套接口来保证分块上传的完整性和冲突解决，之后再具体描述。 - 关于hash计算
每个分片算一次hash，并且最后有序的串起来算一次hash，最后作文件完整性校验。 - 关于监控和故障修复
还需要考虑完善监控完备性，快速报警及修复/替换故障节点。
考虑到无状态服务情况，客户端需保留几个目标host，以备通讯失败时能及时尝试连接到其他节点。