在同一Spring Boot微服务项目中集成Spring Cloud Gateway的可行性及最佳实践问询

First off, let's cut to the chase: it's strongly not recommended to run Spring Cloud Gateway and a traditional Spring MVC-based web service in the same project, and here's why:

Why the Conflict Happens #

Spring Cloud Gateway is built on top of Spring WebFlux—a reactive, non-blocking web framework that doesn't rely on the Servlet API. On the other hand, your existing API service uses Spring MVC, which is a Servlet-based synchronous framework. These two frameworks are fundamentally incompatible at the dependency and runtime level:

• When you have both spring-boot-starter-web (for MVC) and Spring Cloud Gateway dependencies in the same project, Spring will throw that compatibility warning because it can't resolve which web runtime to use.
• When you remove spring-boot-starter-web to fix the warning, you lose all Servlet API dependencies (like javax.servlet.Filter) that your MVC-based API service needs to run—hence the ClassNotFoundException you saw.

While you might be able to hack together some dependency exclusions or workarounds to force them to coexist, this will create a messy, unmaintainable codebase. It goes against the design principles of both Spring Cloud Gateway and microservices architecture.

Best Practices for Spring Cloud Gateway in Microservices #

If you can't integrate them in the same project, here's the standard approach for gateways in microservices:

• Use a single, standalone gateway service (or cluster) as the entry point for your entire microservice ecosystem. All external requests (and even internal cross-service requests, if needed) go through this gateway. This lets you centralize common concerns like authentication, authorization, rate limiting, logging, cross-origin handling, and routing rules.
• Keep the gateway decoupled from your business microservices. Deploy it as a separate service so you can scale, update, or troubleshoot it independently without affecting your API services. Your business services only need to focus on their core functionality.
• Don't deploy a separate gateway for each microservice. This would waste resources, duplicate configuration work, and make it impossible to manage cross-cutting concerns consistently across your system.

Your Next Steps #

• Create a new, standalone Spring Cloud Gateway project. Configure routing rules in it to forward requests to your existing API microservice. This is the cleanest, most maintainable solution.
• If you only need simple routing logic and don't want to spin up a separate gateway, you could use Spring MVC's built-in forwarding capabilities (like RequestMappingHandlerMapping or ForwardController), but this is a lightweight workaround—not a replacement for a full-fledged gateway.

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