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節點帶寬，給其餘頻繁的小數據包請求讓路，這樣更理想。