内网网盘上传文件失败问题的解决

之前有提到,内部用了个网络上开源的网盘系统,最新峰峰他们突然反应好几次上传文件失败,出问题的时候有个比较明显的特征是文件体积较大。由于目前咱就是首席运维官,这个网盘也是亲自选型的,这种事就只好赤膊上阵了。

这个网盘的分发包,结构不是很合理,其存储用户上传的数据的目录跟主程序在一起,如下。

这种组织方法并不利于升级。老夫做了以下改进:
1. 把 conf 和 data 目录提升至与 app-root 平级;
2. 在 app-root 下创建 conf 和 data 软链接指向上层相对应的目录;
3. 将 app-root 改名为 app-root-vX,其中 X 为实际版本号;
4. 创建 app-root 软链接指向 app-root-vX。

这样做的最大的好处就是升级或者回滚都相对方便,勿需覆盖,数据除非应用自身做了大的更改,否则可以直接继承使用。

把源代码克隆到本地,安装 JDK、Maven,以及给 Visual Studio Code 安装插件,让工程可以顺利编译并打包。大体理了一下代码结构,找到了处理文件上传的类,查看可以插入调试信息的方式和位置。作者的信息记录,尤其是出错记录工作相当不到位,日志类竟然是和业务密切相关的,所以第一时间先补了个可以写任意调试内容的方法进去。

一开始,计划在不影响线上入口的情况下做测试,定位问题所在。思路是并行再运行一份服务(把程序复制了一份),但直接使用现有的数据,因为还考虑到了很有可能错误与现有数据相关。修改配置让服务监听到 8282 端口上,然后运行,报错,看信息是因为数据库已经被占用。看来不影响线上入口是不行了。于是把正本服务下线,再次执行副本,上传大文件竟然成功。这个结果表明,我大概率不用再去改源代码了,至少要改的地方可能要发生变化了。

那到底是什么导致的问题呢?突然想到,正本服务是经过 nginx 代理的(因为要让大家用得爽,消除对端口号的记忆),而副本服务是直接对监听端口进行访问的。此灵光一现之后,把副本服务停掉,重启正本服务,然大家分别使用带端口和无端口的 URL 进行访问测试,果然,只要不带端口,上传大文件就会失败。

机智的我,打开了搜索引擎,输入“nginx 反代 上传文件失败”,发现有很多相关的文章在说这个问题。查看后发现,重点在于一个名为 client_max_body_size 的配置(它可以作用于 http、server、location 等节),毫无疑问此处适用于我在 nginx 的配置文件中创建的 server 节。接下来为具体的值犯愁,1024m 还是 4096m?最后还是写作了 0,内部系统,让大家疯狂吧,先不做限制了。

发表评论

电子邮件地址不会被公开。 必填项已用*标注