API 网关应该承担哪些职责？鉴权、灰度、限流怎么设计？
结论先行：网关是流量进入微服务的第一道门，负责收口横切关注点：路由转发、统一鉴权、限流熔断、灰度发布、日志监控、协议转换。设计原则是只放轻量通用逻辑，重业务逻辑下沉到服务内，避免网关变成巨型单点。
一、网关 vs 负载均衡器
| 能力 | Nginx/LB | API 网关 |
|---|---|---|
| 四层/七层转发 | 是 | 是 |
| 协议转换/聚合 | 弱 | 强（HTTP/gRPC/WebSocket） |
| 鉴权、限流、灰度 | 简单规则 | 面向业务可编程 |
| 与注册中心联动 | 弱 | 强（自动发现服务） |
二、鉴权设计
- 白名单放行：登录、回调、健康检查等接口不过滤。
- Token 校验：网关验 JWT 签名与有效期，用户身份透传 Header 给下游。
- 签名防篡改与防重放：appId + timestamp + nonce 参与签名，时间窗内 nonce 去重。
- 粒度原则：网关做是否登录与角色粗校验，细粒度数据权限在业务服务内做。
三、灰度发布设计
规则分层：
1) 按请求特征：Header/Cookie 灰度标记、用户 id 尾号、白名单账号
2) 按流量比例：5% → 20% → 50% → 100% 渐进放量
3) 失败自动回退：灰度组错误率超阈值立即切回稳定版本
- 灰度必须可观测：两组流量都要有 trace 与对比面板，否则无法判断是否继续放量。
四、限流设计
- 分两层：网关层粗限流（按 IP/用户/接口），服务层细限流（按资源配额）。
- 网关多实例时必须用分布式限流：Redis + 令牌桶或滑动窗口（见第 43 章）。
- 被限流返回 429 并带 Retry-After，客户端按语义退避，不能无限重试。
五、性能与可用性红线
- 网关只做轻量逻辑，禁止在网关层 join 数据库或做大对象组装。
- 网关独立集群部署、多机房容灾，自身故障要有 bypass 通道。
- 记录访问日志并透传 traceId（见第 44 章），出问题才能按链路排查。
常见追问与记忆点
- 追问：网关鉴权和业务鉴权重复怎么办？约定清晰：网关验身份与入口合法性，业务验授权与数据范围。
- 追问：网关如何感知后端下线？接入注册中心监听，结合主动健康检查摘除节点。
- 记忆点：网关收口横切面：路由 + 鉴权 + 限流 + 灰度 + 日志；只放轻逻辑、重逻辑下沉、自身要高可用。