《互联网产品的服务端架构·规模化与架构演进》5.1 单位经济模型

86 万元的账单，回答不了“每单赚多少”

「回声」是一个社区加轻电商的混合产品。某个月，云账单第一次突破 86 万元（案例假设值），CFO 在经营会上问了一个很朴素的问题：我们每成交一单，服务端成本是多少？

运营同学当场算了一个数：86 万除以 62 万支付订单，约 1.39 元一单。会议室里有人点头，因为听起来不高；也有人皱眉，因为这个数把图片审核、推荐流、免费用户的浏览、爬虫流量全都摊进了付费订单。两周后，团队按这个数做了一次定价调整，把包邮门槛降了 10 元，结果订单涨了 18%，账单涨了 31%，毛利反而更薄。

问题不在除法，而在分母。单位经济模型的第一件事不是优化成本，而是承认“单位”是一个业务定义，不是账单自带的属性。分母选错，后面所有优化都会朝着错误的方向使劲。

这一节先把常见分母摊开对比，再说明成本应该怎么聚合，最后复盘那次定价误判，并给出一个只负责“精确相加”和“校验分母”的 Go 实现。

分母决定你在回答谁的问题

同一张账单，至少可以除以四类分母。它们都叫“单位成本”，但回答的是完全不同的问题：

表里的数字都是案例假设值，不是行业基准。真正要带走的是最后一列：每个分母都带着一种偏差，选择分母等于选择“愿意忽略哪部分成本”。如果管理层要判断定价能否覆盖服务端成本，支付订单是合适的；如果工程团队要判断一次推荐刷新是否太贵，总请求或有效会话更合适。把两个问题混成一个数字，就会得到那次定价会议上的 1.39 元。

分母还要写清楚统计口径。支付订单是“支付成功”还是“创建订单”？月活跃用户是自然月去重还是滚动 30 天？有效会话的静默超时是 15 分钟还是 30 分钟？口径变一次，单位成本就会跳一次，而账单本身没有任何变化。单位经济模型的报表必须把口径和数字印在一起，否则历史对比没有意义。

分母要能下钻到同一批对象

单位成本最容易出错的地方，是分子和分母来自两套不同的数据管道。账单按小时出，订单按支付回调计数，用户按登录事件去重。三条管道的延迟、重试和去重规则都不一样，月末对齐时就会出现“成本已经发生、订单还没入账”的时间差。

一个实用的检查是抽样下钻：随机取 100 个订单，把它们的请求日志、资源标签和账单条目串起来，确认每一分钱都能归到某个可解释的位置。如果 100 个订单里有 30 个找不到对应成本，说明分子和分母覆盖的不是同一批对象，此时算出来的单位成本只是两个独立数字的商。

下钻还要回答“谁承担”。免费用户的浏览成本由平台承担，付费订单的履约成本由交易收入覆盖，广告位的带宽成本可能由投放预算承担。把这些责任混在一个分母里，业务方会觉得自己被多摊了钱，财务方会觉得平台成本失控。责任边界应该在模型里显式写出来，而不是靠会议上的口头解释。

固定成本与边际成本不要混算

单位成本还有一层容易被忽略的区分：固定成本和边际成本。机房包年、预留实例、基础监控这些费用不随订单量变化；每多一次图片审核、每多一次推荐推理，才会产生近似线性的边际成本。把两者加在一起除以订单数，得到的是“平均成本”，不是“多一单要多花多少钱”。

定价看边际成本，容量规划看平均成本，两件事不能互换。假设一个月的固定成本是 50 万，边际成本是每单 0.8 元，62 万单的平均成本约 1.61 元；订单涨到 100 万单时平均成本会降到 1.3 元，但每多一单仍然要多花 0.8 元。如果因为平均成本下降就降价到 1 元，新增订单越多，亏得越多。

时间窗口要和决策周期匹配

单位成本按日算、按周算还是按月算，会得到不同的数。按日算，分母小、波动大，一次推送或一次故障就能让曲线翻倍；按月算，和账单周期对齐，适合做经营决策；按滚动 7 天算，介于两者之间，适合做告警。

一个常见做法是三层并存：日报看趋势，周报看异常，月报看结算。三层使用同一套分子分母口径，只是聚合窗口不同。如果日报和周报各自维护一套 SQL，时间一长必然分叉，最后没人知道该信哪个。

