使用Spring Cloud API Gateway传输JSP是否属于软件开发不良实践？

这种做法不算绝对的“不良实践”，但明显偏离了微服务架构的核心设计原则，长期维护和扩展会踩不少坑，具体原因如下：

• 违背职责单一原则
  API Gateway的核心定位是流量入口，负责路由转发、限流熔断、认证授权等网关级能力。把JSP视图渲染逻辑耦合进来，会让网关变成一个“既管流量又做页面”的混合服务，职责边界模糊。后续要升级视图模板、调整渲染逻辑时，都得改动网关，无法聚焦在单一职责上，维护成本会越来越高。

• 锁死前端架构演进空间
  微服务架构的一大优势是支持前后端独立迭代。如果依赖网关提供JSP，相当于把前端视图和Java服务强绑定，没法轻松切换到React、Vue这类现代前端框架，也做不到前端的独立发布、灰度发布，完全浪费了微服务带来的灵活性。

• 拖垮网关性能
  API Gateway需要处理大量请求转发，本身就是高流量节点。再加上JSP同步渲染的阻塞特性，会占用网关的CPU、内存资源，直接影响其核心的路由转发吞吐量，甚至导致网关成为系统性能瓶颈。

• 提升部署与扩展复杂度
  网关通常需要水平扩展来应对流量高峰，而带JSP的网关在扩展时，还要同步视图资源、保证模板一致性，增加了部署难度。另外，JSP的热更新、版本管理会和网关的部署流程冲突——比如更新页面模板可能需要重启网关实例，直接影响服务可用性。

• 不符合生态最佳实践
  多数微服务教程里网关只做API转发，是因为这是经过行业验证的成熟模式。在Spring Cloud生态中，视图层工作更适合交给专门的静态资源服务、独立前端应用，或者拆分出单独的视图渲染服务（比如用Thymeleaf的Spring Boot服务），网关只负责把页面请求路由到对应服务，而非自己承担渲染工作。

如果是单体迁移到微服务的过渡阶段，这种做法可以临时用，但建议尽快推进前后端分离，把视图层从网关剥离，让网关回归核心职责。

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