微服务架构下,随着服务数量增多,会出现一系列棘手问题:比如用户访问需要调用多个服务(图书服务、订单服务、用户服务),每个服务都要单独处理认证授权;不同服务的接口地址分散,前端需要维护多个请求地址;流量峰值时无法统一控制各服务的访问压力 —— 就像奶茶店连锁品牌,没有统一的前台收银系统,顾客需要分别在点单区、取餐区、充值区排队,效率低下且无法统一管理客流。
Spring Cloud Gateway 作为 Spring 生态的官方 API 网关,是解决这些问题的 “统一入口管家”,无缝整合 Spring Boot,提供路由转发、统一认证、流量控制、熔断降级等核心能力。今天以图书管理系统为案例,手把手实现 Spring Boot 整合 Spring Cloud Gateway,覆盖 “路由转发、全局过滤、局部过滤、限流熔断、动态路由” 全流程,帮助开发者构建企业级微服务 API 网关,实现接口统一管理和流量精细化控制!
一、核心逻辑:为什么需要 API 网关?(奶茶店类比)
1. 微服务无网关的 5 大痛点(企业级场景具象化)
| 痛点类型 | 图书管理系统场景 | 后果 |
|---|---|---|
| 接口入口分散 | 图书服务(/book/)、订单服务(/order/)、用户服务(/user/*)各有独立地址,前端需维护多个请求 URL | 前端配置混乱,服务地址变更需同步修改前端代码 |
| 认证授权冗余 | 每个服务都要单独实现 JWT 令牌校验、角色权限判断 | 代码重复,权限规则修改需逐个服务调整 |
| 流量控制缺失 | 热门接口(图书详情)被高频访问,未做限流,导致服务过载 | 核心服务宕机,影响整体可用性 |
| 服务依赖故障扩散 | 订单服务依赖的库存服务宕机,订单服务直接报错 | 接口报错率飙升,用户体验差 |
| 监控日志分散 | 每个服务单独记录访问日志,排查问题需切换多个服务日志 | 问题定位效率低,运维成本高 |
2. Spring Cloud Gateway 核心能力(对应解决方案)
- 路由转发:统一 API 入口,将请求按规则转发到对应微服务(如
/api/book/*转发到图书服务),前端只需维护网关地址; - 统一过滤:全局过滤器实现统一认证(JWT 校验)、日志记录、跨域处理,局部过滤器实现接口个性化逻辑(如参数校验);
- 限流熔断:整合 Sentinel/Resilience4j,对接口进行 QPS 限流、服务熔断,保护后端服务;
- 动态路由:支持从 Nacos/Apollo 动态加载路由规则,无需重启网关即可调整路由配置;
- 监控可观测:整合 Prometheus+Grafana,监控路由转发成功率、响应时间、限流次数等指标。
3. 技术选型优势(Spring Boot+Spring Cloud Gateway)
- 无缝整合:Spring Cloud Gateway 是 Spring 生态官方网关,与 Spring Boot、Spring Cloud 微服务无缝兼容,配置简单;
- 性能优异:基于 Netty 非阻塞 IO 模型,吞吐量是传统 Zuul 网关的 3 倍以上,支持高并发场景;
- 功能全面:内置路由、过滤、负载均衡、跨域等核心功能,无需额外集成第三方组件;
- 扩展性强:支持自定义过滤器、路由 Predicate(断言),适配企业个性化需求;
- 生态兼容:与 Sentinel、Nacos、JWT 等组件深度整合,覆盖微服务全链路需求。
二、实操 1:环境准备(Spring Boot 整合 Spring Cloud Gateway)
步骤 1:核心依赖引入(Spring Boot 2.7 + 适配)
创建 Spring Boot 项目(网关服务),pom.xml添加核心依赖,无需额外引入 Web 依赖(Gateway 基于 Netty,与 Spring MVC 冲突):
xml
<!-- Spring Boot核心依赖 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
<version>2.7.10</version>
</dependency>
<!-- Spring Cloud Gateway核心依赖 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId>
<version>2.2.10.RELEASE</version> <!-- 适配Spring Cloud Alibaba版本 -->
</dependency>
<!-- 服务发现依赖(用于从Nacos获取微服务地址,负载均衡) -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
<version>2.2.10.RELEASE</version>
</dependency>
<!-- JWT依赖(统一认证用) -->
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt</artifactId>
<version>0.9.1</version>
</dependency>
<!-- Sentinel整合Gateway(限流熔断用) -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-alibaba-sentinel-gateway</artifactId>
<version>2.2.10.RELEASE</version>
</dependency>
<dependency>
<groupId>com.alibaba.csp</groupId>
<artifactId>sentinel-transport-simple-http</artifactId>
<version>1.8.6</version>
</dependency>
步骤 2:核心配置(application.yml)
配置网关端口、Nacos 服务发现、基础路由规则、跨域处理:
yaml
spring:
application:
name: gateway-service # 网关服务名称
cloud:
# Nacos服务发现配置(获取微服务地址)
nacos:
discovery:
server-addr: localhost:8848 # Nacos地址
username: nacos
password: nacos
# Gateway核心配置
gateway:
# 路由规则(按顺序匹配,先匹配先执行)
routes:
# 1. 图书服务路由:/api/book/** → 转发到book-manage-system服务
- id: book-service-route # 路由ID(唯一)
uri: lb://book-manage-system # 目标服务(lb=负载均衡,服务名对应Nacos注册名)
predicates: # 路由断言(满足条件才转发)
- Path=/api/book/** # 路径匹配:请求路径以/api/book/开头
filters: # 路由过滤器(局部过滤,仅对当前路由生效)
- StripPrefix=1 # 去除路径前缀1级(/api/book/detail → /book/detail)
- name: RequestRateLimiter # 局部限流过滤器(可选)
args:
redis-rate-limiter.replenishRate: 100 # 令牌桶填充速率(每秒100个)
redis-rate-limiter.burstCapacity: 200 # 令牌桶最大容量(最多200个)
key-resolver: "#{@ipKeyResolver}" # 限流键解析器(按IP限流)
# 2. 用户服务路由:/api/user/** → 转发到user-service服务
- id: user-service-route
uri: lb://user-service
predicates:
- Path=/api/user/**
filters:
- StripPrefix=1
# 3. 订单服务路由:/api/order/** → 转发到order-service服务
- id: order-service-route
uri: lb://orde

&spm=1001.2101.3001.5002&articleId=155393407&d=1&t=3&u=27cd40664f5d49b4834f33348dd17fdd)
5675

被折叠的 条评论
为什么被折叠?