窗口还要和业务节奏对齐。大促月的单位成本通常低于平月，因为固定成本被更大的订单量摊薄；如果拿大促月的数据做全年预算，会系统性低估成本。报表应该同时标注窗口和是否包含大促，避免把特殊月份当成常态。

从单位成本到定价要留安全边际

服务端单位成本是定价的下限，不是定价本身。除了计算、存储和带宽，一笔订单还要覆盖支付通道费、退款损失、客服人力、税费和利润。把 1.39 元的服务端成本直接当成“每单成本”，再按 20% 毛利定价，几乎一定亏。

假设服务端成本 1.39 元，支付通道费 0.2 元，退款与售后分摊 0.3 元，客服与运营分摊 0.4 元，合计 2.29 元（均为案例假设值）。如果客单价是 30 元，这些成本占 7.6%，看起来还有空间；如果客单价是 5 元，占比接近 46%，定价就必须非常谨慎。

安全边际不是拍一个百分比，而是把每一项成本单独列出来，标明哪些随订单线性增长、哪些是固定分摊。线性增长的部分决定“多一单是否赚钱”，固定分摊的部分决定“这个业务要多大才能盈亏平衡”。单位经济模型的价值，就是让这两个问题分开回答。

成本先按资源归因，再谈分摊

账单天然按云厂商的产品线组织：计算、对象存储、CDN、数据库、消息队列。业务方关心的是功能线：推荐、搜索、下单、支付、审核。两者之间不是一对一，需要一张归因表。

「回声」的做法是先分三个桶：计算、存储、带宽。每个桶再按标签拆到服务，服务再按调用比例拆到功能。拆分不追求绝对精确，但要求可解释、可复算。一个功能分摊到 12% 的计算成本，必须能说清楚这 12% 来自哪些实例、哪些接口、哪段时间。

这里有一个容易忽略的细节：成本要用整数分聚合。用浮点元做累加，几十个服务、上百个标签加完之后会出现几分钱的漂移，对账时没人愿意花半天解释“为什么总和和账单差 0.03 元”。整数分不能消除分摊误差，但能把“计算误差”和“口径误差”分开。

成本结构也要分开看。计算成本相对平滑，按实例规格和运行时长计费；存储成本随数据保留期累积；带宽成本随流量峰值和回源比例波动。把三者合成一个数再优化，很容易出现“省了存储、涨了带宽”的假胜利。

归因标签的命名要克制。常见的坏例子是 service=api、env=prod、team=backend 这类过于宽泛的标签，最后每个团队都叫 backend，每个服务都叫 api，拆分退化成人工拍脑袋。好的标签至少包含服务名、环境、负责团队和一个能对应到业务功能的维度，并且由平台统一分配，不允许各团队自由发挥。

标签还会影响账单的可追溯性。云厂商的标签一旦漏打，事后无法补到历史账单，只能按比例估算。因此新服务上线时，标签应该和部署清单一起评审；没有标签的实例不应该进入生产。这个约束听起来和成本无关，实际上是成本治理里最便宜的一道门。

分摊比例要能复算

按调用比例分摊共享资源时，比例本身要能被复算。例如推荐流和搜索共用一组特征服务，分摊比例来自过去 30 天的调用次数，那么报表旁边应该能点开这 30 天的原始计数。只写一个百分比而不给计算过程，下一次有人质疑时，团队只能重新跑一遍查询，往往还算不出同一个数。

复算的另一个要求是冻结历史。分摊比例每月重算，但已经出过的报表不能被新数据改写。正确做法是每月生成一份不可变的分摊快照，包含原始计数、比例、单价和最终金额。这样即使标签体系后来调整，历史月份仍然能解释清楚。

共享成本怎么分

网关、消息队列、监控、日志这些共享资源，天然不属于某一个业务。常见的分法有三种：按调用量分、按资源占用分、按固定比例分。三种都能用，但必须写清楚适用边界。

按调用量分适合请求特征接近的服务；按资源占用分适合计算密集、调用次数不能反映真实消耗的服务；按固定比例分最省事，也最容易在业务变化后失真。无论选哪种，都要保留一条“可回到原始计量”的路径，否则分摊结果无法被质疑，也无法被改进。

