Dubbo Data length too large: 11557050, max payload: 8388608 传输数据超限

com.alibaba.dubbo.remoting.transport.AbstractCodec.checkPayload() ERROR  Data length too large: 11557050, max payload: 8388608 java.io.IOException: Data length too large: 11557050, max payload: 838860

 

故障原因：

　　最近作一个功能，前端Spring MVC作Excel文件导入，前端仅负责接收上传数据，解析需交由后端Dubbo Provider解析并持久化到数据库，前端接收文件流，因为Dubbo没法直接对文件流进行传输，随将文件流转byte（能序列化）走Dubbo底层协议传输。

　　起初小文件传输没有问题，可是文件超过8M后，出现本文顶端的异常，由Provider抛出，不难看出，Dubbo对传输的数据包作了8M限制，超限即抛异常，尽管这个问题阿里和当当的Dubbox已经放开了这个限制，详见（https://code.aliyun.com/alibaba/dubbo/commit/827769f8ad1e05f5b7caf0f09afe2aec344096cd       https://github.com/dangdangdotcom/dubbox/pull/33/files?diff=split），可是仔细想一想，这并不符合Dubbo设计的初衷，Dubbo的长链接并非为这种大数据包传输服务的，主要用于小数据包频繁调用，因此这个场景的设计就是有问题的。

 

 

如何解决？

　　一、若是不想修改代码及其余结构，那没办法，要么升级Dubbo版本（这明显动做很大，有不少风险）

　　二、将Excel文件内容拆成小于8M的N个文件

　　三、大于8M的Excel文件前端接收后将文件流转换后的Byte作切割，切成小于8M而后挨个传输，可是Consumer和Provider必须保证头尾完整，Provider才能完整解析

　　四、Excel大文件由Consumer接收后上传至指定FTP服务器，Provider从FTP服务器取回解析，这里也可用其余分布式文件服务器，或者放到Mongodb或Redis库，看本身设计。

　　五、看项目架构及结构，直接由Consumer解析，但有些场景并不容许。

 

建议：

　　我的倾向于上述建议第4条，原本就是分布式架构，跳过RPC传输大数据包，直接从第三方服务器取，这样减轻了Dubbo的压力，也不会占用某个链接对应的Provider节点带宽，给其余频繁的小数据包请求让路，这样更理想。