API网关：所有请求的"第一道门"

你的游戏平台每天处理几千万级请求，它们是怎么找到目的地的？

想象一下：你住在一个超大型小区，每天有成千上万的快递、外卖、访客要进来。

如果没有大门保安，每个人都要自己找楼栋、敲门、确认身份...

API网关，就是你系统的"小区大门保安"——所有请求必须先经过它，才能进入内部服务。

一、为什么需要网关？

没有"保安"的日子

假设你的游戏平台有这些服务：

• 玩家服务（登录、注册、资料）
• 充值服务（支付、订单）
• 游戏服务（匹配、战斗）
• 社交服务（好友、聊天）

听起来还好？但当服务数量从10个变成100个，问题就来了：

🚨 客户端崩溃：要维护100个服务地址，配置管理地狱

🚨 认证重复：每个服务都要实现登录校验，代码重复且难以统一

🚨 安全风险：所有服务都暴露在公网，攻击面巨大

🚨 跨域问题：不同域名、不同协议，前端疯狂报错

🚨 协议不一致：有些服务用 REST，有些用 gRPC，有些用 WebSocket，客户端要适配多种协议

🚨 版本管理混乱：服务升级后，客户端不知道该调哪个版本

有"保安"之后

客户端只需要知道网关地址，剩下的交给网关去路由。

客户端 → 网关 → 内部服务

就像快递员只需要把包裹交给小区保安，保安负责送到具体的楼栋。

✅ 统一入口 - 一个地址，路由到所有服务

✅ 统一认证 - 登录校验只做一次

✅ 安全隔离 - 内部服务不暴露

✅ 跨域处理 - 网关统一处理 CORS

✅ 协议转换 - 屏蔽后端技术差异

✅ 流量管控 - 限流、熔断、降级一站式搞定

真实案例：某游戏平台的网关演进

客户端直连各服务 IP
问题：配置混乱，每次服务迁移都要改客户端

Nginx 配置 location 规则
问题：鉴权逻辑散落各服务，限流能力弱

自研 gateway 服务
效果：统一认证、灵活限流、灰度发布

这个演进过程，是大多数公司的真实写照。

[配图建议：有网关 vs 无网关的架构对比图，左边是混乱的客户端直连多服务，右边是整洁的客户端→网关→服务]

二、网关的六大核心职责

保安的工作可不只是开门关门，网关也一样。

🎯 1. 路由（Routing）

根据 URL 路径、HTTP 方法、请求头等信息，决定请求去哪。

