1. API 网关概述：定义、作用、发展历程

1.1 到底什么是 API 网关？

说白了，API 网关就是系统对外的“总闸门”。

所有客户端请求——不管是手机 App、网页还是第三方服务——都先打到网关。然后由网关决定：这个请求该转发给哪个后端服务，要不要做身份校验，要不要限流。

我习惯把网关理解成“系统的门卫+前台”的组合体。门卫查证件，前台做路由转发。

举个例子。你开发了一个电商系统，订单服务、库存服务、支付服务各自独立。如果没有网关，客户端就要分别调用这些服务。有了网关，客户端只管往网关发请求，网关帮你搞定后面的一切。

1.2 API 网关到底解决了什么问题？

让我从实战角度给你拆解一下。网关的核心作用可以归纳为四大类：

类别	具体作用	真实场景
请求路由	根据 URL、Header 等条件将请求分发到对应后端	订单接口 /api/order 路由到订单服务
安全防护	身份认证、权限校验、IP 白名单、防注入	校验 JWT ，拦截未授权的访问
流量治理	限流、熔断、降级、重试	突发流量下只允许 1000 QPS 通过
协议转换	HTTP 转 gRPC、WebSocket 转 HTTP、数据格式映射	前端需要 JSON，后端返回 Protobuf
监控与日志	全链路跟踪、访问日志、指标采集	记录每次请求的耗时时长和状态码

你想想看，如果没有网关，这些功能就要分散到每个微服务里去实现。每个服务都得写一遍认证、限流、日志……那得多累？

1.3 发展历程：从单体到云原生

API 网关不是一天长成现在这样的。我把它分为三个阶段来讲。

第一阶段：单体时代的“反向代理”

早期 Web 应用是单体架构，前端页面直接请求后端。那时候 Nginx、Apache 扮演的就是“反向代理”角色——把/static 路径映射到静态文件目录，把 /api 路径转发到应用服务器。

但坦白讲，那时的反向代理只做了路由和负载均衡。没什么认证、限流、协议转换的概念。

第二阶段：微服务兴起后的“API 网关”

2014 年左右，微服务架构开始流行。大家发现服务多了之后，客户端直接调用多个服务实在太痛苦。于是出现了专门的 API 网关产品。

比如 Netflix 开源的 Zuul 1.0，就是这方面的早期代表。它能做统一鉴权、路由聚合、限流降级。我记得当时在 Zuul 里写过滤器来处理 JWT 校验，每写一个过滤器就得重启网关……那时候还没热加载的概念。

第三阶段：云原生时代的“服务网格入口”

到了 2018 年之后，Kubernetes 成了事实标准。API 网关开始和 Ingress Controller 结合。比如 Kong Ingress Controller、APISIX Ingress Controller。

更关键的是，Service Mesh 的兴起让网关的定位发生了微妙变化。Istio 的 Ingress Gateway 负责入口流量，Sidecar 负责服务间流量。此时网关不再是“全权代理”，而变成了网格的一部分。

为什么会这样？因为云原生环境要求网关能感知服务注册、动态路由、金丝雀发布。传统网关根本做不到。

1.4 核心知识图谱

这一章的内容逻辑，我用一张图帮你理清。

1.5 小结：这一章你该带走什么？

• 定义上：API 网关是微服务架构的“总入口代理”。它不等同于反向代理，功能范围广得多。
• 作用上：路由、安全、流量治理、协议转换、监控——这五件事最好由网关统一处理，不要分散到各个服务里。
• 发展上：从反向代理到微服务网关再到云原生网关，本质是在应对“服务越来越多、流量越来越复杂”的现实。