API 网关与 BFF 架构

API 网关与 BFF 架构

网关是微服务架构的流量入口，BFF 是适配多端体验的专用层。两者结合实现灵活的前后端协作。

1. API 网关核心职责

                    Client
                      ↓
              ┌───────────────┐
              │   API Gateway  │ ← 流量入口
              └───────────────┘
                      │
      ┌───────────────┼───────────────┐
      ↓               ↓               ↓
┌──────────┐    ┌──────────┐    ┌──────────┐
│ Order    │    │ Payment  │    │ User     │
│ Service  │    │ Service  │    │ Service  │
└──────────┘    └──────────┘    └──────────┘

功能矩阵

2. 网关选型

3. BFF 模式

Backend for Frontend：为不同客户端提供定制化的 API。

    ┌─────────┐
    │  Web    │────────────────→ Web BFF ──→ 聚合后端
    ├─────────┤
    │ Mobile  │────────────────→ Mobile BFF ──→ 聚合后端
    ├─────────┤
    │ Admin   │────────────────→ Admin BFF ──→ 聚合后端
    └─────────┘

BFF vs 网关

BFF 实践要点

// Web BFF：聚合多服务，返回完整数据
async function getOrderDetail(orderId) {
    const [order, payment, logis] = await Promise.all([
        orderService.get(orderId),
        paymentService.get(orderId),
        logisticsService.get(orderId)
    ]);
    return { order, payment, logistics: logis };
}

// Mobile BFF：精简响应，减少数据量
async function getOrderSummary(orderId) {
    const order = await orderService.get(orderId);
    return { id: order.id, status: order.status, total: order.total };
}

4. GraphQL 网关

为何选择 GraphQL

# 客户端决定要什么数据
query {
    order(id: "123") {
        id
        status
        items { name price }
        user { name avatar }
    }
}

优势：

• 精确获取，避免 Over-fetching
• 一次请求聚合多资源
• 强类型 Schema 作为 API 契约

Schema Stitching / Federation

// Apollo Federation：多个服务各自维护子 Schema
const gateway = new ApolloGateway({
    serviceList: [
        { name: 'orders', url: '...' },
        { name: 'users', url: '...' }
    ]
});
// Gateway 自动合并为统一查询入口

GraphQL 网关的权衡

5. 认证与授权策略

典型认证流

Client → Auth Server → Token
  │
  │ (携带 Token)
  ↓
Gateway → 验签/鉴权 → 透传 UserID → Backend

网关层实现

# Kong 插件示例
plugins:
  - name: jwt
    config:
      uri_param_names: [jwt]
      claims_to_verify: [exp]
  - name: rate-limiting
    config:
      minute: 60

微服务间调用

方案 A：网关统一鉴权，Service 间信任传递
  └─ 简单但不适合内部安全要求高场景

方案 B：Service Mesh mTLS + 服务鉴权
  └─ 端到端安全，但复杂度较高

6. 性能优化

总结

7. 网关生产部署模式

部署拓扑

模式 A：集中式网关

Internet ──→ CDN/WAF ──→ API Gateway ──→ Backend Services
                  │
                  └── 所有流量统一经过网关
                  └── 适合：中小型系统，统一治理

模式 B：分层网关

Internet ──→ CDN/WAF ──→ Edge Gateway（认证、限流）
                              │
                    ┌─────────┼─────────┐
                    ▼         ▼         ▼
              Web BFF    Mobile BFF    Admin BFF
                    │         │         │
                    └─────────┼─────────┘
                              ▼
                        Internal API Gateway
                              │
                    ┌─────────┼─────────┐
                    ▼         ▼         ▼
                 Service A  Service B  Service C
                  └── 适合：大型系统，多客户端、多团队

模式 C：Sidecar 网关（Service Mesh）

Client ──→ Ingress Gateway
              │
    ┌─────────┼─────────┐
    ▼         ▼         ▼
 Pod A     Pod B     Pod C
 [App+Envoy] [App+Envoy] [App+Envoy]  ← Sidecar 代理
    │         │         │
    └─────────┴─────────┘
                   │
            Internal Services
            └── 适合：Kubernetes 环境，细粒度治理

与 Service Mesh 的关系

关键洞察：API Gateway 和 Service Mesh 不是二选一，而是互补。Gateway 处理外部流量入口，Service Mesh 处理内部服务通信。

8. 网关性能调优

总结

网关是门面，BFF 是翻译。二者配合，为微服务提供统一且灵活的对外接口。在实际落地时，应根据团队技术栈和系统规模选择合适的部署模式：小型系统使用集中式网关即可，大型系统则需要分层网关 + Service Mesh 的组合方案。