网关最佳实践与综合面试题

面试开场白

面试官：你们的网关架构是怎么设计的？

这是一道开放性问题，考察你对网关整体架构的把握。能说出「多层网关」、「熔断降级」、「性能优化」等关键词，就能展示出架构视野。

链式追问一：网关架构设计

Q1：生产环境通常如何设计多层网关？高频

典型的两层网关架构：

外网流量
    │
    ▼
┌──────────────────────────┐
│      Nginx（接入层）       │
│  ・SSL 证书终止           │
│  ・静态资源缓存            │
│  ・DDoS 防护              │
│  ・全局限流（IP 级别）     │
│  ・负载均衡（到 Gateway）  │
└──────────────────────────┘
    │
    ▼
┌──────────────────────────┐
│  Spring Cloud Gateway    │
│  （业务网关层）            │
│  ・JWT 认证鉴权            │
│  ・服务路由（到微服务）     │
│  ・业务限流（用户/接口级）  │
│  ・灰度发布                │
│  ・请求日志 & 链路追踪     │
│  ・熔断降级                │
└──────────────────────────┘
    │
    ├── 用户服务
    ├── 订单服务
    └── ...微服务

为什么需要两层：

Nginx 擅长高性能代理、SSL 处理
Gateway 擅长业务逻辑（与服务注册发现深度集成，动态路由）
两者各司其职，Nginx 做纯流量处理，Gateway 做业务路由

Q2：网关如何实现熔断降级？高频

Spring Cloud Gateway + Resilience4j：

spring:
  cloud:
    gateway:
      routes:
        - id: order-service
          uri: lb://order-service
          filters:
            - name: CircuitBreaker
              args:
                name: order-circuit-breaker
                fallbackUri: forward:/fallback/order  # 降级到 fallback 接口

// 熔断器配置
@Bean
public Customizer<ReactiveResilience4JCircuitBreakerFactory> circuitBreakerConfig() {
    return factory -> factory.configure(builder ->
        builder.circuitBreakerConfig(CircuitBreakerConfig.custom()
            .slidingWindowSize(10)          // 统计窗口：最近 10 次请求
            .failureRateThreshold(50)       // 失败率 > 50% 触发熔断
            .waitDurationInOpenState(Duration.ofSeconds(30))  // 熔断持续 30s
            .permittedNumberOfCallsInHalfOpenState(3)  // 半开状态放 3 个请求试探
            .build()
        ), "order-circuit-breaker"
    );
}

// Fallback 控制器
@RestController
public class FallbackController {
    @RequestMapping("/fallback/order")
    public Mono<ResponseEntity<Map<String, String>>> orderFallback() {
        return Mono.just(ResponseEntity.ok(Map.of(
            "code", "SERVICE_UNAVAILABLE",
            "message", "订单服务暂时不可用，请稍后重试"
        )));
    }
}

链式追问二：性能优化

Q3：Spring Cloud Gateway 性能优化有哪些手段？高频

1. 合理的过滤器顺序（Order 值）：

鉴权过滤器（Order = -100）排最前，尽早拒绝非法请求
避免不必要的过滤器消耗资源

2. 连接池优化：

spring:
  cloud:
    gateway:
      httpclient:
        pool:
          type: FIXED
          max-connections: 500      # 最大连接数
          max-idle-time: 60s        # 空闲连接保留时间
          acquire-timeout: 5000     # 获取连接超时时间（ms）
        response-timeout: 3s        # 响应超时
        connect-timeout: 1000       # 连接超时（ms）

3. 缓存路由（避免每次查询注册中心）：

使用 CachingRouteLocator（默认已启用）
路由变更时主动刷新缓存

4. 合理设置限流（防止网关自身成为瓶颈）：

# Redis 限流（滑动窗口算法）
- name: RequestRateLimiter
  args:
    redis-rate-limiter.replenishRate: 100  # 每秒补充令牌数
    redis-rate-limiter.burstCapacity: 200  # 令牌桶容量（允许突发）
    key-resolver: "#{@userKeyResolver}"    # 按用户限流

链式追问三：综合面试题

Q4：一个请求从客户端到后端服务经历了哪些步骤？（网关视角）必考

1. 客户端发送 HTTPS 请求
    └── Nginx 接收，SSL 解密，得到明文 HTTP 请求

2. Nginx 转发到 Gateway 集群
    └── 负载均衡（Round Robin / Least Connections）

3. Spring Cloud Gateway 处理
    ├── RoutePredicateHandlerMapping 匹配路由
    │     └── 遍历路由，第一个 Predicate 全部满足的路由生效
    │
    ├── Global Filter Pre 阶段（按 Order 顺序）
    │     ├── JwtAuthFilter：验证 JWT，提取用户信息写入 Header
    │     ├── RateLimitFilter：检查限流配额（Redis 令牌桶）
    │     └── TraceFilter：生成 TraceId，写入 Header 用于链路追踪
    │
    ├── 路由 Filter Pre 阶段
    │     ├── StripPrefix：去掉路径前缀
    │     └── AddRequestHeader：添加请求头
    │
    ├── 请求转发到后端服务（Netty HTTP Client，非阻塞）
    │     └── lb://order-service → Nacos 获取实例 IP:Port → 发送请求
    │
    ├── 后端处理，返回响应
    │
    ├── 路由 Filter Post 阶段（逆序）
    │
    └── Global Filter Post 阶段（逆序）
          └── LogFilter：记录请求日志（URL、耗时、状态码）

4. 响应返回给 Nginx → 返回给客户端

Q5：如何设计一个高可用的网关？

高可用设计要点：

1. 网关集群部署（≥ 2 节点）
   └── 前置 Nginx/LB，任一 Gateway 宕机不影响服务

2. 熔断降级（Circuit Breaker）
   └── 后端服务宕机 → 快速降级返回，防止雪崩

3. 限流保护（Rate Limiter）
   └── 防止流量洪峰压垮网关和后端

4. 超时控制（Timeout）
   └── 后端响应慢 → 快速超时，释放连接

5. 无状态设计
   └── Session 信息不存网关本地，JWT 或 Redis
         → 任何节点都能处理任何请求

6. 配置中心（Nacos/Apollo）
   └── 路由规则、限流规则动态生效，无需重启

7. 监控告警（Prometheus + Grafana）
   └── QPS、错误率、延迟超阈值立即告警