这篇笔记主要记录我对“网关”的理解。

一句话概括：

网关就是系统的统一入口。所有请求进入后端系统之前，先经过网关，再由网关转发到对应的服务。

它主要解决的问题包括：

• 服务太多，入口混乱
• 前端不知道应该请求哪个后端服务
• 权限校验、限流、日志等公共逻辑重复写
• 内部服务不想直接暴露给外部
• 服务扩容、迁移、灰度发布时不希望影响前端

可以把网关理解成一个系统的“总入口”或“前台接待”。外部请求先进来，网关判断这个请求该去哪，再把它转发到真正处理业务的服务。

一、没有网关会怎样？

假设系统里有多个后端服务：

用户服务：user-service:8081
订单服务：order-service:8082
文件服务：file-service:8083
支付服务：pay-service:8084

如果没有网关，前端可能要直接访问这些服务：

http://api.example.com:8081/user/info
http://api.example.com:8082/order/list
http://api.example.com:8083/file/upload
http://api.example.com:8084/pay/create

这样会带来几个问题：

• 前端需要记住很多服务地址
• 后端服务端口直接暴露在外部
• 每个服务都要自己做登录校验
• 每个服务都要自己做限流
• 服务扩容、迁移后，前端也可能要跟着改
• 请求日志分散在各个服务里，不方便排查问题
• HTTPS、跨域、安全策略等配置很难统一

有了网关之后，前端只需要访问一个统一入口：

https://api.example.com

然后由网关负责把请求转发到对应服务：

