面经策

你项目里为什么选择 Gateway 作为网关？ ​

  • 标签：Spring Cloud Gateway、微服务、后端、Spring Cloud

🏛 业务架构师 ​

我选 Spring Cloud Gateway 的理由，按决策权重排：

  1. 技术栈一致性（首要理由）：团队是 Java/Spring Cloud 全家桶（Nacos + OpenFeign + Sentinel），Gateway 用同一套技术栈、同一套配置体系、同一个注册中心——网关的定制开发（鉴权、灰度、审计）就是写 Java 代码，团队掌控力最强。网关是核心组件，出问题时能自己改，比"等社区/等厂商"快太多；

  2. 生态集成零成本：与 Nacos（服务发现+动态路由）、Sentinel（网关限流）、LoadBalancer 原生集成——现成能力拼装，自研量最小；

  3. 性能满足业务量级：基于 WebFlux/Netty 的响应式非阻塞模型，万级 QPS 场景绰绰有余。我们压测过：与 Nginx 直转相比，多一层网关的延迟增加在个位数毫秒——对业务 RT 完全可接受。不为想象中的百万 QPS 预付复杂度；

  4. 扩展模型够用：GlobalFilter + Predicate 的模型清晰，我们落地的横切能力——统一 JWT 鉴权、租户识别、灰度路由（按用户标签分流）、接口审计日志、防重放——全部是标准 Filter 实现，治理规范代码化、版本化管理。

同时说明"为什么不选别的"（体现决策完整性）：Kong/APISIX 性能更强，但 Lua 插件开发超出团队栈，等于把命脉交给少数人；Nginx 层我们保留，但只做静态资源与最前置的 LB——分层而不是二选一。

一句话：网关选型是"团队能不能养得住"的决策，性能参数反而靠后。

🏗 系统架构师 ​

我的决策理由（对标排除式）：

  1. 对 Zuul 1：阻塞 IO 一请求一线程，高并发下线程与内存成为瓶颈，且 Netflix 停维护；Zuul 2 虽 Netty 化但未进 Spring Cloud 体系，社区文档弱——两者直接出局；
  2. 对 Nginx/APISIX：我们的网关层有大量业务语义定制（登录态解析、租户路由、灰度规则、内部鉴权协议）——Java 团队在 SCG 上写 Filter 是主场作战：类型安全、复用公司中间件 SDK、可单测；Lua 侧定制需要稀缺技能，发布与测试链路都要重建；
  3. 生态整合：与 Nacos（服务发现路由）、Sentinel（网关限流熔断）、Spring Security（OAuth2 资源服务器）开箱拼装；
  4. 性能达标：内网网关瓶颈通常在下游与内部逻辑，SCG 单实例（4C8G 量级）数万 RPS 满足绝大多数场景。

反向说明（体现权衡诚实）：若公司由平台团队统一运营 API（门户、计费、多语言后端），APISIX/Higress 的控制台与插件生态更合适——技术选型服从组织形态，这是我的结论。

💻 全栈开发专家 ​

答项目决策，我给过这套论证：

  1. 技术栈一致：团队 Java/Spring，网关 Filter/谓词用 Java 写，断点调试、单测、CI 全链路复用现有工程体系；对照 Kong（Lua 二开）、APISIX（Lua/Go），我们没这块人力储备
  2. 生态融合：与 Nacos（lb:// 服务发现 + 动态路由）、Sentinel（网关流控规则控制台）开箱集成；Spring Cloud Alibaba 全家桶下这是最短路径
  3. 性能够用：Netty 异步非阻塞，单实例数万 QPS，撑住我们入口峰值（万级）有余；网关水平扩展，瓶颈从来不在这层
  4. 能力满足：Predicate/Filter 模型覆盖鉴权、限流、灰度路由、日志埋点全部诉求；IO 型转发场景正是响应式模型的主场

也交代没选其他的理由（显得决策全面）：Zuul 停更且阻塞模型出局；Kong/APISIX 运维栈不匹配（当时团队 K8s 经验浅，etcd 体系不想再加）；纯 Nginx 要专人维护 Lua 脚本。

上线后的实证：P99 转发开销稳定 3ms 内；大促演练中 Sentinel 网关流控把洪峰削掉 30%。选型结论：技术匹配团队 > 单项性能指标。