1. API Gateway 概述
1.1 什么是 API Gateway
API Gateway（API 网关）是微服务架构中位于客户端与后端服务之间的统一入口层。它负责接收所有外部请求，执行协议转换、请求路由、认证鉴权、流量控制、日志监控等横切关注点，再将请求转发给内部微服务。从网络拓扑看，API Gateway 是系统的“前门”，所有客户端流量必须经过此节点。
核心定义：API Gateway 是一个反向代理服务器，封装了内部微服务的复杂调用关系，对外提供统一的 REST/HTTP 或 gRPC 接口，同时承担协议适配、安全防护、流量治理等中间件职责。
1.2 API Gateway 的核心价值
API Gateway 并非简单的反向代理，它在微服务架构中提供了以下六大核心价值：
| 核心价值 | 说明 | 典型场景 |
|---|---|---|
| 统一入口 | 所有客户端只与网关交互，屏蔽后端服务地址与拓扑变化 | 服务拆分、扩缩容对客户端透明 |
| 协议转换 | 将外部 HTTP/HTTPS 请求转换为内部 gRPC、Dubbo、Thrift 等协议 | 移动端 REST ↔ 后端 RPC |
| 安全防护 | 集中处理认证、鉴权、IP 白名单、防 SQL 注入、防重放攻击 | OAuth2.0 / JWT 校验 |
| 流量治理 | 限流、熔断、降级、重试、灰度发布 | 秒杀场景限流、服务雪崩防护 |
| 观测与治理 | 全链路日志、请求追踪、指标采集、调用链分析 | Prometheus + Grafana 监控 |
| 聚合与编排 | 将多个微服务响应聚合成一个客户端响应，减少网络往返 | BFF（Backend For Frontend）模式 |
实践建议：在微服务初期（少于 10 个服务）可以暂不引入网关，直接使用 Nginx 做简单路由；当服务数量超过 20 个或需要协议转换、统一鉴权时，必须引入专业 API Gateway。
1.3 在微服务架构中的位置
API Gateway 位于客户端与微服务集群之间，是微服务架构中南北向流量（客户端到服务端）的唯一入口。它与服务注册中心、配置中心、监控系统等基础设施协同工作，形成完整的微服务治理体系。
从架构分层看，API Gateway 处于以下位置：
- 接入层：直接面对客户端，处理 TLS 终止、HTTP 协议解析、请求校验。
- 网关层：执行路由匹配、中间件链（认证→限流→日志→转发）、协议转换。
- 服务层：通过服务发现（Consul / Nacos / Eureka）动态获取后端实例列表，完成负载均衡转发。
1.4 与传统 API 管理器的区别
传统 API 管理器（如 Apigee、Kong 早期版本、AWS API Gateway 的纯管理模式）主要面向API 生命周期管理（发布、订阅、文档、计费），而微服务架构中的 API Gateway 更强调运行时流量治理与协议适配。两者的核心差异如下：
| 对比维度 | 传统 API 管理器 | 微服务 API Gateway |
|---|---|---|
| 核心目标 | API 的发布、管理、监控、变现 | 请求路由、协议转换、流量治理、安全防护 |
| 部署位置 | 通常部署在 DMZ 区，独立于业务服务 | 嵌入微服务架构，与服务注册中心紧密集成 |
| 协议支持 | 以 REST/HTTP 为主，支持 SOAP | HTTP、gRPC、Dubbo、Thrift、WebSocket、MQTT |
| 服务发现 | 静态配置后端地址 | 动态服务发现（Consul / Nacos / K8s） |
| 中间件扩展 | 插件市场有限，以管理功能为主 | 可编程中间件链，支持自定义 Filter/Plugin |
| 流量治理 | 基础限流，无熔断/降级 | 限流 + 熔断 + 降级 + 重试 + 灰度发布 |
| 典型产品 | Apigee、AWS API Gateway（管理模式）、MuleSoft | Kong、Spring Cloud Gateway、Envoy、APISIX |
常见误区：不要将 API Gateway 与传统 ESB（企业服务总线）混淆。ESB 侧重消息转换与编排，通常部署在内部服务之间（东西向流量）；API Gateway 侧重外部请求接入与治理（南北向流量），两者职责不同，但在某些场景下可以互补。
1.5 本章小结
API Gateway 是微服务架构中不可或缺的流量入口组件，它统一了客户端接入方式，将认证、限流、协议转换、日志等横切关注点从业务服务中剥离出来，让后端微服务专注于业务逻辑。与传统 API 管理器相比，微服务 API Gateway 更强调运行时动态治理和多协议适配，是构建高可用、可观测、可扩展的微服务系统的关键基础设施。