API Gateway 与 BFF

为什么需要 API Gateway

假设你有 10 个微服务,客户端(Web / App / 小程序)直接调每个服务:

没有 Gateway 时:
  Web App ──→ 用户服务 (auth + /users)
         ──→ 订单服务 (auth + /orders)
         ──→ 商品服务 (auth + /products)
         ──→ 搜索服务 (auth + /search)
         ──→ 支付服务 (auth + /payments)

问题:
  1. 客户端要知道所有服务地址
  2. 每个服务都要重复实现 auth / 限流 / CORS
  3. 服务拆分/合并时客户端要改
  4. 内部服务直接暴露在公网

引入 API Gateway 后:

[客户端
(Web/App)] → [API Gateway]

Gateway 解决的核心问题:

Gateway 核心能力

路由(Routing)

根据 URL 路径,HTTP 方法,Header 等条件将请求分发到对应的后端服务:

# 以 APISIX 配置为例
routes:
  - uri: /api/v1/users/*
    upstream:
      nodes:
        user-service:8080: 1
  - uri: /api/v1/orders/*
    upstream:
      nodes:
        order-service:8080: 1
  - uri: /api/v1/products/*
    methods: [GET]
    upstream:
      nodes:
        product-service:8080: 1

认证与鉴权

Gateway 统一验证外部请求的身份(Authentication)和权限(Authorization):

1. 客户端携带 JWT / OAuth2 token
2. Gateway 验证 token 有效性(签名,过期时间)
3. 将解析后的用户信息(user_id,roles)注入到 Header 中转发给后端
4. 后端服务直接信任 Gateway 转发的 Header,无需重复验证

// Gateway 伪代码:JWT 验证 + 注入用户信息
func authMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        token := r.Header.Get("Authorization")
        claims, err := verifyJWT(token)
        if err != nil {
            http.Error(w, "unauthorized", 401)
            return
        }
        // 注入已验证的用户信息到内部 header
        r.Header.Set("X-User-ID", claims.UserID)
        r.Header.Set("X-User-Roles", strings.Join(claims.Roles, ","))
        next.ServeHTTP(w, r)
    })
}

限流(Rate Limiting)

防止单个客户端或突发流量打垮后端:

限流维度:

• 按 IP(防爬虫)
• 按 User ID(按用户配额)
• 按 API Key(按租户/套餐计费)
• 按路由(热点接口单独限流)

协议转换

对外暴露 RESTful JSON,内部转发为 gRPC:

[客户端] → [API Gateway] → [订单服务]

实现方式:

• gRPC-Gateway:从 .proto 文件自动生成 REST 反向代理(上一篇讲过)
• Envoy gRPC-JSON transcoding:配置级转换,无需代码
• 手写 BFF 层:复杂聚合场景下的定制方案

请求聚合

移动端一个页面可能需要 5 个服务的数据.没有聚合时要发 5 个请求(高延迟,高流量消耗).Gateway 可以合并为一次请求:

// Gateway 聚合层:首页数据
func homepageHandler(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()
    userID := r.Header.Get("X-User-ID")

    // 并行请求多个服务
    var (
        user    *UserInfo
        orders  []*Order
        recomms []*Product
    )
    g, ctx := errgroup.WithContext(ctx)

    g.Go(func() error {
        var err error
        user, err = userClient.GetProfile(ctx, userID)
        return err
    })
    g.Go(func() error {
        var err error
        orders, err = orderClient.ListRecent(ctx, userID, 5)
        return err
    })
    g.Go(func() error {
        var err error
        recomms, err = recommendClient.GetForUser(ctx, userID, 10)
        return err
    })

    if err := g.Wait(); err != nil {
        // 部分失败时降级返回(不影响整体)
        log.Warn("partial failure in aggregation", "err", err)
    }

    json.NewEncoder(w).Encode(HomepageResponse{
        User:     user,
        Orders:   orders,
        Recommends: recomms,
    })
}

BFF 模式(Backend for Frontend)

不同客户端的需求差异很大:

• Web:大屏幕,可以展示详细信息,带宽不敏感
• iOS/Android:小屏幕,需要精简数据,带宽敏感
• 小程序:功能子集,API 更简单
• 第三方开放 API:标准 REST,版本稳定

用一个 Gateway 服务所有客户端会导致:接口越来越臃肿(为了兼容所有端),改动互相影响,无法按端独立发布.

BFF 架构

┌──────────┐
│  Web 前端  │
└──────────┘
      │
      ▼
┌─────────────┐
│ iOS/Android │
└─────────────┘
       │
       ▼
┌──────────┐
│   小程序    │
└──────────┘
      │
      ▼
┌──────────┐
│ Web BFF  │
└──────────┘
      │
      ▼
┌────────────┐
│ Mobile BFF │
└────────────┘
       │
       ▼
┌──────────┐
│ Mini BFF │
└──────────┘
      │
      ▼
┌──────────┐
│   用户服务   │
└──────────┘
┌──────────┐
│   订单服务   │
└──────────┘

每个 BFF 的职责:

• 为特定客户端裁剪和聚合 后端数据
• 做协议转换(REST → gRPC)
• 由对应的前端团队拥有和维护
• 可以独立部署和演进

BFF vs 通用 Gateway

实践中两者常共存:Gateway(横切)→ BFF(聚合)→ 后端微服务.

主流 Gateway 方案对比

Gateway 反模式

反模式一:胖 Gateway

把业务逻辑塞进 Gateway:数据校验,业务规则,数据库查询...Gateway 变成了新的单体.

正确做法:Gateway 只做横切关注点(路由/认证/限流/监控).需要业务逻辑的聚合放 BFF 层.

反模式二:单点 Gateway

Gateway 是所有流量的入口--它挂了整个系统都不可用.

正确做法:

• 多实例部署 + 负载均衡(至少 2 个副本)
• 无状态设计(状态放 Redis / 外部存储)
• 健康检查 + 自动故障转移
• 限流保护 Gateway 自身不被打垮

反模式三:Gateway 感知服务内部

Gateway 路由配置与后端服务的内部路径强绑定.服务重构就要改 Gateway 配置.

正确做法:Gateway 按域路由到服务根路径,服务内部路由由服务自己管理.

Gateway 安全实践

• TLS 终止:Gateway 处理 HTTPS,内部通信可以用 mTLS 或明文(配合网络策略隔离)
• CORS 处理:在 Gateway 统一配置跨域策略,后端服务不需要关心
• 请求大小限制:防止大 payload 攻击(body size limit)
• 请求头清洗:删除客户端注入的内部 Header(如 X-User-ID),防止伪造
• API 版本管理:通过路径前缀(/v1/,/v2/)或 Header 实现版本路由

Gateway 可观测性

Gateway 是流量入口,天然是最佳的观测点:

与 K8s Ingress 的关系

在 Kubernetes 04-05 篇中讲过 Ingress 和 Gateway API.它们和 API Gateway 的关系:

常见组合:

• 简单场景:Nginx Ingress Controller 直接当 Gateway 用(路由 + TLS + 基础限流)
• 中等场景:Traefik / APISIX 作为 Ingress Controller + API Gateway 一体化
• 复杂场景:外层 LB → API Gateway(认证/限流/监控)→ 内部 Service Mesh(Istio)