/api/user/**   -> user-service
/api/order/**  -> order-service
/api/file/**   -> file-service
/api/pay/**    -> pay-service

这样前端看到的是一个统一 API 地址，后端内部怎么拆服务、怎么扩容、怎么迁移，对前端的影响都会小很多。

二、网关主要解决什么问题？

1. 统一入口

没有网关时，请求链路可能是：

前端 -> 用户服务
前端 -> 订单服务
前端 -> 文件服务
前端 -> 支付服务

有网关后，请求链路变成：

前端 -> 网关 -> 各个后端服务

前端只需要知道一个地址：

https://api.example.com

这就是网关最基础的作用：把分散的服务入口收拢成一个统一入口。

2. 路由转发

网关会根据请求路径，把请求转发到不同服务。

例如：

/api/user/login     -> 用户服务
/api/order/create   -> 订单服务
/api/file/upload    -> 文件服务
/api/pay/create     -> 支付服务

这就叫路由。

类比一下公司前台：

你办人事业务 -> 前台带你去人事部
你办财务业务 -> 前台带你去财务部
你办仓库业务 -> 前台带你去仓库

网关做的事情也类似：根据请求的内容，找到真正应该处理它的服务。

3. 统一鉴权

没有网关时，每个服务都可能要重复写这些逻辑：

• 检查 token
• 检查登录状态
• 检查用户权限
• 检查接口是否允许访问

有网关后，可以先在网关统一判断：

请求进入系统
  ↓
网关检查 token
  ↓
通过：转发到后端服务
不通过：直接返回 401

这样很多公共逻辑就不用在每个业务服务里重复写了。

4. 统一限流

比如我们想限制：

• 某个 IP 每秒最多访问 10 次
• 某个用户每分钟最多请求 100 次
• 登录接口每秒最多请求 5 次

如果没有网关，每个服务都要自己实现限流。

有网关后，可以在入口统一限制：

请求太频繁
  ↓
网关直接拦截
  ↓
后端服务不被打爆

这类能力在高并发系统里很重要。

5. 负载均衡

一个服务可能会部署多个实例：

user-service-1:8081
user-service-2:8081
user-service-3:8081

网关可以把请求分发到不同实例上：

第 1 个请求 -> user-service-1
第 2 个请求 -> user-service-2
第 3 个请求 -> user-service-3

这样可以分摊服务器压力，提高系统整体吞吐能力。

6. 隐藏内部服务

有网关时，外部用户只知道：

https://api.example.com

但并不知道内部真实服务地址：

10.0.0.11:8081
10.0.0.12:8082
10.0.0.13:8083

内部服务不直接暴露，安全性会更好。

7. 统一日志和监控

所有请求都会先经过网关，所以网关很适合统一记录请求信息，比如：

• 谁访问了哪个接口
• 请求耗时多少
• 返回状态码是多少
• 哪个接口访问量最大
• 哪个 IP 请求异常
• 哪个接口经常报错

这些信息对排查线上问题很有帮助。

8. 灰度发布

比如系统有两个版本：

旧版本：v1
新版本：v2

如果不想让所有用户一次性切到新版本，可以让网关控制流量比例：

90% 请求 -> v1
10% 请求 -> v2

也可以按用户类型控制：

测试账号 -> v2
普通用户 -> v1

这就是灰度发布。它可以降低新版本上线的风险。

9. 协议转换

有些网关还可以做协议转换：

HTTP -> gRPC
WebSocket -> 后端服务
HTTPS -> HTTP
外部 REST API -> 内部 RPC

也就是说，外部访问方式和内部服务之间的通信方式不一定要完全一样。

三、常见网关工具

1. Nginx

Nginx 是最常见的入口网关之一。

常见用途：

• 反向代理
• 负载均衡
• 静态资源服务
• HTTPS 终止
• 简单限流
• 路径转发

适合场景：

• 单体项目
• 前后端分离部署
• 中小型系统
• 普通反向代理
• 静态资源网站

典型链路：

用户 -> Nginx -> Spring Boot
用户 -> Nginx -> Vue 静态页面

特点：

• 性能强
• 稳定
• 配置相对简单
• 但不太适合写复杂业务逻辑

2. OpenResty

OpenResty 可以理解成：

Nginx + Lua 编程能力

它比普通 Nginx 更灵活，可以通过 Lua 写代码处理请求。

适合场景：

• 动态鉴权
• 访问 Redis
• 复杂限流
• 灰度发布
• 动态路由
• 自定义网关逻辑

例如：

请求进来
  ↓
OpenResty 查询 Redis 判断 token
  ↓
通过后再转发给后端服务

特点：

• 性能强
• 可编程
• 适合高并发网关
• 但需要懂 Nginx 和 Lua

3. Spring Cloud Gateway

Spring Cloud Gateway 是 Java / Spring Cloud 生态里常用的网关，比较适合微服务系统。

主要能力：

• 路由转发
• 鉴权过滤器
• 限流
• 熔断
• 重试
• 服务发现
• 和 Nacos / Eureka / Consul 集成

典型结构：

前端
  ↓
Spring Cloud Gateway
  ↓
用户服务 / 订单服务 / 文件服务

如果项目使用 Spring Cloud、Nacos、Sentinel，那么 Spring Cloud Gateway 是很常见的选择。

特点：

• Java 生态友好
• 容易写自定义逻辑
• 适合微服务系统
• 性能和资源占用通常不如 Nginx 轻

4. Kong

Kong 是一个成熟的 API 网关产品，底层和 OpenResty 关系比较深。

常见能力：

• 路由
• 鉴权
• 限流
• 日志
• 插件
• API 管理
• 服务治理

适合场景：

• 企业 API 网关
• 多团队 API 管理
• 插件化管理接口能力

特点：

• 产品化程度高
• 插件丰富
• 适合企业 API 管理
• 比自己写 OpenResty 更开箱即用

5. Apache APISIX

APISIX 也是高性能 API 网关，国内资料相对比较多。

常见能力：

• 动态路由
• 限流
• 鉴权
• 灰度发布
• 服务发现
• 插件扩展
• 可观测性

适合场景：

• 高性能 API 网关
• 云原生系统
• 微服务入口
• Kubernetes 场景

特点：

• 性能强
• 动态配置能力好
• 插件丰富
• 国内资料相对多

6. Traefik

Traefik 在 Docker 和 Kubernetes 场景中比较常见。

它的特点是可以自动发现服务。比如你在 Docker 里启动了一个服务，Traefik 可以根据标签自动生成路由。

适合场景：

• Docker
• Kubernetes
• 容器化部署
• 自动服务发现

特点：

• 配置自动化能力强
• 对容器环境友好
• 适合 DevOps / 云原生环境

7. Envoy

Envoy 是云原生领域很重要的代理 / 网关。很多 Service Mesh，比如 Istio，就大量使用 Envoy。

适合场景：

• 大型微服务系统
• Service Mesh
• 服务间通信治理
• 高级流量控制
• 可观测性

特点：

• 功能强
• 适合大规模系统
• 学习成本较高

8. Kubernetes Ingress Controller

如果服务部署在 Kubernetes 里，经常会用到 Ingress Controller。

常见实现：

• Nginx Ingress Controller
• Traefik Ingress
• APISIX Ingress
• Kong Ingress

它主要解决的问题是：

外部流量如何进入 Kubernetes 集群内部服务

典型结构：

用户
  ↓
Ingress Controller
  ↓
K8s Service
  ↓
Pod

四、这些网关大概怎么选？

1. 普通前后端分离项目

例如：

Vue + Spring Boot

一般可以先选：

Nginx

原因是够用、简单、稳定。

2. 需要在网关里写复杂逻辑

比如：

• 查询 Redis 做鉴权
• 动态限流
• 灰度发布
• 复杂请求改写

可以考虑：

OpenResty
APISIX
Kong

3. Java 微服务项目

例如：

Spring Cloud + Nacos + Sentinel

可以考虑：

Spring Cloud Gateway

原因是它和 Java / Spring Cloud 生态整合比较舒服。

4. Docker / Kubernetes 环境

可以考虑：

Traefik
Nginx Ingress
APISIX Ingress
Kong Ingress
Envoy

5. 企业 API 管理

如果需要这些能力：

• API 鉴权
• API 文档
• 开发者管理
• 插件管理
• 调用统计
• 多租户

可以考虑：

Kong
APISIX

五、网关可以分成几类？

1. Web 网关 / 反向代理网关

代表工具：

Nginx
OpenResty
Apache HTTP Server

主要解决：

• 网站入口
• 反向代理
• HTTPS
• 静态资源
• 负载均衡

2. API 网关

代表工具：

Kong
APISIX
Spring Cloud Gateway

主要解决：

• API 路由
• 鉴权
• 限流
• 熔断
• 灰度
• API 管理

3. 云原生网关

代表工具：

Traefik
Envoy
Ingress Controller

主要解决：

• 容器服务发现
• Kubernetes 入口流量
• 服务治理
• 动态配置

4. Service Mesh 数据面代理

代表工具：

Envoy
Linkerd Proxy

主要解决：

• 服务和服务之间的通信治理
• 熔断
• 重试
• 链路追踪
• 流量切分
• 安全通信

这一类更偏大型微服务架构。

六、网关和 Nginx 是什么关系？

可以这样理解：

网关是一个角色 / 架构概念
Nginx 是实现网关的一种工具

类似：

数据库是概念
MySQL 是一种数据库

网关是概念
Nginx / Spring Cloud Gateway / Kong / APISIX 都可以做网关

所以不要把“网关”和“Nginx”完全等同。

Nginx 可以当网关，但网关不一定是 Nginx。

七、网关和注册中心是什么关系？

注册中心，比如：

Nacos
Eureka
Consul
Zookeeper

负责记录：

• 现在有哪些服务
• 每个服务在哪台机器
• IP 是多少
• 端口是多少
• 是否健康

网关负责：

• 接收用户请求
• 根据路由找到对应服务
• 把请求转发过去

两者配合起来的链路大概是：

用户请求
  ↓
网关
  ↓
从注册中心知道 user-service 有哪些实例
  ↓
转发到其中一个实例

所以可以这样记：

注册中心负责“服务在哪里”
网关负责“请求怎么进来、转发到哪里”

八、网关和负载均衡是什么关系？

负载均衡只是网关的一种能力。

网关通常可以做：

• 路由
• 鉴权
• 限流
• 日志
• 监控
• 灰度
• 负载均衡

而负载均衡只关注一件事：

请求分给哪台服务器

所以：

负载均衡 ⊂ 网关能力

九、网关在系统中的位置

一个比较完整的系统链路可能是：

用户浏览器 / App
        ↓
CDN
        ↓
Nginx / OpenResty
        ↓
API 网关：Spring Cloud Gateway / Kong / APISIX
        ↓
业务服务：用户、订单、库存、支付
        ↓
数据库 / Redis / MQ

注意：真实项目里不一定每一层都有。

小项目可能是：

用户
 ↓
Nginx
 ↓
Spring Boot
 ↓
MySQL

中大型微服务项目可能是：

用户
 ↓
Nginx
 ↓
Spring Cloud Gateway
 ↓
多个微服务
 ↓
数据库 / Redis / MQ

十、我的理解总结

这句话最重要：

网关就是系统的统一入口，负责把请求安全、准确、高效地转发到后端服务。

从“解决问题”的角度看，可以这样记：

入口混乱       -> 统一入口
服务暴露       -> 隐藏内部服务
重复鉴权       -> 统一鉴权
请求太多       -> 限流
服务压力大     -> 负载均衡
上线有风险     -> 灰度发布
问题难排查     -> 统一日志和监控
前端调用复杂   -> 统一 API 地址

如果目前主要做 Spring Boot 项目，我觉得学习顺序可以是：

1. Nginx：先掌握反向代理、静态资源、HTTPS
2. Spring Cloud Gateway：再理解 Java 微服务网关
3. OpenResty / APISIX / Kong：有需要再深入

刚开始不要一上来就学 Kong、APISIX、Envoy，概念会比较多。先把 Nginx + Spring Boot 的请求转发链路 搞明白，网关这个概念基本就通了。