API中转网站
🏦 场景与客户
某技术团队把自研的模型能力对外提供，付费客户几十家，接口调用量按天计。原做法很原始：每家客户直接拿上游的密钥去调，团队这边只留了一张 Excel 记录谁领了哪把钥匙。
卡点很集中：密钥散落在客户代码里，泄漏了也不知道；用量算不清，月底账单靠估算；某个客户的脚本跑飞，把整月额度打满，其他人的调用全被拖慢；上游换了接口参数，得挨个通知客户改代码。
📅 实施节奏
- 第 1–2 周：梳理对外接口契约与鉴权方案
- 第 3–4 周：网关（鉴权、限流、转发）与配额
- 第 5 周：用量统计与账单
- 第 6 周：监控告警与对外状态页
- 第 7 周：客户灰度切流，旧密钥限期停用
🗝️ 方案要点
- 密钥只发本站的：客户拿的是平台签发的密钥，上游密钥只存服务端，客户完全无感
- 网关只做三件事：鉴权、限流、转发。转发时统一改写鉴权信息，屏蔽上游差异
- 配额双层限制：每秒请求数与每日额度分别限制，超额返回明确错误码，不做静默失败
- 用量异步聚合：按请求记录元数据，异步汇总出账，不逐条同步写账
- 上游多路：同一能力接两家供应商，按健康度自动切换
⚖️ 选型与权衡
| 选择点 | 方案 | 权衡 |
|---|---|---|
| 计费粒度 | 按量 + 按次混合 | 贴近真实成本；聚合与对账逻辑更复杂 |
| 限流 | 单机限流 + 全局计数 | 准；全局计数引入额外延迟，要容忍微小超发 |
| 上游接入 | 多供应商 + 适配层 | 抗故障、可议价；各家返回格式不同，适配层要长期维护 |
| 日志 | 全量元数据 + 分层保留 | 便于追责与对账；存储成本可观，需要按时间分层淘汰 |
🚧 实施难点与排查
- 上游超时拖垮网关：同步等待把连接占满，本站也跟着挂。改为快速失败 + 降级到备用上游
- 额度算不准：并发下计数丢失。改为原子计数，并定期与账单核对
- 客户以为是本站故障：上游慢但没暴露出来。加了对外状态页与请求级追踪号，客户可自查
- 密钥泄漏：密钥被写进客户端代码。加了来源白名单与一键吊销
💵 成本与收益
- 成本结构：一次性开发约 2 人 × 6 周量级；网关与日志存储是主要运行成本
- 收益侧：用量透明之后，按量计费可谈，收入与成本能对上
- 运维侧：上游变更只改适配层，客户不用动代码，支持负担明显下降
🛡️ 风险与保障
- 鉴权：密钥可轮换、可限制来源、可设到期时间
- 防滥用：单密钥与单客户双层限流，用量异常触发告警并可临时冻结
- 数据：请求内容默认不落盘，只保留元数据，避免客户数据在平台留存
- 可用性：上游熔断与降级，状态页对外公开，故障时不靠客服口头解释
♾️ 可复用与演进
- 网关可扩展为统一的对外接口出口，陆续接入更多能力
- 演进方向：加用量看板，客户自助查余量与账单，减少人工答疑
- 再进一步：按客户做智能路由，在质量达标前提下自动选成本更低的上游
