Spring Cloud Gateway 微服务统一入口实战
为什么需要网关?
在之前的架构演进中,我们利用 Eureka 或 Nacos 解决了服务注册与发现的问题,通过 Spring Cloud LoadBalancer 实现了负载均衡,并借助 OpenFeign 处理远程调用。但随之而来的问题是:所有微服务的接口直接对外暴露,外部客户端可以直接访问任意服务。
为了保证安全性,服务端通常需要在每个微服务内部实现权限校验逻辑。然而,微服务拆分后,原本单体应用中的多个模块变成了独立的应用,导致我们需要在多个应用中重复编写相同的鉴权代码。一旦校验规则变更,就需要修改多个服务,维护成本极高。
针对这一痛点,API 网关成为了标准解决方案。
类比理解: 就像公司设立前台接待处。早期只有一个人时,核实身份后直接办理业务(单体架构)。随着部门增多,每个部门都要先核实身份再办事(微服务架构),效率低下且流程冗余。改进方案是设立统一的前台,由前台完成身份校验,后续部门只需信任前台即可直接办理。
API 网关的核心职责
API 网关作为后端服务的唯一入口,其设计模式类似于外观模式(Facade)。所有外部请求都需经过它进行调度和过滤。
核心功能包括:
- 权限控制:作为统一入口,对用户进行身份验证,拦截非法请求。
- 动态路由:不处理具体业务,根据规则将请求转发到对应的微服务。
- 负载均衡:当目标服务有多个实例时,自动分配流量。
- 限流熔断:控制进入微服务的流量,防止服务因压力过大而崩溃。
主流网关方案对比
业界成熟的网关方案不少,如 Nginx、Kong、Zuul 和 Spring Cloud Gateway。
Zuul
Zuul 是 Netflix 开源的组件,曾是 Spring Cloud Netflix 的核心。但在 2018 年,Netflix 宣布部分组件进入维护状态,不再开发新功能,Zuul 也在其中。
Spring Cloud Gateway
这是 Spring Cloud 全新推出的网关项目,基于 Spring Boot 和 WebFlux 构建,旨在替代 Zuul。它提供了更简单有效的请求转发途径,并支持安全性、监控等横切关注点。
性能方面,官方测试显示 Spring Cloud Gateway 的 RPS(每秒请求数)是 Zuul 的 1.6 倍。
快速搭建网关服务
创建项目与依赖
新建一个 Spring Boot 项目,引入以下核心依赖:
<!-- 网关核心依赖 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
com.alibaba.cloud
spring-cloud-starter-alibaba-nacos-discovery
org.springframework.cloud
spring-cloud-starter-loadbalancer




