大数据量传输限制问题十分常见，困扰着不少程序员。本文就以实际线上项目遇到的情况为例，详细聊聊应对这一面试题的思路与方法，希望能给大家带来一些启发。

一、问题背景

最近，线上有个API出了状况。有一笔大小在十几兆左右的JSON报文，在通过网关时被拦截了。原因是网关设置的限制是只允许10兆的数据通过，超过这个大小就过不了关。这可给开发小伙伴们带来了麻烦，毕竟数据传不过去，业务就没法正常开展。

二、与运维沟通尝试扩大网关限制

遇到问题后，小伙伴们第一时间想到的就是和运维商量，看看能不能把网关层的限制调大，这样大报文就能顺利通过了。但运维拒绝了这个请求，他们给出的理由也很合理。如果盲目扩大网关限制，会占用大量带宽。一旦并发量稍微高一些，那些大报文很可能会把整个带宽占满。这样一来，其他用户的正常请求就会被卡住，进不来了。所以，从运维的角度考虑，不能轻易改变网关的大小限制。

三、采用压缩报文的临时解决方案

既然扩大网关这条路走不通，那就换个思路。开发团队尝试对入参的报文进行压缩，在发送端把报文压缩后再传输，接收端收到后进行解压缩。这个方法还真有效，经过压缩的报文成功通过了网关。

不过，这只是个临时方案。因为在这个项目场景下，随着时间的推移，请求的入参可能会越来越多。就算当下压缩后能通过网关，后续入参变多了，报文大小还是可能超过10兆，到时候还是会被网关拦截。所以说，压缩报文只能暂时解决眼前的问题，没办法应对数据长期增长带来的挑战。

四、分片处理——更长久的解决方案

经过团队讨论，最终确定了一个相对长久的方案——分片处理。简单来说，就是把原本大的入参JSON拆分成多份，分多次传输。在后端再把这些拆分的数据统一拼接起来，就像把一块大拼图拆成小块，一块一块地运送，最后再拼起来一样。

虽然这个方法属于间接处理方式，不像压缩报文或者修改网关限制那么直接快速，而且对发送端和接收端都有影响。开发人员需要基于现有的API进行分页改造才能实现分片传输，多次分页调用也会对性能产生一定影响。但就目前来看，在不能调整网关限制的情况下，这已经是比较好的解决办法了。

在实际项目开发中，遇到大数据量传输限制问题很正常，大家要多从不同角度思考解决方案。如果在这方面你有什么经验或者想法，欢迎在评论区留言交流。