面经策

说说什么是 API 网关？它有什么作用？ ​

  • 标签：后端、分布式、Spring Cloud

🏛 业务架构师 ​

API 网关是所有外部流量的统一入口，把"每个服务各自处理的事情"收口成一处。核心职责：路由转发、认证鉴权、限流熔断、灰度分流、协议转换、日志审计、API 聚合。

业务架构视角，网关是"变现了的管控点"——我在这些场景反复兑现它的价值：

  • 安全收口：统一鉴权（token 校验、签名验证）、防刷限流、WAF 联动。没有网关时每个服务自己写鉴权，漏一个就是数据泄露；收口后安全策略一次升级全站生效；
  • 灰度与发布安全：按用户 ID 尾号/地域/设备把 5% 流量导向新版本——新功能的风险控制从"全量祈祷"变"小流量验证"，配合快速回滚，发布事故率数量级下降；
  • 多端协议适配：App、小程序、H5、开放平台各有一套接入协议，网关做转换，后端服务保持一套干净的业务 API；
  • 商业能力挂载：开放平台的 API 计量计费、配额管理、_partner 分账**——对外卖 API 的业务，网关就是计费柜台；
  • 可观测性：全量请求的访问日志、trace 采样起点，业务大盘的数据源头。

成本与提醒：

  • 网关自身是单点风险——要集群化 + 过载保护（网关自己的 CPU/连接数水位），网关挂全站挂；
  • 功能克制：网关做"横切"，不做业务逻辑——把业务规则写进网关是常见的腐化起点，最后网关变成没人敢动的怪物。

选型务实：Spring Cloud Gateway（生态整合）、Kong/APISIX（插件丰富、性能强）、Higress（云原生）。按团队技术栈与治理需求选，别为性能差异牺牲可维护性。

🏗 系统架构师 ​

API 网关是微服务体系的统一南北向入口，把"与业务无关但每个服务都需要"的横切能力收口到一层：

核心职责：

  • 路由与协议转换：外部 HTTP/HTTPS 请求按路径/域名/Header 路由到内部服务，可做 HTTP → Dubbo/gRPC 的协议适配；
  • 统一鉴权：JWT 验签、OAuth2、签名校验、会话/黑名单检查，下游服务无感获得身份上下文；
  • 流量治理：限流（网关层第一道防线）、熔断降级、黑白名单、防重放、请求校验；
  • 可观测性：访问日志、trace 透传（生成全局 traceId）、 metrics 打点、审计；
  • 发布能力：灰度路由（按用户/权重分流到新版本）、蓝绿、A/B 实验分流。

架构价值：客户端只面对一个域名，内部拓扑变化不外泄；安全策略改一处全生效；服务只关心业务，横切关注点不重复建设——本质是外观模式 + 责任链的系统级落地。

选型：Spring Cloud Gateway（WebFlux 响应式，Java 生态亲和）、Kong/OpenResty（Lua 扩展，性能强插件生态好）、APISIX（etcd 配置中心、动态热更新）、Envoy（Service Mesh sidecar/入口两用）。我的实践：网关层保持"薄"，重业务逻辑不下沉，避免网关成为开发瓶颈；网关本身无状态多副本 + SLB 部署，它是单点风险最高的组件，可用性目标要最高。

💻 全栈开发专家 ​

API 网关 = 系统的统一入口，把"每个服务都要做一遍"的事情收口到一处：

  • 动态路由：按 path/host/权重把请求转到后端服务；
  • 统一鉴权：JWT 验签、登录态校验，下游无感拿 userId；
  • 限流熔断：接口级/用户级限流，保护后端；
  • 灰度发布：按 header/权重切流量；
  • 聚合与裁剪：BFF 聚合、协议转换（HTTP→RPC）；
  • 可观测：访问日志、traceId 注入、监控埋点。

主流实现：Spring Cloud Gateway（Netty + WebFlux，响应式）、APISIX/Kong（Nginx + Lua，高性能插件生态）、Higress（阿里，AI 网关趋势）、Zuul（淘汰中）。

SCG 的路由配置实操：

yaml
spring:
  cloud:
    gateway:
      routes:
        - id: order-service
          uri: lb://order-service        # 从注册中心负载均衡
          predicates:
            - Path=/api/order/**
          filters:
            - StripPrefix=1
            - name: RequestRateLimiter   # 令牌桶限流
              args:
                redis-rate-limiter.replenishRate: 100

我落地的体会：

  1. 网关逻辑要薄，业务逻辑下沉，网关只做横切面；全局过滤器统一注入 traceId 和鉴权；
  2. 网关自身要高可用（多实例 + 前面 LB），它是单点风险最高的组件；
  3. WebFlux 响应式代码里写阻塞调用（JDBC）会打爆 event loop，需要阻塞逻辑就丢 boundedElastic 调度器。