交付镜像与端口
提供 Dockerfile 或现成镜像，声明 1 个对外端口与健康检查路径 /healthz，其余交给平台。
服务 / 价格档位
5 类计算形态，按真实消耗计费
展开每一项可看到计费单位与省钱前提。所有价格均为公开挂牌价示例，实际以用量阶梯为准；把「闲置率」当作第一成本指标，通常比砍单价更有效。
S1通用弹性实例 Web 服务、API 网关、轻量任务队列0.32 元/核时
按秒计费、不足 1 分钟按 1 分钟结算；夜间无流量时缩容到 0 副本，次日按冷启动窗口恢复。适合流量曲线呈明显峰谷的潮流网络型业务。
计费粒度秒级，最小 60s
适用闲置率< 35%
建议副本最小 1、上限 30
S2突发性能实例 构建流水线、爬虫、批处理0.19 元/核时
基线 20% CPU 积分，突发可短时打满。适合白天低谷、凌晨集中跑任务的场景；若持续负载 > 55%，建议改选通用型以免积分耗尽被限速。
基线性能20% vCPU
积分回补24 点/小时
限速阈值持续负载 > 55%
S3对象存储分层 镜像、日志、备份、静态资源0.008 元/GB·月
标准 / 低频 / 归档三层按访问热度自动下沉。30 天未访问自动转低频，180 天未访问转归档，取回按次计费——把「可能要用」的冷数据成本压到标准的 1/6。
下沉规则30 / 180 天
取回费用0.02 元/GB
建议压缩日志 gzip 后省 62%
S4托管数据库 MySQL / PostgreSQL 主从0.47 元/核时
含自动备份、7 天时间点回滚与只读副本。只读副本按需开启，读多写少业务可把 70% 查询分流，主库规格随之下降一档。
备份保留7 天 PITR
只读副本按需，0.31 元/核时
省费点分流 70% 读请求
S5边缘函数 静态站点、鉴权、A/B 分流0.0009 元/万次
无请求时零成本，冷启动目标 ≤ 90s 全链路（含镜像拉取）。适合把鉴权、重定向、灰度分流从常驻服务中剥离，常驻实例可再降 1–2 个副本。
免费额度每月 100 万次调用
执行上限单次 50ms
建议拆分鉴权 / 分流 / 埋点
工作流程步骤
从交付代码到成本可视，四步走完
设定成本护栏
填写月预算上限与缩容策略：最小副本 1、CPU 触发阈值 65%、夜间 23:00–07:00 缩容至 1 副本。
约 10 分钟灰度与压测
先切 10% 流量观察 24 小时，看 P95 延迟与账单曲线；通过后再全量，异常可一键回滚上一版本。
1 个工作日成本复盘与调参
每周看闲置率、冷启动次数、存储下沉比例三项指标，按 5% 步长微调副本上下限，避免一次性大改。
每周 20 分钟
图文混排特写
一条线背后的调度逻辑
网页布局上，LineCloud 把「成本」当作一等公民：控制台首屏只保留三条信息——当前闲置率、本月已花、预计月末账单。色彩搭配上仅用一条主色线与少量暖色高亮，避免图表花哨导致误读；动画设计只做淡入上浮与数字滚动，不干扰读数。
- 调度器每 15 秒采样一次队列深度，副本增减以 5% 为步长，防止抖动式扩缩容。
- 冷启动预热池常备 1 个轻量副本，命中后首包时间从 3.2s 降到 0.9s，成本仅增加约 6%。
- 日志默认 gzip 压缩后入低频层，实测 1GB 原始日志压到 380MB，存储费下降 62%。
- 跨可用区双活只对核心服务开启，非核心走单区 + 每日快照，容灾成本可省掉约 43%。
- 用户体验优化优先做在缓存层：静态资源命中率提到 92% 后，回源与计算费用同步下降。
常见问题 FAQ
上线前最常被问到的 5 个成本问题
按秒计费真的比包月便宜吗？
取决于闲置率。当日均 CPU 利用率低于 35%、且每天有 8 小时以上低谷时，按秒计费通常比包月省 30%–45%；若负载长期高于 70%，包月预留折扣更划算。建议先跑 7 天监控再决策。
缩容到 1 副本，会不会影响可用性？
单副本期间无冗余，建议至少保留 2 副本并把健康检查间隔设为 5 秒、失败 3 次触发替换。对可用性要求高的核心服务，可只在夜间低峰缩到 2 副本，而非 1。
冷启动 90s 是端到端吗？
是含镜像拉取、依赖安装、健康检查通过的端到端目标。把镜像层数压到 8 层以内、体积控制在 300MB 以下，通常能把冷启动稳定在 60s 上下。
存储分层会不会让取回变慢？
低频层取回通常秒级，归档层可能需要 1–5 分钟。把「可能被随时读取」的数据留在标准层，只把备份与历史日志下沉，就能兼顾成本与响应。
怎么发现账单异常？
设置三道护栏：日花费超过近 7 日均值 1.5 倍告警、单实例 CPU 连续 6 小时低于 5% 提示缩容、存储月增超过 200GB 时通知。三道护栏能覆盖多数意外支出。
解决方案对比
三种上线方式，成本与代价摆在一起看
| 方案 | 适用规模 | 月成本估算（8 核 16G 等效） | 运维投入 | 弹性能力 |
|---|---|---|---|---|
| 自建物理机 | 长期稳定、负载 > 70% | ¥2,400 起（含机柜与带宽） | 高，需专人值守 | 弱，扩容以周计 |
| 包年包月云主机 | 负载波动小、可预测 | 约 ¥1,980 | 中，需自行配置监控 | 中，分钟级 |
| LineCloud 按量 + 缩容 | 峰谷明显的潮流网络型业务 | 约 ¥1,120 | 低，护栏策略自动执行 | 强，秒级扩缩 |
| 全托管 Serverless | 事件驱动、请求稀疏 | 约 ¥860（含冷启动损耗） | 极低 | 强，但有执行上限 |
结论：把「闲置率 > 35%」作为切换信号。闲置率高、峰谷明显时，按量 + 自动缩容的性价比最稳；长期满载则预留实例更省。对比前先量出自己的真实利用率，避免用峰值规格去比价。
客户评价
省下来的钱，被花在了哪里
-38%「把夜间副本从 6 个压到 2 个，账单直接掉下来。真正花时间的是先量清楚哪些服务可以缩，线条式的成本面板帮了大忙。」
-27%「日志和镜像做了冷热分层，存储费用少了近三成。取回速度也在可接受范围内，备份恢复测试一次通过。」
-44%「把鉴权与分流拆到边缘函数后，常驻实例少了两个。极简界面降低了误操作率，新人半天就能看懂成本结构。」
实用指导清单
六个可立刻执行的成本优化要点
01先量闲置率，再谈单价
连续采集 7 天 CPU 与内存利用率，算出日均值与 P95。闲置率 = 1 − 日均利用率。低于 35% 优先做缩容，而不是换更便宜的实例规格，后者常因性能不足反而增加副本数。
02缩容策略用 5% 步长
扩容触发设 CPU > 65% 持续 3 分钟，缩容设 CPU < 25% 持续 15 分钟，每次增减不超过总副本的 5%。步长太小会抖动，太大则易引发雪崩，配合 10 分钟冷却窗口更稳。
03把镜像压到 300MB 以内
用多阶段构建、合并 RUN 指令、清理缓存，层数控制在 8 层内。镜像体积每降 100MB，冷启动约省 8–12 秒，直接减少缩容到 0 时的等待成本。
04存储按 30 / 180 天分层
标准层放热数据，30 天未访问转低频，180 天未访问转归档。日志入仓前先 gzip，实测可压到原体积的 38%；归档数据保留 2 份异地副本，兼顾合规与成本。
05只对核心服务开双活
把服务分成核心 / 一般 / 边缘三档：核心跨可用区双活，一般单区 + 每日快照，边缘随流量弹性。实测该分档方式比全量双活省约 43% 的容灾开销，且不影响主链路 SLA。
06设三道账单护栏
日花费 > 近 7 日均值 1.5 倍即告警；实例 CPU 连续 6 小时 < 5% 提示缩容；存储月增 > 200GB 时通知复核。护栏只做提醒不自动停机，避免误伤线上流量。