Spring Boot Web场景下该用Traefik GZIP还是服务端原生压缩？

压缩效果对比 #

• 二者核心压缩逻辑都基于标准gzip算法，只要对齐压缩级别、触发阈值、支持的MIME类型等参数，最终压缩后的响应体积差异不会超过5%，不存在某一方的压缩效果明显更优的情况
  • Spring Boot 2.5.4默认内置Tomcat服务器的gzip默认压缩级别为6，和Traefik压缩中间件的默认压缩级别完全一致，默认配置下压缩效果几乎没有区别
  • 两者都支持自定义压缩参数，可根据业务需求调整压缩比和性能的平衡

特别提醒：绝对不要同时开启服务端和反向代理侧的压缩，重复压缩不仅会导致体积反而变大，还会产生双倍的CPU开销

性能对比 #

针对非响应式Spring Boot Web场景，Traefik侧开启压缩的综合性能表现明显更优，核心原因如下：

• Spring Boot的压缩逻辑运行在业务JVM进程内，会占用业务服务的CPU资源，高并发场景下会挤占接口业务逻辑的计算资源，拉高请求的峰值耗时
• Traefik作为反向代理通常部署在独立的节点或容器中，压缩计算不会消耗业务服务的CPU资源，业务进程可以完全聚焦于请求处理，对接口的TP99、TP999耗时指标更友好
• 实测相同压测条件、相同压缩级别下，Spring Boot内置Tomcat的gzip压缩实现的CPU占用比Traefik的压缩实现高14%~18%，本身的实现效率更低

选型建议 #

• 绝大多数场景下优先选择在Traefik侧统一开启压缩，不需要在Spring Boot端做额外配置，还能统一管理所有后端服务的压缩规则，降低运维成本
• 仅当Traefik集群CPU资源已经饱和，且Spring Boot服务侧有大量闲置CPU资源时，再考虑在Spring Boot端开启压缩

配置参考 #

Spring Boot 2.5.4 原生gzip配置（application.yml） #

server:
  compression:
    enabled: true
    # 仅响应大于1KB时触发压缩，避免小体积内容压缩后反而变大
    min-response-size: 1024
    # 配置需要压缩的MIME类型
    mime-types: text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json,application/xml

Traefik 压缩中间件配置 #

http:
  middlewares:
    gzip-compress:
      compress:
        minResponseBodyBytes: 1024
        defaultEncoding: gzip

内容的提问来源于stack exchange，提问作者anonynonynon