【Spring Cloud】统一服务入口-Gateway

Ne0inhk

— 14 min read
【Spring Cloud】统一服务入口-Gateway

系列文章目录

文章目录

在这里插入图片描述

一、网关介绍

1.1 问题

之前的文章，我们通过Eureka, Nacos解决了服务注册, 服务发现的问题, 使用Spring CloudLoadBalance解决了负载均衡的问题, 使用OpenFeign解决了远程调用的问题.
但是当前所有微服务的接口都是直接对外暴露的, 可以直接通过外部访问. 为了保证对外服务的安全性,服务端实现的微服务接口通常都带有⼀定的权限校验机制. 由于使用了微服务, 原本⼀个应⽤的的多个模块拆分成了多个应用, 我们不得不实现多次校验逻辑. 当这套逻辑需要修改时, 我们需要修改多个应用, 加重了开发人员的负担.

针对以上问题, ⼀个常用的解决方案是使用API网关.

比如企业管理
外部人员去公司办理业务, 公司需要先核实对⽅的⾝份再去进⾏办理.
最开始只有⼀个员⼯, 这个员工核实之后直接办理即可. (单体架构)
随着公司的发展, 划分了多个部们, 每个部门负责的事情不同, 每个部门都需要先核实对方的身份再进行办理. (微服务架构)
这个流程存在⼀些问题:
1 . 办事效率低
2 . 增加了员工的工作流程
我们对此进行改进, 设立前台, 统⼀由前台来进行身份的校验. 前台⾝份校验通过后, 其他部门就设置信任, 直接办理.。

1.2 什么是API网关

API网关(简称网关)也是⼀个服务, 通常是后端服务的唯⼀入口. 它的定义类似设计模式中的Facade模式(门⾯模式, 也称外观模式). 它就类似整个微服务架构的门面, 所有的外部客户端访问, 都需要经过它来进行调度和过滤.

在这里插入图片描述

网关核心功能:

权限控制: 作为微服务的入口, 对用户进行权限校验, 如果校验失败则进行拦截
动态路由: ⼀切请求先经过网关, 但网关不处理业务,而是根据某种规则, 把请求转发到某个微服务
负载均衡: 当路由的目标服务有多个时, 还需要做负载均衡
限流: 请求流量过高时,按照网关中配置微服务能够接受的流量进行放行, 避免服务压力过大

1.3 常见网关实现

业界常用的网关方式有很多, 技术方案也较成熟, 其中不乏很多开源产品, 比如Nginx, Kong, Zuul,Spring Cloud Gateway等. 下面介绍两种常见的网关方案.
Zuul
Zuul 是 Netflix 公司开源的⼀个API网关组件, 是Spring Cloud Netflix 子项目的核心组件之⼀，它可以和 Eureka、Ribbon、Hystrix 等组件配合使用.
在Spring Cloud Finchley正式版之前, Spring Cloud推荐的网关是Netflix提供的Zuul(此处指Zuul 1.X).
然而Netflix在2018年宣布⼀部分组件进入维护状态, 不再进行新特性的开发. 这部分组件中就包含Zuul.

Spring Cloud Gateway
Spring Cloud Gateway 是Spring Cloud的⼀个全新的API网关项目, 基于Spring + SpringBoot等技术开发, 目的是为了替换掉Zuul. 旨在为微服务架构提供⼀种简单而有效的途径来转发请求, 并为他们提供横切关注点, 比如: 安全性, 监控/指标和弹性.
在性能方面, 根据官方提供的测试报告, Spring Cloud Gateway的RPS(每秒请求数)是Zuul的1.6倍.

二、Spring Cloud Gateway

2.1 快速上手

2.1.1 创建网关项目

在这里插入图片描述

2.1.2 引入网关依赖

<!--⽹关--><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></dependency><!--负载均衡--><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-loadbalancer</artifactId></dependency>

2.1.3 编写启动类

@SpringBootApplicationpublicclassGatewayApplication{publicstaticvoidmain(String[] args){SpringApplication.run(GatewayApplication.class, args);}}

2.1.4 添加Gateway的路由配置

创建application.yml文件, 添加如下配置：

