API 网关成本并不是“每次请求的一个单价”，而是平台费用或基础设施分摊、流量计量、网络传输、依赖服务、可观测性，以及运维所需人力与风险的总和。优化目标应当是可靠性目标下每个成功业务操作的总成本，而不是账单中最显眼的网关条目。
基于工作负载的模型可以比较托管、订阅与自建方案，而且无需把不断变化的厂商单价固化成架构决策。
核心要点
- 分别计算固定成本、用量成本、资源分摊与运维成本。
- 根据服务商当前的负载、消息、区域与功能规则，把原始请求转换成计费单元。
- 纳入重试、被拒流量、WebSocket 时长、日志、指标、缓存、私网连接与下游调用。
- 自建部署要分摊容量与空闲冗余，不能把开源软件直接称为“免费”。
- 在保留安全、证据与 SLO 的前提下，衡量每个成功业务操作的成本。
比较产品前先划定成本边界
从一张覆盖单次 API 请求全部依赖的图开始：
1flowchart LR
2 C[客户端流量] --> E[边缘与网络]
3 E --> G[API 网关]
4 G --> I[身份与策略依赖]
5 G --> U[上游服务]
6 G --> O[日志指标与 Trace]
7 E --> M[网络费用]
8 G --> M
9 I --> M
10 U --> M
11 O --> M
12 M --> B[每个成功业务操作的成本]如果比较中计入托管网关费用，却不包含 Load Balancer、Egress、身份调用、日志摄取或 On-call 工作，就没有在比较同等系统。计算总额前，应先明确每项成本由哪个团队与服务负责。
使用能适应价格变化的模型
按月计算时，应从当前服务商价格表取得变量，并代入测得的工作负载：
1Total gateway cost =
2 fixed platform or subscription cost
3 + request or message units × current unit rate
4 + connection duration × current duration rate
5 + network transfer × current network rate
6 + cache or dedicated capacity hours × current hourly rate
7 + allocated compute, memory, storage, and load-balancer cost
8 + identity, policy, and data-store dependency cost
9 + log, metric, trace, and retention cost
10 + engineering, support, and incident-risk cost
11
12Unit business cost = Total gateway cost / successful business operations
把费率保存在带日期的价格输入表中，而不是写入应用代码或长期使用的架构图。记录币种、区域、Tier、折扣、税务口径与获取日期，并对增长、流量高峰、负载大小、缓存命中率与故障放大进行敏感度分析。
统一不同计费模型的口径
| 模型 | 常见计量项 | 容易遗漏的比较陷阱 |
|---|---|---|
| 按量网关 | 请求、负载计费增量、消息、连接分钟数 | 一次客户端操作可能产生多个计费单元 |
| 托管容量 | Environment、Gateway 或 Capacity Hour，再加调用量 | 最小容量或空闲容量仍可能计费 |
| 订阅 | 合同 Tier、调用额度、Add-on、支持服务 | 超额用量与不包含的能力可能成为主要成本 |
| 自建网关 | CPU、内存、节点、Load Balancer、传输、存储 | 共享资源与空闲资源经常被漏算 |
Amazon API Gateway 定价说明了为什么必须建立计量模型，而不能简单归纳为“按请求计费”：HTTP API 与 REST API 涉及 API 调用和数据传出；REST Cache 按缓存大小与时间计费；WebSocket API 按消息与连接分钟数计费；关联的 AWS 服务还可能产生独立费用。
Apigee 按量计费说明使用多种资源维度，其中包括活跃 Environment 小时数、API 调用量与 Proxy Deployment Unit。具体 SKU 费率与阈值可能变化，应根据目标区域与决策日期重新获取。
对于运行在 Kubernetes 上的网关，OpenCost 规范把资源分配成本、用量成本、空闲成本与共享开销分开。即使账单由其他工具生成，这种结构仍然有用：分配的 CPU 与内存、网络用量、空闲冗余与共享平台服务都需要明确归属规则。
建立工作负载表，而不是只看平均 RPS
按成本与后果拆分流量：
| 工作负载 | 流量维度 | 成本放大因素 | 可靠性约束 |
|---|---|---|---|
| 小型缓存读取 | 请求数、缓存查询、Egress | 低命中率与大 Header | 新鲜度与隐私 |
| 大文件下载 | 请求数与响应字节 | Payload 计费增量与公网 Egress | 吞吐与断点续传行为 |
| 已认证写入 | 请求数与身份调用 | Token Introspection、重试、审计日志 | 幂等与证据 |
| WebSocket 或 Streaming | 连接数、时长、消息、字节 | 空闲连接与重连风暴 | Session 连续性与背压 |
| 合作伙伴 Batch API | 每个 Envelope 的操作数、字节、CPU | 一个请求扇出成许多操作 | 每个合作伙伴的配额与部分失败 |
每一行都要测量平均值、Percentile 与 Peak。被拒流量也要纳入，因为认证、WAF、限流与日志可能在拒绝前消耗资源。还应计入非生产环境、灾备与部署重叠。即使生产请求量不变，Canary 在一小时内把容量翻倍也是真实成本。
采集模型需要的输入
Apache APISIX 3.19.0 的 prometheus 插件导出请求、状态、延迟、连接与带宽指标，可以填充工作负载模型的一部分。apisix_bandwidth 统计流量字节，请求与状态指标则反映流量和结果。这些指标是运维测量值，不是服务商账单；仍需与发票和基础设施分摊对账。
插件的 prefer_name 布尔参数默认为 false。取值为 false 时，支持的指标 Label 使用 Route 或 Service ID；取值为 true 时改用名称。名称更容易阅读，而名称发生变化时，稳定 ID 可能更适合 Join。两条路径都不会自动产生可信的计费归属。应把选定 Label 映射到经过审查的团队、产品、租户或成本中心清单，并控制指标 Cardinality。
还要加入网关指标无法单独提供的数据：
- 成功订单、支付、搜索或其他业务结果；
- 缓存命中、未命中与 Revalidation；
- 认证与策略决策调用；
- 客户端、网关、服务与 SDK 分别产生的重试；
- 日志、指标与 Trace 字节，以及留存 Tier；
- 节点分配、空闲冗余与自动扩缩容事件；
- 网络路径、Region、Zone 与公网 Egress；
- 事故、支持与升级工作量。
除非可信认证层会绑定并覆盖调用方提供的租户 Header，否则不能把它用作 Showback 或 Chargeback 身份。成本分摊本身也是财务信任边界。
按证据确定优化顺序
1. 移除意外产生的工作
查找重试风暴、重复客户端调用、经过高成本策略的健康检查、无界 Batch、本应改用事件的轮询，以及在完成高成本上游工作后才失败的请求。修复放大效应通常比微调代理节省更多。
2. 安全减少字节数
对列表分页、只选择需要的字段、压缩体积足够大且可压缩的负载，并把大媒体移到合适的交付路径。评估压缩时要计入 CPU 成本与延迟。没有完整 Cache Key 与授权边界时，不能缓存或共享私有响应。
3. 让容量符合 SLO
在保留经过测试的故障、部署与流量突发冗余后，再调整基础容量。清除全部空闲容量可能降低分摊报表，却提高事故风险。改变自动扩缩容或冗余前，应测量 Saturation、Queue Age、Tail Latency 与恢复时间。
4. 按价值调整可观测性
使用结构化采样、脱敏、留存 Tier、指标 Cardinality 限制与 Payload 排除。不要只为降低摄取成本而关闭安全审计证据。先定义哪些日志服务于事故、合规、计费与产品分析，再为每类数据设置最短且合理的留存期。
5. 重新评估商业模式与部署拓扑
测得工作负载后，再比较按量、预留容量、订阅与自建方案。纳入迁移、支持、多区域、合规与运维人员技能。更低的基础设施账单可能被更多工程与事故成本抵消；托管服务溢价也只有在实际替代了能力与工作时才合理。
防止“虚假节省”
- 提高限流阈值可能只是把成本与过载转移到数据库。
- 激进缓存可能返回过期数据或未授权数据。
- 关闭跨区域冗余可能把区域故障扩大成业务中断。
- 对所有错误采样可能删除诊断罕见故障所需的证据。
- 配额后端不可用时失败开放，可能制造没有上限的服务商账单。
- 按原始请求量计费，可能惩罚高效 Batch 客户端，也可能掩盖高成本操作。
每项优化都需要成本假设、可靠性与安全 Guardrail、测量窗口和回滚条件。
成本审查清单
- 成本边界是否包含网络、身份、可观测性、依赖与运维？
- 当前费率是否带日期、对应准确区域，并与工作负载数据分开？
- 是否计算 Payload 增量、消息、连接时长与 Add-on？
- 是否计入重试、拒绝、Batch 与非生产流量？
- 自建资源分配、空闲冗余与共享成本是否已归属？
- 是否根据成功业务操作与 SLO 衡量成本？
- 租户与成本中心 Label 是否源自可信身份？
- 每项拟议节省是否保留安全、证据与回滚能力？
- 部署后是否用发票校准估算？
常见问题
自建开源网关免费吗？
开源软件可能不需要许可证费用，但计算、内存、网络、存储、可观测性、升级、安全响应与 On-call 工作仍然会产生成本。
应该按请求衡量成本吗？
请求数可以作为一项输入，但不应成为最终分母。应该比较每个成功业务操作的成本，并按工作负载拆分，因为不同请求包含的字节数、操作数与下游工作可能完全不同。
缓存一定会降低成本吗？
不一定。缓存本身会增加容量与运维成本，错误 Cache Key 还可能引发安全事故。只有测得的源站与传输节省超过缓存成本，而且新鲜度与授权契约安全时，才适合使用缓存。
后续步骤
把成本模型与网关 QoS 和容量保护、并发预算以及日志存储留存与成本关联起来。