最近線上項目暴露出很多問題，其中有一個問題，就是帶寬不夠用的問題，從一開始的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請求，這樣可以省好多事