网关基础概念：从定义到选型

聊网关之前，我先问个问题：你部署微服务时，有没有想过客户端怎么找到你的服务？

我刚开始做分布式系统那会儿，服务少，直接暴露 IP 和端口。后来服务一多，问题就来了——鉴权逻辑散落在每个服务里，限流全靠运气，路由更是硬编码。说白了，我们需要一个统一的入口，把乱七八糟的请求管起来。这个入口，就是网关。

网关的定义

网关，全称 API 网关，是系统对外的唯一入口。它处在客户端和后端服务之间，所有请求都得先经过它。

你可以把它想象成公司的前台。来访者（客户端）先到前台登记，前台确认身份、分配会议室（路由）、控制人流（限流），最后才让你进去找对应的人（后端服务）。

我个人习惯把网关看作「反向代理的升级版」。Nginx 也能做反向代理，但网关在代理的基础上，加了更多业务层面的能力。

网关的核心功能

网关的功能很多，但最核心的就三个：路由、限流、鉴权。我一个个说。

1. 路由

路由是网关最基础的功能。客户端发来请求，网关根据路径、Header、参数等信息，把请求转发到对应的后端服务。

举个例子：

# 请求路径：/api/user/getUserInfo
# 网关配置路由规则：
# /api/user/** -> user-service:8080
# /api/order/** -> order-service:8081

# 网关收到请求后，匹配到 /api/user/，转发到 user-service

我在项目中遇到过一个问题：某个服务迁移了，但客户端没更新地址。幸好网关配置了路由规则，改一下配置文件就行，客户端完全无感知。这就是网关路由的价值——解耦。

2. 限流

限流，说白了就是控制流量。防止某个瞬间大量请求打过来，把后端服务冲垮。

常见的限流算法有几种：

算法	原理	特点
计数器	固定时间窗口内计数，超过阈值就拒绝	实现简单，但存在临界问题
滑动窗口	把时间窗口切分成小段，滑动统计	比计数器平滑，精度更高
漏桶	请求先进入桶，以固定速率流出	流量整形效果好，但无法应对突发
令牌桶	以固定速率生成令牌，请求拿到令牌才能通过	允许一定突发，应用最广

我曾经踩过一个坑：计数器限流在秒杀场景下，刚好在窗口边界出现双倍流量。后来换成滑动窗口，问题才解决。嗯，选算法得看业务场景。

3. 鉴权

鉴权就是验证请求的合法性。谁发的请求？有没有权限？

网关层做鉴权，好处很明显：后端服务不用重复写鉴权逻辑了。我见过一个项目，每个微服务都自己写了一套 JWT 校验，后来改密钥，改了三天才改完。如果鉴权统一放在网关，改一处就行。

常见的鉴权方式：

• JWT（JSON Web Token）：无状态，适合分布式场景
• OAuth2：第三方授权，适合开放平台
• API Key：简单直接，适合内部服务

常见网关产品对比

市面上网关产品不少，我挑几个主流的说说。

产品	语言	性能	生态	适用场景
Kong	Lua/OpenResty	高	插件丰富，社区活跃	企业级、云原生
Spring Cloud Gateway	Java	中	与 Spring 生态无缝集成	Java 技术栈、微服务
APISIX	Lua/Go	高	Apache 顶级项目，热更新	高性能、动态路由
Nginx + Lua	Lua	极高	灵活，但开发成本高	定制化需求
Traefik	Go	高	自动发现，配置简单	Kubernetes 环境

你想想看，选哪个产品，其实取决于你的技术栈和团队能力。Java 团队用 Spring Cloud Gateway，上手快；追求极致性能，Kong 或 APISIX 更合适。

我个人习惯用 APISIX。为什么？热更新太香了。改路由规则不用重启，线上操作零感知。我之前用 Kong，改个配置得 reload，虽然影响不大，但心里总有点不踏实。

网关在策略引擎中的位置

这一章讲网关基础，但别忘了我们的课程主题——策略引擎与网关联动。网关不只是转发请求，它还是策略的执行点。

我画了一张图，帮你理解网关和策略引擎的关系：

这张图你看懂了吗？客户端请求先到网关，网关不急着转发，而是先问策略引擎：「这个请求该怎么处理？」策略引擎返回规则，网关再执行。路由、限流、鉴权，每一步都可能涉及策略决策。

小结

这一章我们聊了网关的定义、三大核心功能，以及主流产品的对比。网关不是简单的代理，它是策略落地的关键节点。记住三个关键词：路由、限流、鉴权。