微服务架构中，客户端需要调用几十个后端服务——每个服务都独立做认证、限流、日志、CORS，是巨大的重复与不一致风险。API 网关是所有请求的统一入口：路由分发、认证鉴权、限流熔断、日志聚合在网关层统一处理——后端服务专注于业务逻辑，横切关注点收编到网关。本篇讲清网关的职责边界、主流网关的对比、以及「什么该放网关、什么不该放」的分界。
网关的四大职责
职责一：路由分发。将请求路由到正确的后端服务——路由规则基于路径（/api/users/* → 用户服务）、请求头（版本路由：X-API-Version: v2 → v2 服务）、权重（金丝雀发布——本库专篇）。动态路由是网关的核心能力：路由规则不重启即可更新（从配置中心拉取规则——本库《配置中心》）、按标签自动路由（服务实例打上版本标签，网关自动路由到指定标签的实例——灰度发布的基础设施）。
职责二：认证与鉴权。统一认证：客户端只需在网关做一次认证（JWT 验证、API Key 校验、OAuth Token 检查——本库《OAuth 2.0》），网关验证后将用户身份信息注入请求头（如 X-User-Id），后端服务信任网关注入的头而不需要重复验证。鉴权的边界：网关做粗粒度鉴权（是否登录、是否有 API 访问权限），后端服务做细粒度鉴权（是否有权操作这条具体的数据——资源级别的 ACL 不适合网关，因为网关不了解业务数据）。
职责三：限流与熔断。在网关层统一限流（按 API Key、按 IP、按用户——本库《一篇读懂限流器》的算法在网关的集中实施），防止任何单一客户端或后端服务被打垮。网关层的熔断（对后端服务的熔断——某服务不可用时快速失败，不将请求发向已经过载的服务）。职责四：可观测性。统一日志（每个请求的访问日志：来源、路由、耗时、状态码）、链路追踪的入口（生成 traceId 注入请求头，后端服务透传——本库《可观测性》）、以及指标聚合（QPS、延迟分布、错误率的统一监控面板）。
主流网关的对比
Nginx / OpenResty：性能最强（C 语言 + Lua 脚本），生态最成熟；但动态路由配置需要 reload 或 Lua 脚本，微服务生态集成需要额外开发。Kong：基于 OpenResty 的 API 网关，插件生态丰富（认证、限流、日志等数百个插件），支持声明式配置（Admin API / declarative config），多语言友好。APISIX：国产开源网关，基于 OpenResty + etcd 动态配置，性能与 Kong 相当但动态配置更灵活，国内社区活跃。Spring Cloud Gateway：Java 生态的网关（基于 Spring WebFlux + Reactor），与 Spring Cloud 生态无缝集成（服务发现、配置中心），适合 Java 技术栈的团队。云厂商托管网关（AWS API Gateway、阿里云 API 网关）：免运维、按量计费、与云生态集成——但厂商锁定与成本是长期考量。
什么该放网关、什么不该放
该放网关的：横切关注点（所有服务都需要的通用功能）——认证与鉴权的粗粒度检查、限流与熔断、请求日志与链路追踪入口、CORS 处理、SSL 终结、响应缓存。不该放网关的：业务逻辑——网关不理解业务规则（「VIP 用户可以超过限流阈值」「黑名单用户的订单要额外审核」——这些是业务逻辑，应放在后端服务中）。重计算——网关的性能定位是「高性能转发」，复杂的计算（数据转换、报告生成）会拖慢网关影响所有请求。数据存储——网关是无状态的（路由规则从配置中心拉取），不在网关存储业务数据。一句话的分界：网关做「协议与流量」的事，后端做「业务与数据」的事——模糊了这个边界，网关就从「加速器」变成了「瓶颈与单点故障源」。
BFF 模式：为前端定制的网关变体
BFF（Backend for Frontend）是 API 网关的一个变体：为每种前端客户端（Web、iOS、Android）各部署一个专属的网关/BFF 层。BFF 的价值：不同前端的需求不同（Web 需要完整的数据视图、移动端需要精简的数据以节省流量、第三方需要受限的 API）——统一的 API 网关无法满足所有前端的差异化需求。BFF 层的职责：聚合多个后端服务的数据为一个响应（一次请求获取首页的全部数据而不是 N 次单独请求）、裁剪数据（只返回当前前端需要的字段）、协议转换（将后端的 gRPC 转换为前端的 REST/GraphQL）。BFF 的团队归属：BFF 由前端团队维护而不是后端团队——因为 BFF 的逻辑是「前端需要什么数据」而不是「后端有什么数据」——BFF 的代码应该是 JavaScript/TypeScript（前端团队的技术栈）。
API 网关的「插件生态」：Kong 与 APISIX 的对比
Kong 与 APISIX 是两个最流行的开源 API 网关，它们的插件生态决定了各自的适用场景。Kong 的插件生态最丰富：认证插件（OAuth2/JWT/LDAP/HMAC）、安全插件（IP 限制/CORS/bot 检测）、流量控制插件（限流/熔断/请求大小限制）、可观测性插件（Prometheus/Zipkin/日志收集）——数百个插件覆盖了 API 网关的绝大多数需求。APISIX 的优势：动态配置（全插件热更新无需重启——Kong 的插件变更需要 reload）、性能（APISIX 的基准测试性能通常优于 Kong）、中文社区活跃（国内团队开发与维护）。选型的建议：国际化的团队或需要丰富插件生态选 Kong；国内团队或需要动态配置选 APISIX；Spring 生态选 Spring Cloud Gateway。
API 网关的 BFF 模式：为前端定制的网关变体
BFF（Backend for Frontend）是 API 网关的一个变体：为每种前端客户端各部署一个专属的网关或 BFF 层。BFF 的价值：不同前端的需求不同——Web 需要完整的数据视图移动端需要精简的数据第三方需要受限的 API——统一的 API 网关无法满足所有前端的差异化需求。BFF 层的职责：聚合多个后端服务的数据为一个响应、裁剪数据只返回当前前端需要的字段、协议转换将后端的 gRPC 转换为前端的 REST。BFF 的团队归属由前端团队维护——因为 BFF 的逻辑是前端需要什么数据而不是后端有什么数据。
API 网关的「什么该放什么不该放」
API 网关的职责边界值得明确。该放网关的：横切关注点所有服务都需要的通用功能——认证与鉴权的粗粒度检查限流与熔断请求日志与链路追踪入口 CORS 处理 SSL 终结响应缓存。不该放网关的：业务逻辑——网关不理解业务规则；重计算——网关的性能定位是高性能转发。一句话的分界：网关做协议与流量的事后端做业务与数据的事——模糊了这个边界网关就从加速器变成了瓶颈与单点故障源。
BFF 模式与 API 网关的关系
BFF 是 API 网关的一个变体为每种前端客户端各部署一个专属的网关层。BFF 的价值不同前端的需求不同统一的 API 网关无法满足所有前端的差异化需求。BFF 层的职责聚合多个后端服务的数据为一个响应裁剪数据只返回当前前端需要的字段协议转换。BFF 的团队归属由前端团队维护。BFF 与 API 网关的关系不是替代而是互补——API 网关处理横切关注点认证限流日志 BFF 处理前端的差异化需求——两者可以共存 API 网关在外层 BFF 在内层。
API 网关的「限流策略」：从全局到细粒度的多层限流
API 网关的限流策略需要多层设计，从粗到细逐层收紧。第一层：全局限流——整个网关的总 QPS 上限（保护网关自身与后端集群）。第二层：按 API 限流——不同 API 路径有不同的限流阈值（核心 API 限流宽松、非核心 API 限流严格）。第三层：按租户/API Key 限流——不同客户有不同的配额（免费用户 100 QPS、付费用户 1000 QPS）。第四层：按用户限流——同一用户在短时间内的请求频率限制（防刷接口）。多层限流的实现通常在网关层统一配置（Kong 的 rate-limiting 插件支持多个维度的配置），配合 Redis 做分布式计数（跨实例共享计数——单机限流在多实例部署时配额会乘以实例数）。多层限流的参数设计需要根据业务的 SLA 与容量规划来定，而不是拍脑袋。
API 网关的「插件架构」：网关的扩展机制
API 网关的扩展能力取决于其插件架构的设计。Kong 的插件架构：插件在请求的不同阶段（证书/重写/访问/头过滤/响应/日志）插入自定义逻辑，插件可以用 Lua 编写（OpenResty 的生态）或用 Go/Python 编写（通过插件服务器）。APISIX 的插件架构：类似 Kong 但更轻量（Lua 编写），支持热更新（插件变更不需要重启网关）。Spring Cloud Gateway 的扩展：通过 GlobalFilter 与 GatewayFilterFactory 两种机制实现自定义过滤器——与 Spring 生态的集成最自然。插件架构的设计原则：插件的加载与卸载不影响网关的运行（热更新）、插件的执行顺序可配置、插件之间通过 Chain 模式传递控制权。
小结
API 网关收成四条：四大职责——路由分发（动态路由 + 版本路由）、认证鉴权（粗粒度，细粒度留给后端）、限流熔断（统一入口的流量保护）、可观测性（日志 + traceId + 指标聚合）；主流网关对比——Nginx 性能最强、Kong 插件生态最丰富、APISIX 动态配置最灵活、Spring Cloud Gateway 适合 Java 生态；该放网关的是横切关注点（协议与流量），不该放的是业务逻辑与重计算——模糊边界网关变瓶颈；选型建议——按技术栈选（Java 选 Spring Cloud Gateway、多语言选 Kong/APISIX）、按规模选（小团队 Nginx 足够、大团队选带控制面的网关）。API 网关的价值不是「又一个中间件」，是把横切关注点从 N 个服务收编到 1 个入口——N 次重复变成 1 次实现。
参考资料
- Kong / APISIX / Spring Cloud Gateway 官方文档
- 本库前篇：《一篇读懂限流器》《Istio 流量管理》《OAuth 2.0》
- Chris Richardson, 《微服务架构设计模式》第 8 章—— API 网关模式
读者留言
COMMENTS 暂无还没有留言，来说第一句？