【本人菜鸡,欢迎交流讨论】
业务中常常有文件上传的需求,将文件传到第三方对象存储服务器或者ftp
【基本流程】
- 后端接收
MultipartFile
类型参数 - 将图片上传到ftp/第三方对象存储服务器
- 返回给前端流(outputStream)/ url地址,供前端预览
【常见问题】
- 从controller到service,参数需要序列化,而MultipartFile和HttpServletResponse都未实现序列化
- dubbo消费层向服务层传输大数据容量对象时,会受dubbo限制,报错
Data length too large
,最简单粗暴的操作方式直接修改dubbo的payload
属性
然而,这么操作存在的问题;dubbo协议采用单一长连接,不支持大文件传输
【解决方案】
- 从consumer到provider可以通过将
multipartFile
转换为byte[]
传输【技术上】 - 将所有的上传代码全部写到consumer,不进行数据传输
以上两种一般是做简单的存储操作,不对文件进行处理;然而,在需要对文件进行处理时,比如pdf的合成与定位,后端接收文件需要进行二次处理就不太适合了,可以采用下面的逻辑
改变业务执行方式
:在consumer中将文件上传到服务器,传输文件名,再在provider中根据文件名下载文件,对文件进行操作;回传呢?provider中处理完后,在上传到服务器,返回给前端url地址即可
【补充说明,dubbo为什么不支持传输大文件】
官网说明:Dubbo 缺省协议采用单一长连接和 NIO 异步通讯,适合于
小数据量
、大并发
的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况。
如果将File
转换为byte[]
传输文件内容,那么provider需要一次性接收所有的内容,存在内存占用过高
的问题;
Dubbo协议默认是单连接模型
,多个请求用同一个连接(一个provider的所有请求都是用一个TCP连接,默认使用Netty传输),即多个consumer对应一个provider,这些consumer排队等待使用provider,当一个consumer占用过多资源时,其他consumer等待处理,会造成阻塞; 因此,从设计上,dubbo就不适合大文件传输