为什么都说Dubbo不适合传输大文件？苦思许久的我终于有了答案

背景

之前公司有一个 Dubbo 服务，内部封装了腾讯云的对象存储服务 SDK，是为了统一管理这种三方服务的SDK，其他系统直接调用这个对象存储的 Dubbo 服务。用来避免因平台 SDK 出现不兼容的大版本更新，导致公司所有系统修改跟着升级的问题。

然而因为 Dubbo 并不适合传输大包，所以虽然想法不错，但这种做法还是并不合适，于是这个系统在上线不久就遭废弃没人用了……

不过系统虽然废弃了，但是我们可以顺着 Dubbo 上传文件的主题来详细分析下，说说看它究竟是因为什么不适合传文件。

 

Dubbo 怎么传文件？

难道直接这样传 File 吗？

void sendPhoto(File photo);

自然是不可以的！Dubbo 只是将对象进行序列化然后传输，可 File 对象就算序列化也无法处理文件的数据，所以只能直接发送文件内容：

void sendPhoto(byte[] photo);

但这样会导致 consumer 端需要一次性读取完整的文件内容至内存中，这样玩的话，再大的内存也都遭不住。

并且 provider 端在接受数据解析报文时， byte[] 也需要一次性读取至内存中，内存占用过高的问题同样存在。

 

单连接模型问题

除了内存占用问题之外，Dubbo（这里指 Dubbo 协议）的单连接模型也不适合文件传输。 ​

Dubbo 协议默认是单连接的模型，也就是一个 provider 的所有请求都是用一个 TCP 连接。默认使用 Netty 来进行传输，而 Netty 中为了保证 Channel 线程安全，会将写入事件进行排队处理。那么在单连接下，多个请求都会使用同一个连接，也就是同一个 Channel 进行写入数据；当多个请求同时写入时，如果某个报文过大&