共享成本还应该设一个上限。如果某个业务分摊到的网关成本超过它自身直接成本的 30%，说明分摊规则可能把平台的基础开销过度压给了它。这个阈值不是财务准则，而是一个提示团队重新检查计量口径的信号。

口径文档要跟代码一起评审

单位成本的分母定义、归因范围和分摊规则，应该写在一份可版本化的口径文档里，和计算代码放在同一个仓库。文档变更时，代码评审要同时看三件事：新口径是否影响历史对比、是否需要重跑报表、是否需要在页面上标注生效日期。

把口径写在文档里而不是散落在聊天记录里，最大的好处是新人能自己读懂数字是怎么来的。成本模型最怕的不是算错，而是只有一个人知道怎么算；那个人休假时，所有质疑都无法回答。

文档不需要很长，一页纸足够：分母是什么、分子覆盖哪些成本、分摊比例怎么来、哪些成本被排除。每个字段都配一个负责人。超过一页的部分，通常是规则开始失控的信号。

一次“每单成本下降”的假象

那次定价调整之后，团队做了月度复盘。报表显示每单服务端成本从 1.39 元降到 1.21 元，结论是“效率提升”。但账单总额从 86 万涨到了 112 万（案例假设值），订单从 62 万涨到 73 万。1.21 元乘以 73 万，约 88 万，和 112 万对不上。

追查后发现两个问题。第一，报表只统计了主站订单服务，图片审核和推荐流的成本记在另一个成本中心，没有进入分子。第二，降价带来的新增订单里，有大量低客单价订单触发了运费补贴，补贴记在市场费用里，不在服务端账单里，但发货和售后接口的调用量真实增加了。

更隐蔽的是分母的变化。为了冲订单量，运营把“创建订单”也计入了支付订单口径，73 万里有 9 万是未支付订单。分子漏了成本，分母掺了水，单位成本当然下降。这个数字被写进季度汇报，直到财务对账时才被发现。

这类事故的共同点不是算错，而是“单位”没有版本。分母口径、归因范围、成本桶的边界，任何一项改变都应该产生一个新的报表版本，并在页面上标注生效日期。否则同一个指标名在不同月份代表不同东西，趋势线就是一条编出来的故事。

复盘时还有一个细节值得记录：报表页面上的数字没有小数位，1.39 和 1.21 看起来都是“一块多”，没人注意到变化幅度只有 13%，而账单涨幅是 30%。单位成本应该和账单总额、订单量放在同一屏，让三个数互相校验。任何一个数和另外两个对不上，就说明口径已经分叉。

团队后来加了一条硬规则：单位成本报表必须附带一份对账行，写明“分子总额 × 分母数量 = 预计账单”，并与实际账单比较，偏差超过 3% 就标黄。这条规则不能自动修复口径，但能让错误在发布的当天被看见，而不是等到季度汇报。

对账行应该长什么样

对账行的最小形式是四列：分子总额、分母数量、单位成本、预计账单。预计账单等于前两列相乘，第四列和实际账单并排展示。任何人打开报表，都能在一行里完成乘法校验，不需要理解背后的 SQL。

对账行还要写清“预计账单覆盖了哪些成本项”。如果它只覆盖主站计算和存储，却拿全量账单去比，偏差会一直存在，团队很快学会忽略黄色标记。正确做法是为每个成本中心各做一行，最后再加一行汇总，让偏差定位到具体范围。

比偏差更值得记录的是偏差的解释。3% 以内的偏差可以归为计提时间差，超过 3% 必须有文字说明：是新服务漏了标签，还是某笔一次性费用没有分摊，还是账单周期和统计周期错位。对账行不是给别人看的装饰，它是模型的自检日志。

修复方案并不复杂：把成本聚合与分母校验做成两个独立步骤。聚合只接受整数分和明确的成本桶；计算单位成本时，分母必须由调用方显式传入，并在为零或负数时直接失败。下面就是这个最小实现。

用整数分聚合，把分母校验前移

配套代码 internal/cost/unit.go 刻意只做三件事：表示三项成本、逐字段相加、按单位数求平均。它不读取账单、不做标签匹配、不决定分母，因为这些都属于业务口径，应该由调用方显式表达。

// file: internal/cost/unit.go
// tier: L1
// verify: go test ./internal/cost/

package cost

import "fmt"

