服务成本账:一个服务一个月烧多少钱
你写的那个服务,一个月花公司多少钱?八成研发答不上来 —— 平时只盯功能和性能,账单从没看过。但"会算成本"恰恰是从「只管把功能跑通」到「能扛一摊事」的分水岭:能上线、能稳、还得算得清这摊东西值不值这个钱。
说来有点惭愧,成本这块我也是开始补服务端之后才认真算的——平时写功能,真没盯过账单。这篇就把这笔账一起算明白:成本由哪几块构成、云怎么计费、怎么估一个服务一个月烧多少、钱常白烧在哪、以及怎么省。配套一个零依赖的小工具(月成本估算计算器),跑一下就能看到钱具体花在哪几项上。
一、成本由哪几块构成
一个跑在云上的服务,花的钱不是一个数,而是六个口袋同时在漏。把它们拆开,账才算得清:
- 计算(CPU / 内存):跑你代码的服务器或容器。一台 2 核 4G、4 核 8G 的实例,按规格 × 时长收费 —— 这是大多数服务最直觉的一块成本。
- 存储(磁盘 / 对象存储):数据库的数据盘、日志盘,以及放图片、视频、备份、用户上传文件的对象存储。按"存了多少 GB × 多少个月"收费。
- 流量 / 带宽:数据进出机房要花钱,尤其是公网出口(数据从你的服务发到公网用户)。这一项最容易被低估,后面会看到它常常是大头。
- 数据库(云 RDS):托管的关系型数据库(MySQL / PostgreSQL 等)。云厂商替你管主从、备份、高可用,所以它比自己搭一台数据库贵,但省心。
- 缓存(云 Redis):托管的内存缓存。规格越大、内存越多越贵。
- 日志(存储 + 检索):日志量大得惊人,而且不光占存储,按关键词检索 / 建索引还要额外收费。一个没设保留期的服务,日志账单能悄悄爬到吓人。
还有一些零散项:负载均衡(SLB / ALB)、CDN、消息队列、监控告警平台、对象存储的请求次数费(不只是存储费,读写次数也计费)等。本文聚焦上面六块主干,把账的骨架搭起来。
这六块拎清楚,后面所有的估算和降本,都是围着它们转。
二、云是怎么计费的
同样一台实例,用什么付费方式买,价格能差出一倍。先搞懂三种主流模型,再看计费维度。
三种付费方式
| 付费方式 | 怎么收 | 适合什么 | 取舍 |
|---|---|---|---|
| 按量付费 | 用多久算多久(按秒 / 小时),随时开随时关 | 流量波动大、临时任务、测试环境、不确定要不要长期用 | 单价最贵,但不用就不花钱 |
| 包年包月 | 一次性买一段时间(月 / 年),到期续费 | 长期稳定运行的核心服务 | 比按量便宜不少,但买了就锁住,关了也退不了 |
| 预留实例 / 节省计划 | 承诺用满 1~3 年,换一个大折扣 | 长期且用量可预测的基本盘 | 最便宜,但锁定期最长,押错了就浪费 |
一句话选型:波动用按量,稳定用包年/预留。
实践里常常组合用:基本盘(任何时候都得有的那几台)用包年或预留锁住低价;高峰时段临时多出来的那部分,用按量弹性补 —— 既省钱又扛得住峰值。
常见的计费维度
不同资源,按不同的"量"收费,知道维度才知道账怎么涨上去的:
| 资源 | 计费维度 | 大意 |
|---|---|---|
| 计算实例 | 实例规格 × 时长 | 几核几 G,开了多久 |
| 块存储 / 对象存储 | 存储量 GB × 月 | 存了多少,存了多久 |
| 公网流量 | 流量 GB | 出口走了多少 G(进一般免费、出收费) |
| 对象存储请求 | 请求次数 | 读写各算一次,海量小文件别忽视 |
| 数据库 / 缓存 | 规格 × 时长(+存储) | 托管实例的规格和时间 |
| 日志 | 存储 GB + 检索量 | 存多少,还查多少 |
一个反直觉点:公网流量"出"收费、"进"通常免费;而且同地域内网互通往往免费或极便宜,跨公网就贵。这条规律直接决定了后面"大文件走 CDN、服务间走内网"的降本招式。具体价格一律以云厂商官网价目表为准(阿里云、AWS 官网都有公开的计算器和价目表),本文所有数字都是为了讲清思路的示例估算。
三、估算一个服务:走一遍账
光说不练没体感。我们挑一个典型的对外 API 服务,从头到尾把账估一遍。强调:下面每个数字都是示例,目的是讲清「估算思路」,不是让你记住具体价格。
假设:一个对外 API 服务,峰值 1000 QPS(每秒 1000 个请求)。
第一步:估计算费。 关键是先知道"单台实例能扛多少 QPS"—— 这个数要靠压测得出,跟业务逻辑轻重直接相关。假设压测下来单台稳定扛 200 QPS:
所需实例数 = 峰值 QPS ÷ 单台 QPS,向上取整 = 1000 ÷ 200 = 5 台
注意要向上取整:4 台只能扛 800,顶不住峰值,必须 5 台。再留点冗余余量更稳妥,这里先按 5 台算。假设单台月单价 ￥300(示例),计算费 = 5 × 300 = ￥1500/月。
第二步:加上其余各项(全是示例值):
| 成本项 | 估算 | 月费用(示例) |
|---|---|---|
| 计算 | 5 台 × ￥300 | ￥1,500 |
| 数据库 RDS | 中等规格主从 | ￥1,200 |
| 缓存 Redis | 中等规格 | ￥600 |
| 公网流量 | 5000 GB × ￥0.8/GB | ￥4,000 |
| 对象存储 | 2000 GB × ￥0.12/GB | ￥240 |
| 日志 | 800 GB × ￥0.7/GB | ￥560 |
| 合计 | 约 ￥8,100/月 |
这张表最值得盯的,是占比。 把它画成占比,公网流量一项就占了近一半(约 49%),反而比计算、数据库都贵。这不是编出来的极端例子 —— 凡是对外吐数据多的服务(图片、视频、大 JSON、文件下载),公网流量都极容易成为头号开销。
而如果是个低流量的内部小服务(峰值 100 QPS,流量很小),账完全是另一副样子:一台实例就够,大头反而落在"固定包月"的数据库上,月成本可能就一千出头。
所以估算的价值不在那个总数,而在那张占比图:它告诉你这个服务的钱主要烧在哪,降本该先动哪一块。配套 demo 把这两个场景都跑了出来,你能一眼看到大头随服务形态怎么迁移。
这套思路对 AI 时代的服务同样成立,只是多了一块新的大头:GPU 算力。推理服务的成本结构里,GPU 实例往往一骑绝尘,贵到让传统的 CPU / 流量都显得是零头 —— 但"先拆项、再看占比、盯着大头降本"的方法论,完全一样。
四、常见的"白烧钱"
算明白账之后,你会发现很多钱根本没花在刀刃上,纯属白烧。这几种最常见:
- 闲置 / 超配实例:申请的时候图省事拍了个 8 核 16G,实际 CPU 常年 5% 利用率 —— 多出来的规格全是钱。超配比不够更隐蔽,因为服务跑得好好的,没人会去查。
- 测试 / 预发环境忘关:开发联调时拉起一套环境,事后忘了关,按量计费的它就 7×24 一直烧。一堆"僵尸环境"是团队成本里最冤的一笔。
- 日志爆炸、没设保留期:DEBUG 级日志全量打、永久留存,日志量滚雪球,存储费 + 检索费一起涨。绝大多数日志过了一两周就再没人看,却一直占着钱。
- 大文件没走 CDN:图片、视频、安装包直接从你的服务走公网出口吐给用户 —— 上一节看到了,公网流量极贵。同样的文件交给 CDN,既快又便宜(CDN 流量单价通常远低于源站公网出口)。
- 存储没设生命周期、冷数据没归档:三年前的日志、早就不看的备份,还躺在最贵的标准存储里。这些冷数据本该归档到便宜得多的归档存储,却因为没人管理一直按标准价计费。
- 该弹性的没弹性:明明白天高、半夜低,却按峰值规格 7×24 常备 —— 半夜那些用不上的实例,钱照烧。
这几条的共同点:不是功能出了问题,是没人管钱。服务跑得好好的,账单却在悄悄漏。
五、降本思路
把上面的"白烧"反过来,就是降本的招式。按收益从高到低排:
- 按需弹性伸缩:根据负载自动增减实例数,高峰多开、低谷自动缩。白天 5 台、半夜 2 台,半夜那几台的钱就省下来了。这是收益最大、也最该先上的一招。
- 合理规格 + 压测定容:别拍脑袋超配。靠压测知道单台真实能扛多少,按实际负载选规格,再留合理冗余 —— 而不是"先买大的图安心"。
- 用缓存挡住数据库:热点数据进 Redis,大量读请求不再打到数据库,数据库的规格就能选小一档 —— 缓存不只是为了快,也是为了省下数据库那笔钱。
- 冷数据归档 + 存储生命周期:给对象存储设生命周期规则 —— 比如 30 天后自动从标准存储转到低频访问、90 天后转归档存储。日志设保留期,过期自动删。让冷数据待在便宜的地方。
- 大文件走 CDN、服务间走内网:静态资源、下载文件全部上 CDN,把昂贵的源站公网出口换成便宜的 CDN 流量;服务之间的调用尽量走内网 / 同地域,避开公网计费。
- 稳定部分用包年 / 预留:基本盘锁低价,弹性部分用按量补 —— 付费方式本身就是一种降本。
- 监控 + 成本预算告警:这是托底的一招。给每个服务 / 项目设成本预算,超阈值就告警。很多白烧之所以烧很久,就是因为没人盯着账单 —— 把账单变成一个会主动报警的指标,问题才暴露得早。
降本不是一味抠到最省,而是让每一块钱花得有数:知道花在哪、为什么花、能不能更省。该花的(高可用、冗余、稳定性)别省,白烧的(闲置、超配、冷数据占贵存储)一分别留。
六、一张表:成本项 → 怎么省
把全文收进一张表,照着这张表去翻自己的服务,大概率能找到能省的地方:
| 成本项 | 计费大致逻辑(示例) | 怎么省 |
|---|---|---|
| 计算(实例) | 规格 × 时长 | 弹性伸缩、合理规格、稳定部分用包年/预留 |
| 数据库 RDS | 托管规格 × 时长(+存储) | 加缓存挡读请求 → 数据库选小一档;清理无用数据 |
| 缓存 Redis | 内存规格 × 时长 | 按真实热点数据量选规格,别一味买大 |
| 公网流量 | 出口 GB × 单价 | 大文件走 CDN;服务间走内网/同地域;压缩响应 |
| 对象存储 | 存储 GB × 月(+请求次数) | 设生命周期:冷数据转低频/归档;清理无用文件 |
| 日志 | 存储 GB + 检索量 | 设保留期、调日志级别、采样;过期自动删 |
| (通用) | —— | 关僵尸测试环境;设成本预算告警,让账单主动报警 |
名词解释
- QPS(Queries Per Second):每秒处理的请求数,衡量服务的吞吐压力,是估算实例数的起点。
- 按量付费:用多少算多少(按秒/小时),随时开关、不用不花钱,单价最高。适合波动大、临时性的负载。
- 包年包月:一次性买一段时间(月/年)的使用权,比按量便宜,但买了就锁定。适合长期稳定运行的服务。
- 预留实例 / 节省计划:承诺用满 1~3 年换大折扣,最便宜但锁定期最长。适合用量可预测的基本盘。
- vCPU(虚拟 CPU):云实例分配的虚拟 CPU 核数,和内存一起决定实例规格与单价(如 2 核 4G、4 核 8G)。
- 公网流量 / 内网流量:数据走公网出口收费(且通常只对"出"收费),同地域内网互通往往免费或极便宜 —— 这条规律决定了很多降本招式。
- CDN(内容分发网络):把静态资源缓存到离用户近的边缘节点,加速访问;其流量单价通常远低于源站公网出口,是大文件分发的降本利器。
- 对象存储:存图片、视频、备份、文件等非结构化数据的服务(如 S3、OSS),按存储量 GB·月 + 请求次数计费。
- RDS(关系型数据库服务):云厂商托管的关系型数据库(MySQL/PostgreSQL 等),替你管高可用与备份,省心但比自建贵。
- 冷数据 / 热数据:经常被访问的是热数据,很少访问的(旧日志、旧备份)是冷数据。冷数据应归档到便宜存储。
- 生命周期规则:给存储设的自动转换/删除策略,如"30 天后转低频、90 天后归档、365 天后删除",让冷数据自动待到便宜的地方。
- 弹性伸缩(Auto Scaling):根据负载自动增减实例数量,高峰多开、低谷自动缩,是计算降本最有效的手段。
- 成本预算告警:给服务/项目设定费用阈值,超出即告警 —— 让账单成为一个会主动报警的可观测指标。
配套 demo:backend-notes/04-cost/cost-demo —— 跑一下:把一个服务的成本拆成计算 / 数据库 / 缓存 / 公网流量 / 对象存储 / 日志六项,打印月成本明细表 + 总额 + 各项占比,跑了"小服务"和"中等服务"两个场景,一眼看到大头随服务形态怎么迁移(单价均为示例值,以云厂商官网为准)。
本文属《研发都要懂的事》· 研发视野专题。完整代码与系列在 GitHub · backend-notes。
评论（0）
登录后参与评论。
还没有评论，来抢沙发吧。
