最近线上项目暴露出很多问题，其中有一个问题，就是带宽不够用的问题，从一开始的30M 加至 60M 到后来的 200M 可是我们的日活总共还不到10000啊，这个问题，我决定好好查查原因
占用带宽无非就是接口返回的数据量过大导致，所以我就排查了下项目中返回数据量较大的几个接口，当中的一个也是访问很频繁的接口 获取即时列表接口最大返回数据量有时会超过2M！！！ 我靠，更可怕的是这个接口还是个轮询接口，5秒中前台调用一次
好了原因找到了，就是这个接口导致的，优化吧
1.业务逻辑规定该数据不能分页返回
2.该接口无法拆分，很多数据必须一次返回
3.轮询不能修改
OK ...
然后就想到了数据压缩，因为我们项目是spring-boot项目，所以添加Gzip很方便 添加两行配置就好了
server.compression.enabled=true server.compression.min-response-size=1024 server.compression.mime-types=application/json
可是添加后没有任何效果，接口调用后也没有显示数据被压缩过
凉凉
为了排除是spring-boot 版本号的问题，我使用自己之前的小项目写了个小demo测试，不加压缩的时候返回数据3M 加完压缩返回的数据 60多Kb....
这个压缩确实是个好东西，可是我们项目中没法用...
经过百般思考，发现了其中的端倪 GET POST
需要用GZIP 必须是get 请求
可是前台包无法即时更新，且要考虑到老版本 POST 改GET 也只能是后续版本能缓解压力，所以 mark 下，以后这中返回数据量大的接口，只要不涉及到敏感信息，务必使用GET请求，这样可以省好多事