当你的系统从单体架构走向微服务，原本一个庞大的应用被拆成了几十个独立的服务。这时候，前端开发者可能会崩溃：“以前调一个域名就能搞定，现在查个用户详情要调用户服务，查订单要调订单服务，查商品要调商品服务……难道我要在代码里写几十个不同的 IP 和端口？”
更可怕的是，如果每个微服务都自己处理登录鉴权、限流、日志，那同样的代码要在几十个服务里写几十遍，维护成本直接爆炸。
这时候，API 网关（API Gateway）就该登场了。它就像是微服务架构的“超级门卫”和“总调度室”，所有外部请求都必须先经过它，再由它统一分发。今天我们就来拆解，API 网关到底在干嘛，以及为什么它是微服务的标配。
一、 核心职责 1：统一入口与智能路由
API 网关最基础的作用，就是屏蔽后端复杂性。
对于前端或外部调用方来说，整个后端集群只有一个域名（比如 api.yourcompany.com）。网关接收到请求后，会根据 URL 路径、请求头等规则，把请求精准地转发到对应的后端服务。
路径路由：/api/users/ 转发给用户服务，/api/orders/ 转发给订单服务。
动态服务发现：网关对接注册中心（如 Nacos、Eureka），后端服务扩容或宕机时，网关能自动感知并更新路由表，前端完全无感。
灰度发布：网关可以按规则分流，比如把 10% 的请求导向新版本服务，90% 导向老版本，实现平滑上线。
二、 核心职责 2：统一鉴权与安全防线
如果没有网关，每个微服务都要自己写一套 JWT 验证、OAuth2 鉴权逻辑。有了网关，这些横切关注点全部上提到网关层统一处理。
统一认证：网关拦截所有请求，验证 Token 是否合法。验证通过后，把用户信息塞进请求头，再转发给后端服务。后端服务只需要信任网关即可，不再重复验证。
安全防护：集成 WAF（Web 应用防火墙），拦截 SQL 注入、XSS 攻击；配置 IP 黑白名单，把恶意爬虫挡在门外。
TLS/SSL 终结：所有的 HTTPS 加解密在网关层统一完成，后端微服务之间走 HTTP 明文通信，既安全又高效。
三、 核心职责 3：流量治理与保护
网关是系统的“第一道防线”，当流量洪峰到来时，它能保护后端服务不被压垮。
限流（Rate Limiting）：基于 IP、用户 ID 或接口维度，限制每秒请求数。比如限制“发送验证码”接口每个手机号每分钟只能调 1 次。
熔断降级（Circuit Breaking）：当某个下游服务响应超时或错误率飙升时，网关直接熔断，不再把请求发过去，而是返回兜底数据或友好提示，防止“雪崩效应”。
负载均衡：网关内置轮询、加权、最少连接等算法，把流量均匀分配到多个服务实例上。
四、 核心职责 4：协议转换与数据聚合
协议转换：对外暴露 RESTful API，对内微服务之间用高性能的 gRPC 或 Dubbo 通信。网关在中间做协议翻译，兼顾了外部兼容性和内部性能。
请求聚合（BFF 模式）：前端渲染一个页面可能需要调 5 个微服务。网关可以一次性并行调用这 5 个服务，拼装好数据后统一返回，把 5 次网络请求变成 1 次，大幅降低延迟。
五、 常见的 API 网关选型
网关 特点 适用场景
Nginx / OpenResty 性能极高，配置灵活 适合做边缘网关、静态资源代理
Spring Cloud Gateway Java 生态，响应式编程 适合 Java 技术栈的微服务网关
Kong 基于 Nginx，插件丰富 适合需要大量扩展能力的企业级网关
APISIX 国产开源，高性能，动态路由 适合高并发、云原生场景
Envoy 云原生标配，Service Mesh 核心 适合 K8s 环境和 Service Mesh 架构
结语：
API 网关不是万能的，它本身也可能成为性能瓶颈。所以生产环境中，网关通常要做多实例集群部署，甚至采用“两层网关”架构（外层 Nginx 做 SSL 终结和静态资源，内层 Spring Cloud Gateway 做微服务路由和鉴权）。
但不可否认，API 网关是微服务架构的“基础设施”。它把那些重复的、非业务的逻辑从微服务中剥离出来，让每个服务都能专注自己的核心业务。