/api/player/*  → 玩家服务
/api/pay/*     → 充值服务
/api/game/*    → 游戏服务

路由的实现原理

routes:
  - id: player-service
    uri: lb://player-service
    predicates:
      - Path=/api/player/**
      - Method=GET,POST
    filters:
      - StripPrefix=1
      
  - id: pay-service
    uri: lb://pay-service
    predicates:
      - Path=/api/pay/**
      - Header=X-Request-Id, \d+

1. 路径匹配：前缀匹配、精确匹配、正则匹配
2. 方法匹配：GET、POST、PUT、DELETE 等
3. Header 匹配：根据请求头判断
4. 参数匹配：Query 参数条件

智能路由策略

routes:
  - id: player-v1
    uri: lb://player-service-v1
    predicates:
      - Path=/v1/api/player/**
      
  - id: player-v2
    uri: lb://player-service-v2
    predicates:
      - Path=/v2/api/player/**

routes:
  - id: player-canary
    uri: lb://player-service-v2
    predicates:
      - Path=/api/player/**
      - Header=X-User-Group, canary

routes:
  - id: player-stable
    uri: lb://player-service-v1
    predicates:
      - Path=/api/player/**
      - Weight=group1, 90
      
  - id: player-canary
    uri: lb://player-service-v2
    predicates:
      - Path=/api/player/**
      - Weight=group1, 10

路由性能优化

• 线性扫描：O(n)，每次请求遍历所有规则
• 前缀树（Trie）：O(m)，m 是路径长度
• 哈希索引：O(1)，但只支持精确匹配

• 路由规则数量 < 1000：线性扫描够用
• 路由规则数量 > 1000：使用前缀树优化
• 高频接口：单独提取，优先匹配

🔐 2. 鉴权（Authentication）

鉴权的层次

第一层：你是谁？（身份认证）
第二层：你能做什么？（权限校验）
第三层：你能访问多久？（会话管理）

JWT 鉴权完整流程

1. 客户端登录 → 认证服务
2. 认证服务验证账号密码
3. 认证服务生成 JWT Token
4. 客户端保存 Token（LocalStorage / Cookie）
5. 后续请求携带 Token（Authorization: Bearer xxx）
6. 网关验证 Token 有效性
7. 网关提取用户信息注入请求头
8. 请求转发到下游服务

网关鉴权过滤器实现

@Component
public class AuthFilter implements GlobalFilter, Ordered {
    
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        String token = exchange.getRequest().getHeaders().getFirst("Authorization");
        
        // 1. 检查 Token 是否存在
        if (StringUtils.isEmpty(token)) {
            return onError(exchange, "未登录", 401);
        }
        
        // 2. 验证 Token 有效性
        try {
            Claims claims = JwtUtil.parseToken(token.replace("Bearer ", ""));
            
            // 3. 检查是否过期
            if (claims.getExpiration().before(new Date())) {
                return onError(exchange, "Token 已过期", 401);
            }
            
            // 4. 提取用户信息注入请求头
            ServerHttpRequest request = exchange.getRequest().mutate()
                .header("X-User-Id", claims.get("userId", String.class))
                .header("X-User-Name", claims.get("userName", String.class))
                .build();
            
            return chain.filter(exchange.mutate().request(request).build());
            
        } catch (Exception e) {
            return onError(exchange, "Token 无效", 401);
        }
    }
    
    @Override
    public int getOrder() {
        return -100; // 优先级最高
    }
}

权限校验（RBAC 模型）

@Component
public class PermissionFilter implements GlobalFilter, Ordered {
    
    @Autowired
    private PermissionService permissionService;
    
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        String userId = exchange.getRequest().getHeaders().getFirst("X-User-Id");
        String path = exchange.getRequest().getPath().value();
        String method = exchange.getRequest().getMethod().name();
        
        // 查询用户是否有该接口的访问权限
        if (!permissionService.hasPermission(userId, path, method)) {
            return onError(exchange, "无访问权限", 403);
        }
        
        return chain.filter(exchange);
    }
    
    @Override
    public int getOrder() {
        return -90; // 鉴权之后执行
    }
}

白名单机制

某些接口不需要鉴权（如登录、注册、健康检查）：

public class WhiteListConfig {
    
    private static final Set<String> WHITE_LIST = Set.of(
        "/api/auth/login",
        "/api/auth/register",
        "/api/health",
        "/api/public/**"
    );
    
    public static boolean isWhiteList(String path) {
        return WHITE_LIST.stream().anyMatch(path::startsWith);
    }
}

🚦 3. 限流（Rate Limiting）

高并发场景下，如果不限流，一个恶意用户就能打爆你的服务。

为什么需要限流？

场景1：黑五促销，正常用户涌入 → 系统过载崩溃
场景2：恶意用户刷接口 → 消耗服务器资源
场景3：爬虫大量抓取数据 → 影响正常用户
场景4：某个服务响应慢 → 请求堆积，雪崩

四种经典限流算法

public class FixedWindowRateLimiter {
    private int limit = 100;           // 限制次数
    private long windowSize = 60000;   // 窗口大小（毫秒）
    private AtomicInteger count = new AtomicInteger(0);
    private long windowStart = System.currentTimeMillis();
    
    public synchronized boolean tryAcquire() {
        long now = System.currentTimeMillis();
        
        // 窗口过期，重置计数
        if (now - windowStart >= windowSize) {
            windowStart = now;
            count.set(0);
        }
        
        // 判断是否超过限制
        if (count.get() >= limit) {
            return false;
        }
        
        count.incrementAndGet();
        return true;
    }
}

窗口1（0-1分钟）：第59秒来了100个请求 ✅
窗口2（1-2分钟）：第1秒又来了100个请求 ✅
实际上在2秒内处理了200个请求，超出限制！

public class SlidingWindowRateLimiter {
    private int limit = 100;
    private long windowSize = 60000;
    private LinkedList<Long> timestamps = new LinkedList<>();
    
    public synchronized boolean tryAcquire() {
        long now = System.currentTimeMillis();
        
        // 移除窗口外的时间戳
        while (!timestamps.isEmpty() && timestamps.getFirst() < now - windowSize) {
            timestamps.removeFirst();
        }
        
        // 判断当前窗口内的请求数
        if (timestamps.size() >= limit) {
            return false;
        }
        
        timestamps.addLast(now);
        return true;
    }
}

public class TokenBucketRateLimiter {
    private int capacity = 100;        // 桶容量
    private int rate = 10;             // 令牌生成速率（个/秒）
    private AtomicInteger tokens = new AtomicInteger(capacity);
    private long lastRefillTime = System.currentTimeMillis();
    
    public synchronized boolean tryAcquire() {
        // 补充令牌
        refillTokens();
        
        // 尝试获取令牌
        if (tokens.get() > 0) {
            tokens.decrementAndGet();
            return true;
        }
        return false;
    }
    
    private void refillTokens() {
        long now = System.currentTimeMillis();
        long elapsed = now - lastRefillTime;
        int tokensToAdd = (int) (elapsed * rate / 1000);
        
        if (tokensToAdd > 0) {
            tokens.set(Math.min(capacity, tokens.get() + tokensToAdd));
            lastRefillTime = now;
        }
    }
}

public class LeakyBucketRateLimiter {
    private int capacity = 100;        // 桶容量
    private int rate = 10;             // 漏水速率（个/秒）
    private AtomicInteger water = new AtomicInteger(0);
    private long lastLeakTime = System.currentTimeMillis();
    
    public synchronized boolean tryAcquire() {
        // 漏水
        leak();
        
        // 判断桶是否已满
        if (water.get() >= capacity) {
            return false;
        }
        
        water.incrementAndGet();
        return true;
    }
    
    private void leak() {
        long now = System.currentTimeMillis();
        long elapsed = now - lastLeakTime;
        int waterToLeak = (int) (elapsed * rate / 1000);
        
        if (waterToLeak > 0) {
            water.set(Math.max(0, water.get() - waterToLeak));
            lastLeakTime = now;
        }
    }
}

限流维度

# 按用户限流
rate-limit:
  type: USER
  limit: 1000/minute
  
# 按 IP 限流
rate-limit:
  type: IP
  limit: 100/minute
  
# 按接口限流
rate-limit:
  type: API
  path: /api/pay/**
  limit: 500/minute
  
# 组合限流
rate-limit:
  type: COMPOSITE
  rules:
    - type: USER
      limit: 1000/minute
    - type: IP
      limit: 100/minute

分布式限流

单机限流只能保护本机，分布式环境需要集中式限流：

-- rate_limit.lua
local key = KEYS[1]
local limit = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local now = tonumber(ARGV[3])

-- 移除窗口外的记录
redis.call('ZREMRANGEBYSCORE', key, 0, now - window)

-- 获取当前窗口内的请求数
local count = redis.call('ZCARD', key)

if count < limit then
    redis.call('ZADD', key, now, now .. '-' .. math.random())
    redis.call('EXPIRE', key, window / 1000)
    return 1
else
    return 0
end

🔥 4. 熔断（Circuit Breaker）

熔断器的三种状态

        [请求失败率 < 阈值]
              ↑
              │
    ┌─────────┴─────────┐
    │                   │
    ↓                   │
┌────────┐  [失败率>阈值]  ┌────────┐
│  关闭  │ ─────────────→ │  打开  │
└────────┘               └────────┘
    ↑                        │
    │                        │ [超时后]
    │                        ↓
    │                   ┌────────┐
    └────────────────── │  半开  │
       [请求成功]       └────────┘

• 关闭（Closed）：正常转发请求，统计失败率
• 打开（Open）：直接返回错误，不再转发，启动超时计时器
• 半开（Half-Open）：试探性放行部分请求，检测是否恢复

Resilience4j 熔断器配置

resilience4j:
  circuitbreaker:
    instances:
      playerService:
        slidingWindowSize: 100           # 滑动窗口大小
        failureRateThreshold: 50         # 失败率阈值（%）
        waitDurationInOpenState: 30s     # 打开状态等待时间
        permittedNumberOfCallsInHalfOpenState: 10  # 半开状态允许的请求数
        slowCallDurationThreshold: 2s    # 慢调用阈值
        slowCallRateThreshold: 60        # 慢调用率阈值（%）

熔断器代码示例

@RestController
public class GameController {
    
    @CircuitBreaker(name = "playerService", fallbackMethod = "getPlayerFallback")
    @GetMapping("/api/player/{id}")
    public Player getPlayer(@PathVariable String id) {
        return playerService.getPlayer(id);
    }
    
    // 熔断降级方法
    public Player getPlayerFallback(String id, Exception e) {
        // 返回缓存数据或默认值
        return Player.builder()
            .id(id)
            .name("未知玩家")
            .level(1)
            .build();
    }
}

📝 5. 日志与监控（Logging & Monitoring）

请求日志结构

{
  "traceId": "abc123",
  "timestamp": "2026-03-01T10:30:00Z",
  "method": "POST",
  "path": "/api/pay/order",
  "userId": "user_001",
  "ip": "192.168.1.100",
  "userAgent": "GameClient/1.0",
  "requestSize": 256,
  "responseSize": 128,
  "statusCode": 200,
  "latency": 45,
  "upstreamService": "pay-service",
  "upstreamLatency": 38
}

全链路追踪

客户端请求 → 网关（生成 TraceId）→ 服务A → 服务B → 数据库
                │
                └── 所有节点共享同一个 TraceId

@Component
public class TraceFilter implements GlobalFilter, Ordered {
    
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        String traceId = exchange.getRequest().getHeaders().getFirst("X-Trace-Id");
        
        // 如果没有 TraceId，生成一个
        if (StringUtils.isEmpty(traceId)) {
            traceId = UUID.randomUUID().toString().replace("-", "");
        }
        
        // 注入到请求头
        ServerHttpRequest request = exchange.getRequest().mutate()
            .header("X-Trace-Id", traceId)
            .build();
        
        // 记录日志
        exchange.getAttributes().put("startTime", System.currentTimeMillis());
        
        return chain.filter(exchange.mutate().request(request).build())
            .doFinally(signalType -> {
                long latency = System.currentTimeMillis() 
                    - exchange.getAttribute("startTime");
                log.info("traceId={}, path={}, latency={}ms", 
                    traceId, request.getPath(), latency);
            });
    }
}

监控指标

# Prometheus 指标示例
http_requests_total{method="GET", path="/api/player", status="200"} 12345
http_request_duration_seconds{method="GET", path="/api/player", quantile="0.99"} 0.045
gateway_active_connections 1024
gateway_circuit_breaker_state{service="player"} "closed"

🔄 6. 协议转换（Protocol Translation）

HTTP → gRPC 转换

spring:
  cloud:
    gateway:
      routes:
        - id: grpc-service
          uri: grpc://localhost:9090
          predicates:
            - Path=/api/grpc/**
          filters:
            - name: GrpcToHttp

WebSocket 代理

spring:
  cloud:
    gateway:
      routes:
        - id: websocket-service
          uri: ws://localhost:8081
          predicates:
            - Path=/ws/**

请求/响应转换

@Component
public class RequestTransformFilter implements GlobalFilter {
    
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // 转换请求体
        return exchange.getRequest().getBody()
            .map(dataBuffer -> {
                // JSON 字段映射、格式转换等
                return transformBody(dataBuffer);
            })
            .then(chain.filter(exchange));
    }
}

[配图建议：网关核心职责的六个图标组成的图示，每个图标代表一个功能]

三、高可用设计：网关不能挂

网关是所有请求的必经之路，一旦挂掉，整个系统就瘫痪了。

1. 无状态设计

❌ 错误做法：
网关A 处理用户1的会话
网关B 处理用户2的会话
→ 网关A 挂了，用户1 的会话丢失

✅ 正确做法：
会话状态存储在 Redis
任何网关实例都能处理任何用户的请求
→ 网关A 挂了，网关B 接管，无感知

2. 多实例部署 + 负载均衡

                    ┌─────────────┐
                    │  负载均衡器  │
                    │  (Nginx/LB) │
                    └──────┬──────┘
                           │
           ┌───────────────┼───────────────┐
           │               │               │
           ↓               ↓               ↓
      ┌────────┐      ┌────────┐      ┌────────┐
      │ 网关-1 │      │ 网关-2 │      │ 网关-3 │
      └────────┘      └────────┘      └────────┘

# Nginx 健康检查
upstream gateway {
    server 10.0.0.1:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.2:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.3:8080 max_fails=3 fail_timeout=30s;
}

3. 熔断降级

@GetMapping("/api/player/{id}")
@CircuitBreaker(name = "playerService", fallbackMethod = "getPlayerFromCache")
public Player getPlayer(@PathVariable String id) {
    return playerService.getPlayer(id);
}

// 降级方案1：从缓存读取
public Player getPlayerFromCache(String id, Exception e) {
    return cacheService.getPlayer(id);
}

// 降级方案2：返回默认值
public Player getPlayerDefault(String id, Exception e) {
    return Player.defaultPlayer();
}

4. 限流保护

# 全局限流
rate-limit:
  global: 100000/second
  
# 单 IP 限流
rate-limit:
  ip: 100/second
  
# 热点接口限流
rate-limit:
  api:
    /api/login: 1000/second
    /api/pay: 500/second

5. 多机房部署

┌─────────────────────────────────────────────────────┐
│                    DNS 智能解析                      │
└───────────────────────┬─────────────────────────────┘
                        │
         ┌──────────────┼──────────────┐
         │              │              │
         ↓              ↓              ↓
   ┌──────────┐   ┌──────────┐   ┌──────────┐
   │ 北京机房 │   │ 上海机房 │   │ 广州机房 │
   │  网关集群 │   │  网关集群 │   │  网关集群 │
   └──────────┘   └──────────┘   └──────────┘

6. 灰度发布

# 灰度发布配置
routes:
  - id: gateway-v1
    uri: lb://gateway-v1
    predicates:
      - Weight=gateway, 90
      
  - id: gateway-v2
    uri: lb://gateway-v2
    predicates:
      - Weight=gateway, 10

四、网关架构设计：同步 vs 异步

同步网关（传统模式）

请求 → 线程阻塞等待 → 响应返回 → 线程释放

请求1 → Thread-1 → 等待 → 响应
请求2 → Thread-2 → 等待 → 响应
请求3 → Thread-3 → 等待 → 响应
...
请求1000 → Thread-1000 → 等待 → 响应

• 实现简单，易于理解
• 调试方便，堆栈清晰

• 高并发时线程数爆炸
• 内存消耗大（每个线程约 1MB 栈空间）
• 线程切换开销大
• 不适合长连接场景

• 请求量 < 5000 QPS
• 内部服务网关
• 快速原型开发

异步网关（现代模式）

请求 → 注册回调 → 线程释放 → 响应到达时回调处理

┌─────────────────────────────────────┐
│           Event Loop Thread         │
│  ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐  │
│  │请求1│ │请求2│ │请求3│ │请求4│  │
│  └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘  │
│     │       │       │       │      │
│     ↓       ↓       ↓       ↓      │
│  ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐  │
│  │回调1│ │回调2│ │回调3│ │回调4│  │
│  └─────┘ └─────┘ └─────┘ └─────┘  │
└─────────────────────────────────────┘

@Component
public class AsyncHandler {
    
    public Mono<String> handleRequest(ServerRequest request) {
        return Mono.fromCallable(() -> {
            // 异步处理
            return doSomething();
        }).subscribeOn(Schedulers.boundedElastic());
    }
}

• 高并发友好，少量线程处理大量请求
• 资源消耗低
• 适合 IO 密集型场景
• 响应式编程模型

• 代码复杂度增加
• 调试困难（异步堆栈）
• 学习曲线陡峭

• 请求量 > 10000 QPS
• 公网 API 网关
• 高并发、低延迟要求

性能对比

游戏行业怎么选？

[配图建议：同步 vs 异步网关的对比图，左侧是阻塞等待的线程，右侧是事件循环的非阻塞模型]

五、游戏行业的网关挑战

游戏行业对网关有独特的要求，远超普通的 Web 应用。

🎮 挑战1：超高并发

开服前 5 分钟：1000 QPS
开服瞬间：100000 QPS（100倍）
开服后 10 分钟：50000 QPS
开服后 1 小时：20000 QPS

# 弹性扩容配置
autoscaling:
  minReplicas: 5
  maxReplicas: 100
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: 10000

@Scheduled(cron = "0 55 9 * * ?")  // 每天 9:55 执行
public void preheatBeforeServerOpen() {
    // 开服前 5 分钟预扩容
    kubernetesClient.scaleDeployment("gateway", 50);
    
    // 预热连接池
    connectionPool.warmUp();
    
    // 预加载热点数据
    cacheService.preloadHotData();
}

# 开服专用限流策略
rate-limit:
  login:
    type: QUEUE           # 排队模式
    limit: 10000/second
    queueSize: 100000
    queueTimeout: 30s     # 排队超时
    
  fallback:
    message: "服务器火爆，请稍后重试"
    retryAfter: 10

⚡ 挑战2：超低延迟

总延迟 = 客户端网络 + 网关处理 + 服务处理 + 数据库 + 返回
   100ms =    30ms    +    5ms   +    30ms   +   20ms  + 15ms

1. 边缘计算：网关下沉到离玩家最近的节点

传统架构：
玩家（北京）→ 中心机房（上海）→ 服务
延迟：30ms

边缘架构：
玩家（北京）→ 边缘节点（北京）→ 服务
延迟：5ms

1. 协议优化：UDP 代替 TCP

TCP：三次握手 + 拥塞控制 + 重传
延迟：50-100ms

UDP：无连接 + 无拥塞控制
延迟：10-20ms

1. 连接复用：长连接减少握手开销

// 连接池配置
HttpClient client = HttpClient.create()
    .keepAlive(true)
    .maxConnections(10000)
    .responseTimeout(Duration.ofSeconds(5));

1. 零拷贝技术

// Netty 零拷贝
ByteBuf buf = Unpooled.wrappedBuffer(data);
// 直接操作内存，避免数据拷贝

🔌 挑战3：长连接管理

┌─────────────────────────────────────────────┐
│                 游戏网关                      │
├─────────────────────────────────────────────┤
│  ┌─────────┐  ┌─────────┐  ┌─────────┐     │
│  │ 连接管理 │  │ 会话管理 │  │ 消息路由 │     │
│  └─────────┘  └─────────┘  └─────────┘     │
├─────────────────────────────────────────────┤
│  ┌─────────┐  ┌─────────┐  ┌─────────┐     │
│  │ 协议解析 │  │ 消息队列 │  │ 负载均衡 │     │
│  └─────────┘  └─────────┘  └─────────┘     │
└─────────────────────────────────────────────┘

public class ReconnectHandler {
    
    public void onReconnect(String playerId, String oldSessionId, String newSessionId) {
        // 1. 验证玩家身份
        if (!authService.validatePlayer(playerId)) {
            return;
        }
        
        // 2. 恢复会话状态
        Session session = sessionService.getSession(oldSessionId);
        if (session != null && !session.isExpired()) {
            // 3. 迁移到新连接
            sessionService.migrateSession(oldSessionId, newSessionId);
            
            // 4. 推送断线期间的消息
            List<Message> missedMessages = messageQueue.getUnsentMessages(playerId);
            pushService.pushMessages(newSessionId, missedMessages);
        }
    }
}

💥 挑战4：DDoS 防护

1. SYN Flood：耗尽连接池
2. UDP Flood：带宽攻击
3. HTTP Flood：应用层攻击
4. CC 攻击：模拟正常用户

┌──────────────────────────────────────────────┐
│                 DDoS 防护架构                  │
├──────────────────────────────────────────────┤
│                                              │
│  攻击流量                                    │
│     │                                        │
│     ↓                                        │
│  ┌──────────┐    ┌──────────┐               │
│  │ 高防 IP  │ → │ 流量清洗  │               │
│  └──────────┘    └──────────┘               │
│                       │                      │
│                       ↓                      │
│                  ┌──────────┐               │
│                  │  网关层   │               │
│                  │ (限流/黑名单)│            │
│                  └──────────┘               │
│                       │                      │
│                       ↓                      │
│                   正常流量                    │
└──────────────────────────────────────────────┘

@Component
public class DDoSFilter implements GlobalFilter {
    
    private LoadingCache<String, AtomicInteger> requestCounts = CacheBuilder.newBuilder()
        .expireAfterWrite(1, TimeUnit.SECONDS)
        .build(new CacheLoader<String, AtomicInteger>() {
            @Override
            public AtomicInteger load(String key) {
                return new AtomicInteger(0);
            }
        });
    
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        String ip = getClientIp(exchange);
        
        try {
            AtomicInteger count = requestCounts.get(ip);
            if (count.incrementAndGet() > 100) {  // 每秒超过 100 次请求
                // 加入黑名单
                blacklistService.add(ip, 3600);  // 封禁 1 小时
                return onError(exchange, "请求过于频繁", 429);
            }
        } catch (Exception e) {
            log.error("限流异常", e);
        }
        
        return chain.filter(exchange);
    }
}

[配图建议：游戏行业网关挑战的四象限图，每个象限代表一个挑战]

六、网关与服务网格的关系

答案是：需要，它们解决不同层面的问题。

API 网关 vs Service Mesh

• API 网关 = 小区大门保安（管进出）
• Service Mesh = 楼栋内部管家（管内部流转）

它们如何配合？

外部请求 → API网关（认证、限流）→ Service Mesh（服务发现、负载均衡）→ 目标服务

                    ┌─────────────────────────────────────┐
                    │            API 网关                  │
                    │   (认证、限流、路由、协议转换)         │
                    └─────────────────┬───────────────────┘
                                      │
                    ┌─────────────────┴───────────────────┐
                    │                                     │
            ┌───────┴───────┐                   ┌────────┴────────┐
            │   服务 A       │                   │    服务 B        │
            │ ┌───────────┐ │                   │ ┌─────────────┐ │
            │ │ 业务逻辑   │ │                   │ │  业务逻辑    │ │
            │ └───────────┘ │                   │ └─────────────┘ │
            │ ┌───────────┐ │   Service Mesh    │ ┌─────────────┐ │
            │ │  Sidecar  │ │◄─────────────────►│ │   Sidecar   │ │
            │ └───────────┘ │   (东西向流量)      │ └─────────────┘ │
            └───────────────┘                   └─────────────────┘

1. API 网关 处理所有外部流量，做认证、限流、路由
2. Service Mesh 管理内部服务间调用，做熔断、重试、追踪
3. 两者配合，形成完整的流量治理体系

游戏行业的实践

• HTTP API 网关：处理登录、充值、配置等 HTTP 请求
• 游戏网关：处理游戏内的实时通信（TCP/UDP）
• Service Mesh：管理后端微服务间的调用

[配图建议：API网关 + Service Mesh 的分层架构图，展示南北向和东西向流量的分工]

七、主流网关技术选型

开源网关对比

选型建议

推荐: 根据业务需求选择
理由:
  - 自研网关：业务深度定制，灵活扩展
  - Kong：插件丰富、企业级管理
  - APISIX：云原生、动态配置
  - Envoy：高性能、Service Mesh 数据面

推荐: APISIX 或 Traefik
理由:
  - 原生支持 Kubernetes Ingress
  - 动态配置，无需重启
  - 与云原生生态集成良好

推荐: Nginx + Lua 或 Envoy
理由:
  - C/C++ 实现，性能极致
  - 支持千万级并发
  - 内存占用低

推荐: Kong
理由:
  - 完善的管理界面
  - 丰富的插件市场
  - 企业版支持更好

八、总结：网关设计的关键要点

设计一个好的 API 网关，记住这些原则：

✅ 要点1：职责单一

网关只做"门卫"该做的事，不要把业务逻辑塞进网关。

❌ 错误：在网关里做订单计算、库存扣减
✅ 正确：网关只做认证、限流、路由，业务逻辑交给下游服务

✅ 要点2：高可用优先

网关是单点，必须做到：无状态、可水平扩展、有降级方案。

✅ 无状态设计：会话存储在 Redis
✅ 多实例部署：至少 3 个实例
✅ 健康检查：自动剔除故障节点
✅ 熔断降级：下游故障时快速返回

✅ 要点3：性能敏感

网关是所有请求的必经之路，任何延迟都会被放大。

✅ 异步非阻塞：使用 Reactor 模型
✅ 连接复用：减少握手开销
✅ 缓存热点：减少下游压力
✅ 协议优化：HTTP/2、压缩传输

✅ 要点4：安全第一

网关是安全的第一道防线，认证、限流、防护一个都不能少。

✅ 统一认证：JWT、OAuth2、API Key
✅ 限流保护：防止恶意请求
✅ DDoS 防护：流量清洗、黑名单
✅ 敏感信息脱敏：日志中隐藏密码、Token

✅ 要点5：可观测性

日志、监控、追踪，三者缺一不可，否则出问题就是瞎子摸象。

✅ 结构化日志：JSON 格式，便于检索
✅ 指标监控：QPS、延迟、错误率
✅ 链路追踪：全链路 TraceId
✅ 告警机制：异常自动通知

写在最后

API 网关看似简单，实则是系统架构中最关键的组件之一。

门开得太大，什么人都能进来，不安全。

门开得太小，业主进出都堵，体验差。

回顾本文，我们覆盖了：

1. 网关的价值：统一入口、简化架构、提升安全
2. 六大核心职责：路由、鉴权、限流、熔断、日志、协议转换
3. 高可用设计：无状态、多实例、熔断降级、多机房
4. 同步 vs 异步：选型依据和性能对比
5. 游戏行业挑战：超高并发、超低延迟、长连接、DDoS 防护
6. 与服务网格配合：南北向 + 东西向流量治理
7. 技术选型：根据场景选择合适的网关

下一篇，我们来聊聊微服务架构中的"身份证系统"——服务注册与发现。

• 第1篇：从单体到微服务：游戏平台的架构演进之路
• 第2篇：微服务拆分：怎么切才不会切到手？