微服务架构下，客户端直接访问数十个内部服务既不安全也难维护。API网关作为统一入口，承担路由转发、认证鉴权、限流熔断、协议转换、日志监控等横切职责。但网关选型众口难调：Java栈团队倾向Spring Cloud Gateway，云原生团队偏爱APISIX与Envoy。本文从核心维度对比主流网关，帮助上海技术团队做出合理决策。

一、网关的核心职责

统一入口与横切关注点

网关是所有外部请求的第一站，客户端只需知道网关地址。横切关注点集中在网关处理：HTTPS终结、身份认证、JWT校验、请求限流、IP黑白名单、CORS跨域、请求日志、链路追踪。后端业务服务专注业务逻辑，不重复实现这些通用能力。上海团队应明确：网关做"通用横切"，不做"业务编排"，避免把网关变成臃肿的"大泥球"。

服务发现与动态路由

微服务实例动态上下线，网关需对接服务注册中心（Nacos、Consul、Eureka）自动感知后端实例变化，做客户端负载均衡。路由规则可按路径、Header、域名、用户身份灵活匹配。上海团队应将路由配置与代码分离，支持动态生效，避免改路由要发版。

二、主流网关对比

Spring Cloud Gateway：Java栈首选

基于Spring WebFlux响应式非阻塞模型，与Spring Cloud生态无缝集成。优点：Java团队上手快、可自定义Filter用Java编写、与Nacos/Spring Security集成开箱即用、企业文档丰富；缺点：基于JVM内存占用较大、冷启动慢、极高并发下性能不如Nginx类。适合上海以Java为主、内部微服务、对性能要求中等的团队。

Kong：老牌API网关

基于Nginx与OpenResty，插件生态丰富（认证、限流、日志、转换等上百插件）。优点：性能优异、管理界面成熟、企业版支持企业级功能；缺点：Lua插件开发对部分团队有门槛、动态配置依赖数据库（Cassandra/PostgreSQL）、云原生原生性一般。适合上海需要丰富插件、对外API开放平台场景。

APISIX：云原生后起之秀

基于Nginx + etcd，动态配置通过etcd实时推送，无需重启。优点：性能极高（远超Kong）、热更新、云原生友好（K8s Ingress Controller）、插件用Lua/Wasm编写、控制台友好；缺点：社区相对年轻、企业功能需商业版。适合上海云原生环境、高性能、动态路由场景。

Envoy：数据平面标准

由Lyft开源，作为服务网格（Istio）的数据平面，是现代云原生架构的事实标准。优点：L3/L4/L7代理、极致性能、xDS动态配置、丰富过滤器、与服务网格深度集成；缺点：配置复杂、无独立管理界面、学习曲线陡。适合上海已采用服务网格、需要细粒度流量治理的团队。

三、选型关键维度

性能与资源占用

网关是所有请求必经之路，性能瓶颈会被放大数倍。Nginx类（Kong、APISIX）单机可达每秒数万至十万请求；Spring Cloud Gateway单机在数千至万级；Envoy性能与APISIX接近。上海团队应根据预期QPS选型：内部系统数千QPS用Spring Cloud Gateway足够；对外开放API每秒数万请求选APISIX或Kong。同时关注内存占用，JVM类网关内存通常是Nginx类的3至5倍。

动态配置与热更新

路由规则、限流策略、证书变更应秒级生效，不重启网关。APISIX通过etcd推送实现纯动态；Kong需重启或数据库同步；Spring Cloud Gateway依赖配置中心刷新；Envoy通过xDS推送。上海团队在频繁调整路由（如灰度发布、AB测试）场景下，动态配置能力是硬指标。

插件与扩展生态

横切需求会不断增加：新增认证方式、特殊协议转换、定制日志格式。网关插件生态决定扩展成本。Kong与APISIX插件市场成熟，多数常见需求无需自研；Spring Cloud Gateway自定义Filter灵活但需开发发版。上海团队应评估未来12个月可能的扩展需求，选生态匹配的产品。

四、高可用与部署

无状态横向扩展

网关本身应无状态，会话状态外存（Redis），多实例 behind 负载均衡（LVS/Nginx/云LB）。任一网关实例故障不影响整体。上海团队应至少部署2个实例跨可用区，避免单机房故障。网关配置中心（etcd/数据库）自身也要高可用。

灰度发布与流量治理

现代网关应支持按权重、按Header、按用户标签路由，实现灰度发布与A/B测试。APISIX与Envoy在流量染色上能力最强；Spring Cloud Gateway需结合灰度框架。上海团队应将网关作为流量治理核心，配合服务注册中心实现精细化发布。

五、安全与可观测性

网关层安全防护

HTTPS终结、WAF防护、IP限流、JWT校验、OAuth2.0资源服务器，这些都应在网关统一实施。上海团队应避免让后端服务直接暴露公网，所有入口收口到网关。证书自动续期、HSTS、安全响应头也在网关统一配置。

日志、指标与链路追踪

网关是最佳观测点：记录每个请求的路径、状态码、耗时、来源IP、下游服务。指标（QPS、延迟分位数、错误率）暴露给Prometheus；链路追踪注入Trace Header传递到下游；访问日志输出到ELK。上海团队应建立网关看板，异常突增时第一时间定位。

六、常见坑点

把网关当业务编排层

常见反模式：在网关写聚合接口（并行调用多个后端再合并返回）、在网关做业务逻辑判断。这会让网关变成新的单点与巨石。上海团队应坚持网关只做横切，业务聚合放到BFF（Backend For Frontend）层或后端服务。

忽略网关自身故障

网关一旦故障全站不可用。必须演练：网关集群故障、配置中心故障、后端服务全部不可用时网关行为。上海团队应配置优雅降级：后端服务不可用时返回友好错误页而非超时挂起；网关自身多实例跨可用区。

七、上海团队选型建议

分阶段演进

初创期：Spring Cloud Gateway足够，与技术栈一致、快速上线。成长期：若出现性能瓶颈或动态路由需求，引入APISIX作为入口网关，Java网关退化为内部服务聚合。成熟期：引入服务网格时，Envoy成为数据平面，APISIX作为边缘网关。上海团队不必一开始就选最复杂的方案，匹配当前阶段最重要。

微服务网关选型是架构决策，不是技术潮流追逐。对上海企业而言，Java内部系统选Spring Cloud Gateway、高性能对外开放选APISIX、服务网格环境用Envoy。建议上海团队在选型前做POC压测，验证性能、动态配置、插件扩展三项关键能力后再落地。

八、网关与服务网格的边界

边缘网关与Side车分工

很多团队混淆边缘网关（North-South流量）与服务网格Side车（East-West流量）。边缘网关负责外部请求入口：认证、限流、路由、HTTPS终结；Side车负责服务间通信：熔断、重试、服务发现、mTLS。两者不重复建设，而是分层协作。上海团队应避免在Side车做边缘认证（所有服务都要面对公网暴露面），也不要在边缘网关做服务间细粒度熔断（规则爆炸）。

网关演进路线

早期单网关即可；多团队多业务线后，按业务域拆分多个网关实例（如交易网关、内容网关），统一由配置中心管理；云原生阶段，边缘用APISIX/Kong，内部用Istio+Envoy。上海团队应根据团队规模与业务复杂度演进，不要在三人团队时引入服务网格，那是过度工程。