// Cost 用整数分表示一类资源在一个统计周期内的成本。
// 使用整数而不是浮点，是为了让多处聚合的结果可以精确对账；
// 只有在计算“每单位成本”时才允许出现小数。
type Cost struct {
	Compute   int64
	Storage   int64
	Bandwidth int64
}

// Add 逐字段累加两份成本。
// 不做溢出检查：调用方应保证单个统计周期的金额远小于 int64 上限。
func Add(a, b Cost) Cost {
	return Cost{
		Compute:   a.Compute + b.Compute,
		Storage:   a.Storage + b.Storage,
		Bandwidth: a.Bandwidth + b.Bandwidth,
	}
}

// Total 返回三项成本之和，单位仍是分。
func (c Cost) Total() int64 {
	return c.Compute + c.Storage + c.Bandwidth
}

// PerUnit 返回每个单位分摊的成本，单位是分/单位。
// units 必须为正数：分母为零会让结果变成 +Inf，
// 负分母则会让“成本为负”这种不可能的信号被悄悄接受。
func PerUnit(c Cost, units int64) (float64, error) {
	if units <= 0 {
		return 0, fmt.Errorf("cost: units must be positive, got %d", units)
	}
	return float64(c.Total()) / float64(units), nil
}

Add 逐字段相加而不是先求和再相加，是为了保留成本结构。如果只保留总额，后续想回答“带宽占了多少”就必须回到原始数据重算。字段分开还有一个好处：当某个桶的口径变化时，可以单独替换这个桶，而不影响另外两个桶的历史数据。

PerUnit 在 units <= 0 时返回错误，而不是返回 0 或 +Inf。分母为零通常意味着上游筛选条件写错，例如“统计昨天支付的订单”却传了一个空时间窗；分母为负则更危险，它会和负成本相消，产出一个看起来正常的正数。让函数在入口失败，比让错误数字流进经营报表便宜得多。

这个实现故意不处理“成本为负”。退款、抵扣、预留实例折扣都应该在生成 Cost 之前完成冲减，保证进入聚合的数据是非负的。把负数留在聚合层，会让 Total 和 PerUnit 的语义变得含糊：一笔负成本究竟算哪个桶的减少？

测试：零分母、负分母和空成本

单位经济模型的测试重点不是除法结果，而是坏输入是否被挡住。下面的测试把加法、总额、正常除法、零成本以及非正分母都固定下来。

// file: internal/cost/unit_test.go
// tier: L1
// verify: go test ./internal/cost/

package cost

import (
	"math"
	"testing"
)

func TestAdd(t *testing.T) {
	a := Cost{Compute: 100, Storage: 20, Bandwidth: 30}
	b := Cost{Compute: 1, Storage: 2, Bandwidth: 3}
	got := Add(a, b)
	want := Cost{Compute: 101, Storage: 22, Bandwidth: 33}
	if got != want {
		t.Fatalf("Add() = %+v, want %+v", got, want)
	}
}

func TestCostTotal(t *testing.T) {
	c := Cost{Compute: 100, Storage: 20, Bandwidth: 30}
	if got := c.Total(); got != 150 {
		t.Fatalf("Total() = %d, want 150", got)
	}
}

func TestPerUnit(t *testing.T) {
	c := Cost{Compute: 400, Storage: 100, Bandwidth: 100}
	got, err := PerUnit(c, 3)
	if err != nil {
		t.Fatalf("PerUnit(): %v", err)
	}
	if math.Abs(got-200) > 1e-9 {
		t.Fatalf("PerUnit() = %f, want 200", got)
	}
}

func TestPerUnitZeroCost(t *testing.T) {
	got, err := PerUnit(Cost{}, 10)
	if err != nil {
		t.Fatalf("PerUnit(): %v", err)
	}
	if got != 0 {
		t.Fatalf("PerUnit() = %f, want 0", got)
	}
}

func TestPerUnitRejectsNonPositiveUnits(t *testing.T) {
	for _, units := range []int64{0, -1, -100} {
		if _, err := PerUnit(Cost{Compute: 1}, units); err == nil {
			t.Fatalf("PerUnit(units=%d) = nil, want error", units)
		}
	}
}

