API 网关如何把内部服务变成统一入口？
- API 网关: 位于客户端与后端服务之间，隐藏内部拓扑并提供面向客户端的接口入口;
- 粒度问题: 微服务接口可能比页面需求细，一个页面直接调用多个服务会增加客户端复杂度;
- 接口组合: 网关可以聚合需要的数据，但应控制同步依赖数量与总体超时;
- 职责边界: 网关承担入口策略，核心业务规则仍应由相应服务负责，避免网关演变成另一个巨型单体;
网关通常集中哪些横切能力？
| 类别 | 典型能力 |
|---|
| 身份与访问 | 认证、授权、IP 访问控制 |
| 路由 | 反向代理、服务发现、负载分配、版本选择 |
| 流量保护 | 限流、节流、超时、重试、熔断 |
| 性能 | 缓存、请求聚合 |
| 运维 | 日志、指标、追踪 |
- 产品边界: 并非所有网关都原生支持所有协议与功能，HTTP、WebSocket 或其他流量需要逐项确认;
- 重试边界: 网关自动重试写入可能重复执行，应结合请求幂等与后端状态语义;
- 授权边界: 网关识别用户不代表每个后端对象访问都已获准，资源级授权仍需校验;
网关怎样避免拖累整个系统？
- 容量: 所有入口流量集中后需要独立扩容，限制昂贵聚合并观察尾延迟;
- 可用性: 多实例和明确接管机制避免单点，配置错误也应能快速回滚;
- 配置成本: 路由、版本和策略随服务增加而复杂，应保持规则可审查;
- 收益评估: 用客户端调用简化与治理收益对照新增延迟和运维开销;
BFF 如何为不同客户端提供合适的数据？
- BFF: Backend For Frontend，为特定前端建立专用后端适配层，例如移动端和桌面端分别聚合所需数据;
- 处理路径: 从领域服务取数，筛选、格式化并组合成前端需要的形状;
- 适用条件: 单一通用 API 为多个界面反复定制，已经带来明显复杂度或带宽浪费;
- 权衡: 每种客户端更容易独立演进，但增加适配服务数量并可能重复逻辑;
- GraphQL: 可作为 BFF 的接口表达方式，但 BFF 并不要求使用 GraphQL;
网关与 BFF 怎样分工？
- 网关: 优先处理整个系统共享的入口路由和保护策略;
- BFF: 优先处理某类客户端特有的数据组合与交互适配;
- 原文示例: Amazon API Gateway、Apigee、Azure API Management、Kong，选型以所需边界为准;