server: port:10030 # ⽹关端⼝ spring: application: name: gateway # 服务名称 cloud: nacos: discovery: server-addr:110.41.51.65:10020 gateway: routes: # ⽹关路由配置 - id: product-service #路由ID, ⾃定义, 唯⼀即可 uri: lb://product-service #⽬标服务地址 predicates: #路由条件 -Path=/product/## - id: order-service uri: lb://order-service predicates:-Path=/order/**

配置字段说明:

• id : 子定义路由ID, 保持唯⼀
• uri: 目标服务地址, 支持普通URI 及 lb://应用注册服务名称 . lb表示负载均衡, 使用 lb:// 方式表示从注册中心获取服务地址.
• predicates: 路由条件,根据匹配结果决定是否执⾏该请求路由, 上述代码中, 我们把符合Path规则的 ⼀切请求, 都代理到uri参数指定的地址.

通过网关服务访问order-service的URL：http://127.0.0.1:10030/order/1

2.2 Route Predicate Factories

2.2.1 Predicate

Predicate是Java 8提供的⼀个函数式编程接口, 它接收⼀个参数并返回⼀个布尔值, 用于条件过滤, 请求参数的校验.

@FunctionalInterfacepublicinterfacePredicate<T>{booleantest(T t);//...}

代码演示:

  1. 定义⼀个Predicate
classStringPredicateimplementsPredicate<String>{@Overridepublicbooleantest(String str){return str.isEmpty();}}
  1. 使用这个Predicate
publicclassPredictTest{publicstaticvoidmain(String[] args){Predicate<String> predicate =newStringPredicate();System.out.println(predicate.test(""));System.out.println(predicate.test("bite666"));}}
  1. Predicate的其他写法
    1）内置函数
publicclassPredictTest{publicstaticvoidmain(String[] args){Predicate<String> predicate =newPredicate<String>(){@Overridepublicbooleantest(String s){return s.isEmpty();}};System.out.println(predicate.test(""));System.out.println(predicate.test("bite666"));}}
  1. lambda写法：
publicclassPredictTest{publicstaticvoidmain(String[] args){Predicate<String> predicate = s -> s.isEmpty();System.out.println(predicate.test(""));System.out.println(predicate.test("bite666"));}}

Predicate predicate = s -> s.isEmpty(); 也可以写成
Predicate isEmpty = String::isEmpty;

  1. Predicate 的其他方法
• isEqual(Object targetRef) :比较两个对象是否相等,参数可以为Null
• and(Predicateother): 短路与操作,返回⼀个组成Predicate
• or(Predicate other):短路或操作,返回⼀个组成Predicate
• test(T t) :传入⼀个Predicate参数,用来做判断
• negate() :返回表示此Predicate逻辑否定的Predicate

2.2.2 Route Predicate Factories

Route Predicate Factories (路由断言工厂, 也称为路由谓词工厂, 此处谓词表示⼀个函数), 在Spring Cloud Gateway中, Predicate提供了路由规则的匹配机制.我们在配置文件中写的断言规则只是字符串, 这些字符串会被Route Predicate Factory读取并处理, 转变为路由判断的条件.

比如前面章节配置的 Path=/product/** , 就是通过Path属性来匹配URL前缀是 /product 的请求.这个规则是由org.springframework.cloud.gateway.handler.predicate.PathRoutePredicateFactory 来实现的.Spring Cloud Gateway 默认提供了很多Route Predicate Factory, 这些Predicate会分别匹配HTTP请求的不同属性, 并且多个Predicate可以通过and逻辑进行组合.

具体可以参考相关网站：Spring Cloud Gateway

2.2.3 代码演示

  1. 添加Predicate规则
    在application.yml中添加如下规则
spring: cloud: gateway: routes: # ⽹关路由配置 - id: product-service #路由ID, ⾃定义, 唯⼀即可 uri: lb://product-service #⽬标服务地址 predicates: #路由条件 -Path=/product/## -After=2026-01-01T00:00:00.000+08:00[Asia/Shanghai]

这样我们可以通过修改时间访问限制，发现只有在时间限制范围内的请求可以通过。

2.3 Gateway Filter Factories(网关过滤器工厂)

Predicate决定了请求由哪⼀个路由处理, 如果在请求处理前后需要加⼀些逻辑, 这就是Filter(过滤器)的作用范围了.
Filter分为两种类型: Pre类型和Post类型.
Pre类型过滤器: 路由处理之前执行(请求转发到后端服务之前执行), 在Pre 类型过滤器中可以做鉴权, 限流等.
Post类型过滤器: 请求执行完成后, 将结果返回给客户端之前执行

在这里插入图片描述

Spring Cloud Gateway 中内置了很多Filter, 用于拦截和链式处理web请求. 比如权限校验, 访问超时等设定.
Spring Cloud Gateway从作用范围上, 把Filter可分为GatewayFilter 和GlobalFilter.
GatewayFilter: 应用到单个路由或者⼀个分组的路由上.
GlobalFilter: 应用到所有的路由上, 也就是对所有的请求生效.

2.3.1 GatewayFilter

GatewayFilter 同 Predicate 类似, 都是在配置文件 application.yml 中配置，每个过滤器的逻辑都是固定的. 比如 AddRequestParameterGatewayFilterFactory 只需要在配置文件中写 AddRequestParameter , 就可以为所有的请求添加一个参数, 我们先通过⼀个例子来演示GatewayFilter如何使用
快速上手：

server: port:10030 # ⽹关端⼝ spring: application: name: gateway # 服务名称 cloud: nacos: discovery: server-addr:110.41.51.65:10020 gateway: routes: # ⽹关路由配置 - id: product-service #路由ID, ⾃定义, 唯⼀即可 uri: lb://product-service #⽬标服务地址 predicates: #路由条件 -Path=/product/## -After=2024-01-01T00:00:00.000+08:00[Asia/Shanghai] filters:-AddRequestParameter=userName, bite - id: order-service uri: lb://order-service predicates:-Path=/order/**

该filter只添加在了 product-service 路由下, 因此只对 product-service 路由生效, 也就是对 /product/** 的请求生效.

2 . 接收参数并打印
在 product-service 服务中接收请求的参数,并打印出来

@RequestMapping("/product")@RestControllerpublicclassProductController{@AutowiredprivateProductService productService;@RequestMapping("/{productId}")publicProductInfogetProductById(@PathVariable("productId")Integer productId,String userName){System.out.println("收到请求,Id:"+ productId);System.out.println("userName:"+ userName);return productService.selectProductById(productId);}}

GatewayFilter说明：

Spring Cloud Gateway提供了的Filter非常多,具体网站网址：网站

大家可以细化学习。

Default Filters
前⾯的filter添加在指定路由下, 所以只对当前路由生效, 若需要对全部路由⽣效, 可以使用spring.cloud.gateway.default-filters 这个属性需要⼀个filter的列表.
配置举例:

spring: cloud: gateway:default-filters:-AddResponseHeader=X-Response-Default-Red,Default-Blue-PrefixPath=/httpbin

2.3.2 GlobalFilter

GlobalFilter是Spring Cloud Gateway中的全局过滤器, 它和GatewayFilter的作用是相同的.GlobalFilter 会应用到所有的路由请求上, 全局过滤器通常用于实现与安全性, 性能监控和日志记录等相关的全局功能.
Spring Cloud Gateway 内置的全局过滤器也有很多, 比如:
• Gateway Metrics Filter: 网关指标, 提供监控指标
• Forward Routing Filter: 用于本地forword, 请求不转发到下游服务器
• LoadBalancer Client Filter: 针对下游服务, 实现负载均衡.
• …
更多过滤器参考: 网址

快速上手

  1. 添加依赖
<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-actuator</artifactId></dependency>
  1. 添加配置
spring: cloud: gateway: metrics: enabled:true management: endpoints: web: exposure: include:"*" endpoint: health: show-details: always shutdown: enabled:true

http://127.0.0.1:10030/actuator, 显示所有监控的信息链接

2.4 过滤器执行顺序

⼀个项目中, 既有GatewayFilter, 又有 GlobalFilter时, 执行的先后顺序是什么呢?
请求路由后, 网关会把当前项目中的GatewayFilter和GlobalFilter合并到⼀个过滤器链(集合)中, 并进行排序, 依次执行过滤器

在这里插入图片描述

每⼀个过滤器都必须指定⼀个int类型的order值, 默认值为0, 表示该过滤的优先级. order值越小，优先级越高，执行顺序越靠前.
• Filter通过实现Order接口或者添加@Order注解来指定order值.
• Spring Cloud Gateway提供的Filter由Spring指定. 用户也可以自定义Filter, 由用户指定.
• 当过滤器的order值⼀样时, 会按照 defaultFilter > GatewayFilter > GlobalFilter的顺序执行.

2.5 自定义过滤器

Spring Cloud Gateway提供了过滤器的扩展功能, 开发者可以根据实际业务来自定义过滤器, 同样自定义过滤器也支持GatewayFilter 和 GlobalFilter两种.

2.5.1 ⾃定义GatewayFilter

自定义GatewayFilter, 需要去实现对应的接口 GatewayFilterFactory , Spring Boot 默认帮我们实现的抽象类是 AbstractGatewayFilterFactory , 我们可以直接使用

2.5.1.1 定义GatewayFilter
@Slf4j@ServicepublicclassCustomGatewayFilterFactoryextendsAbstractGatewayFilterFactory<CustomGatewayFilterFactory.CustomConfig>implementsOrdered{publicCustomGatewayFilterFactory(){super(CustomConfig.class);}@OverridepublicGatewayFilterapply(CustomConfig config){/** * Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) * ServerWebExchange: HTTP请求-响应交互的契约, 提供对HTTP请求和响应的访问, 服 务器端请求属性, 请求实例,响应实例等, 类似Context⻆⾊ * GatewayFilterChain: 过滤器链 * Mono: Reactor核⼼类, 数据流发布者, Mono最多只触发⼀个事件, 所以可以把 Mono ⽤于在异步任务完成时发出通知. * Mono.fromRunnable: 创建⼀个包含Runnable元素的数据流 */return((exchange, chain)->{ log.info("[Pre] Filter Request, name:"+ config.getName());return chain.filter(exchange).then(Mono.fromRunnable(()->{ log.info("[Post] Response Filter");}));});}@OverridepublicintgetOrder(){returnOrdered.LOWEST_PRECEDENCE;//配置优先级, order越⼤, 优先级越低}

针对这个Filter的配置, 使用CustomConfig 定义

@DatapublicclassCustomConfig{privateString name;}

代码说明:

类名统一以GatewayFilterFactory结尾, 因为默认情况下, 过滤器的name会采用该定义类的前缀. 这里的name=Custom(yml配置中使用)apply方法中, 同时包含Pre和Post过滤, then方法中是请求执行结束之后处理的CustomConfig 是一个配置类, 该类只有⼀个属性name, 和yml的配置对应该类需要交给Spring管理, 所以需要加 @Service 注解getOrder表示该过滤器的优先级, 值越大, 优先级越低
2.5.1.2 配置过滤器
spring: cloud: gateway: routes: # ⽹关路由配置 - id: product-service #路由ID, ⾃定义, 唯⼀即可 uri: lb://product-service #⽬标服务地址 predicates: #路由条件 -Path=/product/## filters:- name:Custom args: name: custom filter

2.5.2 自定义GlobalFilter

GlobalFilter的实现比较简单, 它不需要额外的配置, 只需要实现GlobalFilter接口, 自动会过滤所有的Filter.

2.5.2.1 定义GlobalFilter
@Slf4j@ServicepublicclassCustomGlobalFilterimplementsGlobalFilter,Ordered{@OverridepublicMono<Void>filter(ServerWebExchange exchange,GatewayFilterChain chain){ log.info("[Pre] CustomGlobalFilter enter...");return chain.filter(exchange).then(Mono.fromRunnable(()->{ log.info("[Post] CustomGlobalFilter return...");}));}@OverridepublicintgetOrder(){returnOrdered.LOWEST_PRECEDENCE;//配置优先级, order越⼤, 优先级越低}}

总结

以上就是本文全部内容，本文主要为大家介绍了Spring Cloud中统一服务入口的重要组件Gateway的相关操作和知识。感谢各位能够看到最后，如有问题，欢迎各位大佬在评论区指正，希望大家可以有所收获！创作不易，希望大家多多支持。

Read more

智谱GLM-5深度解析：稀疏架构革新与2026年开发者实操全指南（附可运行代码）

智谱GLM-5深度解析：稀疏架构革新与2026年开发者实操全指南（附可运行代码）

一、背景引入：2026年大模型落地痛点与GLM-5的破局意义 2026年，AI大模型赛道正式告别“参数内卷”，迈入效率与规模双轮驱动的新阶段，ZEEKLOG平台数据显示，开发者核心痛点集中于三点：算力成本居高不下、长文本处理时延过高、国产模型本土化适配不足。 2月11日，智谱AI正式发布新一代旗舰大模型GLM-5，此前通过OpenRouter平台匿名曝光的“Pony Alpha”，经开发者验证确认为其测试版，上线首日即处理40亿token、接收20.6万请求，引爆开发者圈层。 作为适配2026年“稀疏架构+AI原生应用”趋势的核心模型，GLM-5凭借DSA稀疏注意力、MoE混合专家架构等革新，完美解决开发者“高性能与低成本不可兼得”的核心诉求。 二、GLM-5核心技术原理：架构革新与能力升级 GLM-5的核心竞争力源于底层架构的重构与工程化优化，相较于上一代GLM-4.7，在架构设计、推理效率、能力覆盖上实现代际跨越，关键技术原理围绕“稀疏化、高效化、本土化”三大核心展开。 2.1 核心架构：DSA稀疏注意力+MoE混合专家模型

By Ne0inhk
实测百灵大模型Ling-2.5-1T：混合线性架构下的全能开发与办公新体验

实测百灵大模型Ling-2.5-1T：混合线性架构下的全能开发与办公新体验

前言 在当前的大模型赛道中，单纯的参数竞赛已逐渐让位于架构创新与场景落地的比拼。作为国内首个采用**混合线性架构（Hybrid Linear Architecture）**的万亿参数级模型，Ling-2.5-1T 的发布引起了技术圈的广泛关注。这种架构旨在兼顾Transformer的通用性与线性注意力机制在长文本、推理效率上的优势。 本次评测将基于 Ling Studio 这一核心场域，从开发者视角的代码生成、咨询顾问视角的深度逻辑分析、极客视角的个性化交互，以及高阶用户的API生态接入四个维度，对Ling-2.5-1T进行全方位拆解。 一、 开箱：极简主义下的全能控制台 进入 Ling Studio 的主界面，首先映入眼帘的是极度克制的UI设计。没有繁杂的侧边栏干扰，用户的注意力被强制聚焦于屏幕中央的对话框。 https://ling.tbox.cn/chat 这种设计语言在当下的SaaS工具中颇为流行，暗示了产品对核心对话能力的自信。点击输入框左侧的配置按钮，会展开详细的模型配置面板。这里不仅仅是简单的对话，Ling Studio 暴露了包括 联网搜索、时间查询、天

By Ne0inhk
掌控消息全链路(4)——RabbitMQ/Spring-AMQP高级特性详解之事务与消息分发

掌控消息全链路(4)——RabbitMQ/Spring-AMQP高级特性详解之事务与消息分发

🔥我的主页：九转苍翎⭐️个人专栏：《Java SE》《Java集合框架系统精讲》《MySQL高手之路：从基础到高阶》《计算机网络》《Java工程师核心能力体系构建》《RabbitMQ理论与实践》天行健，君子以自强不息。 1.事务 AMQP(高级消息队列协议)实现了事务机制，主要用于确保消息的原子性发布和确认。换言之，它允许你将多个操作(如发送消息、确认消息)绑定在一起，要么全部成功，要么全部失败 发送消息 @RestController@RequestMapping("/producer")publicclassProducerController{@Resource(name ="transRabbitTemplate")privateRabbitTemplate transRabbitTemplate;@Transactional@RequestMapping("/trans")publicStringtrans(){ transRabbitTemplate.convertAndSend(""

By Ne0inhk
CHI 协议导论与宏观架构

CHI 协议导论与宏观架构

CHI 协议导论与宏观架构 第1章：片上互连技术的演进与CHI的诞生 1.1 从 AMBA AXI 到 ACE：总线式与一致性挑战        在深入 CHI 之前，我们必须理解其诞生的土壤。ARM 的 AMBA（Advanced Microcontroller Bus Architecture）协议家族是这一切的起点。 1.1.1 AHB 与 ASB 时代：共享总线之困        在早期简单的微控制器系统中，AHB（Advanced High-performance Bus）是主流。它是一种共享总线架构，意味着多个主设备（如CPU、DMA）需要通过仲裁来争夺总线的使用权。 工作原理：仲裁器根据优先级决定哪个主设备可以使用总线。获胜的主设备在下一个周期开始传输，其他主设备必须等待。 核心缺陷： 性能瓶颈：任何时刻只有一个主设备能使用总线，

By Ne0inhk