微服务架构 | 怎样解决超大附件分片上传？

导读：分片上传、断点续传，这两个名词对于做过或者熟悉文件上传的朋友来说应该不会陌生，总结本篇文章希望对从事相关工作的同学能够有所帮助或者启发。     

当我们的文件特别大的时候，上传是不是需要很长的时间啊，这么长时间的长连接，如果网络波动了呢？中间网络断开了呢？在这么长时间的过程中如果出现不稳定的情况，本次上传的所有内容就全部失败了，又要重新上传。

分片上传，就是将所要上传的文件，按照一定的大小，将整个文件分隔成多个数据块（我们称之为 Part）来进行分别上传，上传完之后再由服务端对所有上传的文件进行汇总整合成原始的文件。分片上传不仅可以避免因网络环境不好导致的一直需要从文件起始位置还是上传的问题，还能使用多线程对不同分块数据进行并发发送，提高发送效率，降低发送时间。

一、背景

在系统用户量突增以后，为了更好适配各群体的定制化需求。业务上慢慢实现了支持 C 端用户自定义布局和配置，导致配置数据读取 IO 激增。

为了更好优化此类场景，将用户自定义配置静态化管理！也就是将对应的配置文件生成静态文件，在生成静态文件的过程中遇到棘手的问题，配置文件文件过大导致在文件上传服务器等待时间过长，致使整个业务场景性能整体下滑。

二、生成配置文件

生成文件三大要素

• 文件名

• 文件内容

• 文件存储格式

文件内容、文件存储格式都好理解和处理，当然先前整理过微服务中常用的加密方式

• 微服务架构 | 微服务有哪些常用的加密方式 (一)

• 微服务架构 | 数据加密有哪些常用的加密方式（二）

这里做下补充说明，如果要想对文件内容进行加密可以考虑。但是本文的案例场景对于配置信息保密程度较低，这里不做拓展。

而对于文件名的命名规范具体结合业务场景来定，通常都是以文件概要+时间戳格式为主。但是这类命名规范容易导致文件名冲突，造成没有必要的后续麻烦。

所以我这里对于文件名的命名做了特殊处理，有处理过前端 Route 路由经验的应该能联想到，文件名可以通过基于内容生成 Hash 值