Dubbo不支持远程文件流传输，项目中常用的解决方案

【本人菜鸡，欢迎交流讨论】

业务中常常有文件上传的需求，将文件传到第三方对象存储服务器或者ftp

【基本流程】

1. 后端接收MultipartFile类型参数
2. 将图片上传到ftp/第三方对象存储服务器
3. 返回给前端流（outputStream）/ url地址，供前端预览

【常见问题】

1. 从controller到service，参数需要序列化，而MultipartFile和HttpServletResponse都未实现序列化
2. dubbo消费层向服务层传输大数据容量对象时，会受dubbo限制，报错Data length too large，最简单粗暴的操作方式直接修改dubbo的payload属性
   然而，这么操作存在的问题；dubbo协议采用单一长连接，不支持大文件传输

【解决方案】

1. 从consumer到provider可以通过将multipartFile转换为byte[]传输【技术上】
2. 将所有的上传代码全部写到consumer，不进行数据传输

以上两种一般是做简单的存储操作，不对文件进行处理；然而，在需要对文件进行处理时，比如pdf的合成与定位，后端接收文件需要进行二次处理就不太适合了，可以采用下面的逻辑

3. 改变业务执行方式：在consumer中将文件上传到服务器，传输文件名，再在provider中根据文件名下载文件，对文件进行操作；回传呢？provider中处理完后，在上传到服务器，返回给前端url地址即可

【补充说明，dubbo为什么不支持传输大文件】

官网说明：Dubbo 缺省协议采用单一长连接和 NIO 异步通讯，适合于小数据量、大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。

如果将File转换为byte[]传输文件内容，那么provider需要一次性接收所有的内容，存在内存占用过高的问题；

Dubbo协议默认是单连接模型，多个请求用同一个连接（一个provider的所有请求都是用一个TCP连接，默认使用Netty传输），即多个consumer对应一个provider，这些consumer排队等待使用provider，当一个consumer占用过多资源时，其他consumer等待处理，会造成阻塞； 因此，从设计上，dubbo就不适合大文件传输