TestPerUnit 用 math.Abs 比较浮点结果，而不是直接写 got != 200。600 分除以 3 恰好是 200，但换成 100 除以 3 就不会这么整齐，测试应该容忍浮点表示误差。这里的容差是 1e-9，比“分”这个最小单位小几个数量级，不会掩盖真实错误。

TestPerUnitZeroCost 确认零成本是合法输入。新上线的服务在第一个统计周期可能还没有产生账单，返回 0 比报错更符合预期。真正应该报错的是分母，不是分子。

TestPerUnitRejectsNonPositiveUnits 覆盖了 0 和两个负数。测试只断言“有错误”，不绑定错误文案，这样后续调整提示信息不会让测试无故失败。错误文案应该给人看，测试应该盯行为。

运行命令与真实输出

在仓库根目录执行：

cd .local/checks/webapp-lab && go test ./internal/cost/ -run 'TestAdd|TestCostTotal|TestPerUnit' -count=1 -v

一次本机运行的真实输出如下，耗时随机器变化：

=== RUN   TestAdd
--- PASS: TestAdd (0.00s)
=== RUN   TestCostTotal
--- PASS: TestCostTotal (0.00s)
=== RUN   TestPerUnit
--- PASS: TestPerUnit (0.00s)
=== RUN   TestPerUnitZeroCost
--- PASS: TestPerUnitZeroCost (0.00s)
=== RUN   TestPerUnitRejectsNonPositiveUnits
--- PASS: TestPerUnitRejectsNonPositiveUnits (0.00s)
PASS
ok  	webapp/internal/cost	0.499s

五个用例全部通过，退出码为 0。-count=1 关闭测试缓存，确保看到的是本次执行结果；-run 只筛选单位成本相关用例，同包的存储与预算测试没有执行。

小结

单位经济模型的核心不是“把总额除以一个数”，而是先定义分母代表谁的业务问题，再保证分子覆盖了对应的成本范围。分母和归因范围都应该版本化，任何口径变化都要产生新的报表版本，而不是悄悄改写历史趋势。

工程上能做的最有价值的两件事，一是用整数分聚合、把计算误差和口径误差分开，二是让单位成本计算对零分母和负分母直接失败。这两件事不能保证模型正确，但能保证错误不会以“看起来合理”的方式传播。

最后要提醒的是，单位成本是决策输入，不是绩效指标。一旦把它和团队考核绑定，最理性的做法就会变成缩小分子、放大分母，而不是真正降低资源消耗。模型应该帮助团队看清成本来自哪里，而不是逼着大家把数字做小。

判断一个单位经济模型是否可用的最低标准是：随便挑一个异常月份，团队能在半小时内解释清楚分子、分母和归因范围各自发生了什么变化。解释不了，模型就还只是三张拼在一起的报表。

还有一条更朴素的标准：业务方能不能用这个模型回答“如果我明天把价格降 10%，成本会发生什么”。如果答案只能靠重新跑一遍报表，说明模型还没有把固定成本、边际成本和分母变化拆开。好模型不追求预测精确，但必须让假设可以被单独调整。

下一节讨论存储与带宽：它们都是“按 GB 计费”，但一个看保留期，一个看峰值与回源，成本曲线完全不同。

阅读导航：上一节：目录与学习路径 · 下一节：5.2 存储与带宽成本 。

常见错误与边界

• 把总账单除以支付订单，却把免费用户、爬虫和审核成本留在分子里。分母与分子的覆盖范围必须对应同一批业务对象。
• 分母口径随产品改版漂移，却不留版本号。本月“有效会话”和上月不是同一个定义，趋势线就没有解释力。
• 用浮点元累加大量成本。分摊到几十个服务后会出现分级漂移，对账时无法区分计算误差与口径误差。
• 把负数成本塞进聚合层。退款与折扣应在生成成本前冲减，否则 Total 与 PerUnit 的语义会变得含糊。
• 分母为零时返回 0。空时间窗、筛选条件写错都会产生零分母，静默返回 0 会让报表看起来“成本极低”。
• 只报一个单位成本，不报成本结构。总额相同但带宽占比翻倍，说明优化方向已经变了。
• 把案例假设值当成行业基准。每个产品的流量结构、客单价和资源单价都不同，必须用自己的账单重算。
• 用单位成本直接做定价决策，却不区分固定成本与边际成本。闲置容量的成本不会因为多一单而线性增加。