微服务外部流量需要统一入口。本文整理网关的核心职责、能力边界与选型思路，帮助区分哪些逻辑该放网关、哪些必须回到业务服务或 BFF，避免网关膨胀成第二套单体。

要解决什么问题

服务拆分后，认证、限流、日志若在每个服务重复实现，代码冗余且策略难统一。客户端直连多服务还暴露内部拓扑，协议和安全策略也难以集中治理。大促前若要调整全站限流阈值，没有网关就需要逐服务发版，风险高、回滚慢，观测也无法在入口层做统一大盘。

核心原理

网关位于客户端与后端之间，核心做两件事：请求转发（动态路由、负载均衡、协议转换）和请求过滤（身份认证、权限校验、限流熔断、日志监控）。典型链路是客户端→前置负载均衡→网关集群→注册发现→目标服务。网关本身也要多实例部署，否则会成为新的单点；与 RPC 层分工是：网关面向南北向外部流量，RPC 面向东西向内部调用。

方案权衡

Spring Cloud Gateway 与 Spring 生态集成好，基于 WebFlux 异步 IO；Kong、APISIX 偏高性能与插件生态，适合多语言栈。Zuul 1.x 已进入维护模式，新项目不建议选用。网关应承载协议级、通用型、跨服务的能力；复杂字段映射、长事务、细粒度业务授权应留在 BFF 或领域服务，否则网关代码难以测试和演进。

落地要点

生产实践要点：网关集群前置 Nginx 或云 LB；SSL 证书在网关集中终结；限流 key 区分 IP、用户、接口；灰度通过 Header 或权重路由；与链路追踪集成传递 traceId。选型时做压测对比 P99 延迟，并验证动态路由配置能否与 CI/CD 联动。Spring 栈新项目优先 Gateway，追求极致吞吐和多租户插件可选 APISIX。

常见误区

误区包括在网关写大量业务规则导致发布耦合；忽视网关自身 HA；把 Hystrix 当作 QPS 限流组件；在网关做复杂响应聚合和业务编排。另一个常见问题是 Filter 中使用阻塞 JDBC，在 reactive 模型下会拖垮事件循环，应改为异步或非阻塞调用。