API

1. 定义与职责

API 网关层位于 接入层之后、业务服务之前，是所有业务 API 的统一入口。
它不承载核心业务逻辑，而是负责 流量治理、安全控制、协议适配和可观测性。

核心职责：

1. 统一 API 入口，屏蔽后端微服务复杂性
2. 流量控制（限流 / 熔断 / 降级）
3. 认证与鉴权
4. 协议与数据格式转换
5. 灰度发布与版本管理
6. API 级别监控与审计

---

2. API 网关在整体架构中的位置

接入层 (DNS / CDN / WAF / LB)
│
▼
┌─────────────────────────┐
│ API 网关层 │
│ 统一入口 / 流量治理 │
└─────────────────────────┘
│
▼
应用层（微服务 / RPC / gRPC）

---

3. 核心功能模块

3.1 API 路由与聚合

作用：
将外部请求路由到正确的后端服务，必要时对多个服务结果进行聚合。

能力：

• 路径 / Host / Header 路由
• API 版本管理（v1 / v2）
• 多服务结果聚合（BFF 模式）

设计要点：

• 网关只做“轻逻辑”，避免业务侵入
• 聚合逻辑尽量简单，复杂逻辑下沉到应用层

---

3.2 认证与鉴权（AuthN / AuthZ）

作用：
统一处理身份认证和权限校验，避免每个服务重复实现。

常见方式：

• OAuth2
• JWT / Access Token
• API Key
• mTLS（服务间）

设计要点：

• 鉴权在网关完成，服务默认信任网关
• Token 校验失败直接在网关拦截
• 权限模型要与业务解耦

---

3.3 限流（Rate Limiting）

作用：
防止流量洪峰、恶意请求或雪崩效应。

限流维度：

• IP
• 用户 ID
• API Key
• 接口级别

常见算法：

• Token Bucket
• Leaky Bucket
• 固定窗口 / 滑动窗口

设计要点：

• 区分 保护系统 和 限制用户
• 限流策略可动态调整
• 支持不同 API 不同限额

---

3.4 熔断与降级

作用：
当下游服务异常时，防止请求持续放大故障。

能力：

• 熔断（Circuit Breaker）
• 快速失败
• 服务降级（返回兜底数据）

设计要点：

• 熔断是“止血”，不是“修复”
• 降级返回应可被客户端识别
• 熔断策略要基于真实指标（错误率、延迟）

---

3.5 协议与数据转换

作用：
解耦客户端与后端服务的通信方式。

常见场景：

• HTTP → gRPC
• REST → RPC
• JSON → Protobuf
• Header / Body 结构转换

设计要点：

• 网关适配客户端多样性
• 后端服务内部通信保持高效协议

---

3.6 灰度发布与流量切分

作用：
支持无感知发布、风险控制。

能力：

• 按比例分流（5% / 10%）
• 按用户 / Header 分流
• A/B Test

设计要点：

• 与 CI/CD / 配置中心联动
• 支持快速回滚
• 流量规则必须可观测

---

3.7 日志、监控与审计

作用：
API 级别的可观测性和合规审计。

监控指标：

• QPS / TPS
• P99 / P95 延迟
• 错误率
• 熔断 / 限流触发次数

日志内容：

• 请求路径
• 用户标识
• 响应状态
• 耗时

---

4. 技术选型

能力	技术 / 产品
API 网关	Kong、Apigee、Tyk
高性能代理	Nginx + Lua、Envoy
服务网格集成	Istio Ingress Gateway
鉴权	OAuth2、JWT、Keycloak
限流熔断	Envoy、Istio、Resilience4j

---

5. 架构文本图（API 网关层）

来自接入层流量
│
▼
┌─────────────────────────────┐
│ API 网关 │
│ ────────────────────────── │
│ • 路由 & 版本管理 │
│ • 认证 / 鉴权 │
│ • 限流 / 熔断 / 降级 │
│ • 协议 & 数据转换 │
│ • 灰度发布 / A/B Test │
│ • 日志 / 指标 / 审计 │
└─────────────────────────────┘
│
▼
应用层（微服务）

---

6. CTO 级设计权衡

1. API 网关 ≠ 业务层

   • 只做治理，不写业务逻辑

2. 性能 vs 功能

   • 网关是高 QPS 组件，功能必须克制

3. 集中治理 vs 单点风险

   • 网关必须集群化、无状态

4. 与 Service Mesh 的边界

   • 外部流量：API 网关
   • 内部服务：Service Mesh

5. 可演进性

   • 初期：Nginx / Kong
   • 成熟期：Envoy + Istio

---

7. 常见错误设计（反例）

• 在网关中实现复杂业务逻辑
• 把网关当成 BFF 滥用
• 没有限流策略直接暴露服务
• 网关无监控，出问题无法定位

---

一句 CTO 总结：
API 网关是“系统的交通警察”，不是“业务开发者”。