1.4 费用构成与成本预估

架构定稿那天，负责人问了我一个无法回避的问题：“这套东西每个月要花多少钱？”我没办法立刻给出数字，只能先把费用构成拆开：哪些产品按分钟计费、哪些按存储量计费、哪些按流量计费。搞清楚计费维度，成本预估才有意义。这一节不编造具体价格，只把各部分的计费逻辑和我们这种小机构的用量量级摆出来，方便你照着自家情况估算。

各产品的计费维度

同一门课，不同维度的消耗差别很大：上课本身主要消耗 TRTC 时长，课后复习主要消耗 CDN 流量，而录制视频只要不删就一直占着 COS 存储。这三笔账要分开算，省钱的空间也藏在其中。

计费维度里还有一个容易踩的坑：有些维度是“峰值”计费，有些是“累计”计费。比如 IM 的日活看的是当天进过群的人数，而峰值群成员数看的是某一时刻的同时在线数，两个数字可能相差好几倍。做预估的时候要把“每天来多少人”和“同时在线多少人”分开估，不然预算很容易做小。

小机构的月成本量级

我不在书里写具体单价，一来价格以官网页面为准，二来每个人的用量结构不同。下面只按班级规模给出量级表述，方便你做相对粗的预算评估。

判断自己落在哪一档，最简单的办法是先量两个数：每天同时在线的学生数，和每周回放的总观看时长。这两个数基本决定了费用的大头在哪里。我们机构常态是第二档，暑期会短暂冲到第四档。

还有一个经验：不要只看当下的规模，要按半年后的目标做预估。我们第一版预算按一档做的，结果学期中途加了两个班，TRTC 时长和 IM 日活都翻了一倍。预留百分之三十到五十的缓冲，比频繁调整预算从容得多。

旺季人多、淡季人少的弹性

这套架构最让我满意的一点是成本天然有弹性。不上课的时候，TRTC 不产生时长，IM 日活归零，只剩云服务器的固定开支和 COS 里逐渐累积的录制文件。机构的学习周期又是明确的：学期内课程密集，寒暑假是回放高峰，节假日几乎没量。比起提前包一组固定服务器应付峰值，按量计费的模式让每个月的花销曲线和业务曲线大体同频，对现金流的压力小得多。

不过弹性不等于可以放任不管。有两类成本是“你不处理它就一直涨”的：一类是 COS 里的录制文件，只进不出，老的回放没人看却一直占着存储；另一类是 CDN 流量，缓存策略没配好时，热门回放会反复回源拉取，流量费白白多花一截。

弹性也要求监控跟上。云监控的账单指标我每周看一次，重点对比上课时长和回放流量的比例。有一阵子回放流量占比突然升高，排查发现是机构把公开课视频挂到了首页做推广，引来一批未登录访问。加鉴权之后流量回落到正常区间。这类异常如果靠月底看出账单才发现，哭都来不及。

省钱的两个注意点

第一是录制文件的生命周期。我的做法是给存储桶配生命周期规则：新录制文件放常用的标准存储，超过一定时间自动转为低频存储，长期无人观看的再进一步沉降，确实没人看的就定期清理。视频文件占存储的大头，这条规则每月能省下一笔不小的钱。具体规则怎么配，我会在 4.2 节展开。

第二是 CDN 缓存策略。回放视频是典型的“新热旧冷”：刚上完课那几天几乎全班都要看，热度过后就只有零星点播。把缓存放得足够久、把回源压缩到最低，热门回放的流量绝大部分就能由缓存扛住。防盗链也要配上，我们的回放链接曾被爬过一次，那个月流量异常拉高，后来加了鉴权才堵住。这些细节在 4.3 节细讲。

再补一条小经验：云服务器这一项虽然固定，但也能省。业务服务平时负载很低，我把排课、鉴权这些非实时逻辑和课堂状态服务放在同一台机器上，上课高峰期靠监控观察负载，确认没有瓶颈再维持现状。机器数量永远跟着监控数据走，而不是跟着“感觉不够”走。

成本预估表怎么用

