Spring Cloud Gateway 微服务统一入口实战
为什么需要 API 网关
在微服务架构中,我们通常通过注册中心(如 Nacos、Eureka)解决服务发现问题,用负载均衡器处理流量分发。但随之而来的一个痛点是:所有微服务的接口都直接暴露在外,外部客户端可以直接访问任意服务。
为了保证安全性,每个微服务内部都需要实现权限校验逻辑。一旦业务拆分,原本单体应用中的单一校验点变成了多个应用的重复代码。当需要修改鉴权规则时,开发人员得逐个修改所有服务,维护成本极高。
这就好比一家公司,以前只有一个员工负责接待和核实身份;后来部门多了,每个部门都要自己核实访客身份,效率低且流程繁琐。设立一个统一的前台(API 网关),由前台先核实身份,通过后放行到各部门,是更优的解决方案。
什么是 API 网关
API 网关是后端服务的唯一入口,类似于设计模式中的门面模式(Facade)。它对外提供统一的调度与过滤能力,核心功能包括:
- 权限控制:作为入口拦截非法请求,统一进行鉴权。
- 动态路由:根据规则将请求转发到对应的微服务,不处理具体业务。
- 负载均衡:当目标服务有多个实例时,自动分配流量。
- 限流熔断:控制进入后端的流量,防止服务压力过大。
常见网关实现
业界成熟的网关方案不少,比如 Nginx、Kong、Zuul 等。在 Spring Cloud 生态中,主要对比的是 Zuul 和 Spring Cloud Gateway。
- Zuul:Netflix 开源组件,早期 Spring Cloud 推荐方案。但在 2018 年后 Netflix 宣布部分组件进入维护状态,不再开发新特性,性能方面基于 Servlet 阻塞模型也略显吃力。
- Spring Cloud Gateway:Spring Cloud 全新项目,基于 Spring Boot 和 WebFlux 响应式栈开发,旨在替代 Zuul。官方测试显示其 RPS(每秒请求数)约为 Zuul 的 1.6 倍,更适合高并发场景。
快速上手
创建项目与依赖
新建一个 Spring Boot 项目,引入以下核心依赖:
<!-- 网关核心依赖 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<!-- 服务发现依赖 (以 Nacos 为例) -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
org.springframework.cloud
spring-cloud-starter-loadbalancer


