我用 Dubbo 传输文件，差点被开除

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

想法是好的，不过这种做法并不合适，因为 Dubbo 并不适合传输文件。好在这个系统在上线不久就没人用废弃了……

虽然被系统废弃了，不过就这个 Dubbo 上传文件的主题还是可以详细分析下，聊聊它到底为什么不适合上传文件。

Dubbo 怎么传文件？

难道这样直接传 File 吗？

void sendPhoto(File photo);

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

void sendPhoto(byte[] photo);

但这样就会导致 consumer 端需要一次性读取完整的文件内容至内存中，再大的内存也扛不住这样玩。而且 provider 端在接受数据解析报文时，也需要一次性将 byte[] 读取至内存中，也是一样有内存占用过高的问题。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能。

项目地址：https://github.com/YunaiV/ruoyi-vue-pro

单连接模型问题

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

Dubbo 协议默认是单连接的模型，即一个 provider 的所有请求都是用一个 TCP 连接。默认使用 Netty 来进行传输，而 Netty 中为了保证 Channel 线程安全，会将写入事件进行排队处理。那么在单连接下，多个请求都会使用同一个连接，也就是同一个 Channel 进行写入数据；当多个请求同时写入时，如果某个报文过大，会导致 Channel 一直在发送这个报文，其他请求的报文写入事件会进行排队，迟迟无法发送，数据都没有发送过去，那么其他的 consumer 也自然会处于阻塞等待响应的状态中，一直无法返回了。

所以在单连接下，如果报文过大，会导致 Netty 的写入事件处理阻塞，无法及时的将数据发送至服务端