成本预估不是一次性动作，而是每月一做的常规动作。我的流程是三步：第一步把上月的账单按产品列出，和预估表对比；第二步找出偏差最大的那一项，搞清楚是用量结构变了还是预估假设错了；第三步更新下个月的预估。半年下来，预估和实际的误差从百分之三十压到了百分之十以内，负责人对预算也越来越有数。预估的本质是把“钱花哪了”变成可讨论的问题，而不是一笔糊涂账。

几个常见的预算误区

第一个误区是只算上课的钱。很多人估成本只估音视频时长，忘了回放流量这个大头。我们机构回放流量长期占总成本的三分之一以上，因为学生看回放的次数比上课还多——复习、补课、考前突击，全靠回放。第二个误区是低估存储的累积效应。每周几十节课的录制文件，一年累积下来是个不小的数字，从第一天就该规划存储分层。第三个误区是把促销价当长期价。开通时的折扣终究会到期，长期预算要按标准价做，促销期省下来的钱当作意外之喜。

这三个误区我都踩过，也都是从账单里一点点学回来的。成本管理没有巧办法，就是每月看、每月比、每月调。

最后给一个可操作的起步建议：上线第一个月，把账单导出来做一次逐项标注，搞清楚每一笔钱对应哪个业务动作（这节课、这次回放、这天的在线学生）。这个动作只要做一次，后面所有成本讨论都有了共同语言。对我们这种小机构，成本透明本身就是竞争力——同样的预算，知道钱花在哪里的机构才能把每一分都花在学生身上。

关于价格本身，最后再强调一次：本书不写具体数字，因为价格会调整、套餐会变动，写死数字只会误导读者。判断贵不贵的正确姿势是打开官网按当前价格算一遍自己的用量，再结合每月账单慢慢修正。我把这件事当成长期功课：先粗估、再跟踪、后优化，三步循环走一年，成本结构就完全透明了。

给负责人汇报的成本话术

技术上想清楚是一回事，让机构负责人点头是另一回事。我最后用三句话说服了他：第一句，这个平台不上课就不花钱，淡季没有固定包袱；第二句，每笔钱都能对应到具体业务，账单看得懂；第三句，存储和流量这两个大头都有明确的优化手段，而不是无底洞。小机构的决策者并不需要精确到小数点的预算，需要的是“可控感”——知道钱为什么花、能不能停、能不能省。这三句话背后，其实分别对应着弹性计费、成本归因和持续优化三件事，本节前面几段都是在为这三句话做技术注脚。汇报出去之后，预算当场就批了。

还有一点决定值得记录：我们不做预付包年。小机构现金流是生命线，按量付费虽然单价略高，但保留了随时调整的自由，可以把省下的钱投在内容和师资上。等用量稳定一年、量级确实够大之后，再考虑阶梯或包年的优惠方式也不迟。钱是活的，人不该被付费方式捆住。

做最后一层风险提示：成本预估里不要忘了开发与调试的消耗。联调阶段反复进房、压测阶段模拟并发、早期学员体验课，这些都会产生真实计费。我在预算表里单列了一项“开发与压测”，虽然占比不高，但把它显式写出来，团队在调试时就不会大手大脚地开房间。压测也有省的办法：先用小规模并发验证逻辑正确性，只在最终验收时跑一次全量压测，既省钱又能拿到需要的数据。

这一节到这里，第一篇也就收尾了。下一篇我们正式开始 TRTC 的接入实战，从开通服务和鉴权配置讲起。

成本这件事，前期预估宁可粗一点也不要漏维度，实际跑起来之后再用监控数据逐月修正。第 5 篇会专门做一次成本复盘，把各产品占比和优化效果摊开来看。想深入了解云产品计费组合的，可以读 《腾讯云实战清单》；存储与流量管理可以参考 《家用 NAS 服务器指南》 中对存储分层的思路；如果你想直接看监控怎么盯住这些成本指标，《数据看板实战》 给了我不少启发。续费与扩容的入口我会放在第 5 篇的成本复盘里，那里结合实际数据说更合适。

延伸阅读

• 《腾讯云实战清单》：计费方式与资源组合
• 《家用 NAS 服务器指南》：存储分层与容量规划
• 《数据看板实战》：成本指标的可视化跟踪