波仔
☁️ 第一章 云计算的基础知识
📄 一句话概括

按量收费与扩展性看着是两条特点，其实是同一件事的两面——把固定成本换成可变成本：不用再为峰值买单，也不用再等采购到货。

📝 本节和前面几节的关系

上一篇（1-1）用三个条件划出了"什么算云"，这一篇讲的是为什么值得选云。

三个条件里，第①条（网络可达）今天几乎人人都有，第②条（位置抽象）是运维责任的转移，而第③条（按需自助）带来的好处最直接、也最好算——它就是教材这两条特点的来源：按量收费（用多少付多少）和扩展性（要多少有多少）。所以这一篇可以看成第③条判据的展开。

一、两个特点为什么放在一起讲

教材把它们并列，是因为它们回答的是同一个问题的两个侧面：

两者合起来才是完整的一句：云把"资源"从一件要提前规划几年的事，变成了随时可以取用的事。少了任一半都不成立——只能自助却不能计量，你会不敢用；只能计量却不能自助，你还是要等。

二、按量收费：把固定成本变成可变成本

先看自建的钱是怎么花的。买一台服务器，钱是在第一天花出去的，然后你用它三年。这三年的使用量却是不均匀的：

这意味着你必须按三年里的最高点买硬件，而大部分时间它在浪费。 这叫峰值采购。

云把这条曲线压平了：你按实际用量付钱。峰值那几小时按峰值算，平时按平时算。多花的钱只发生在你真正用到的时候。

这里有个容易被忽略的推论：按量收费真正省钱的地方，不是单价便宜，而是"不用为闲置买单"。云的单位算力单价通常比自建贵，但因为你不再闲置，总账反而可能更低——要不要更低，取决于你的负载波动有多大。负载曲线越平，自建越占优；波动越大，云越占优。

三、扩展性：要的时候马上就有

第二条特点解决的是时间问题。自建扩容要经过一个完整的链条：提需求、审批、比价、下单、到货、上架、装系统、配网络。每一步都在等，加起来的量级是周。

云上这件事变成了一个动作：控制台点一下，或者调一次接口。更进一步，你还可以设一条规则——CPU 连续五分钟超过 70% 就自动加两台——这叫自动伸缩（Auto Scaling），响应时间是秒级。

这个差别不只是"快一点"，它改变了你能做的生意：

注意扩展性也是双向的：能扩，也要能缩。缩容的价值常被低估——自建的机器不能退，业务萎缩时你手里握着一堆吃电的废铁；云上关掉实例，下个月账单立刻变小。教材把它和扩容并列，其实是在说同一件事：资源的规模应该跟着业务走，而不是跟着采购周期走。

四、按量收费也有代价

这两个特点不是白给的。写下来是为了让你在算账时不被销售口径带着走：

五、动手 Demo：把两个特点算成数

下面这个 Demo 用一组具体数字走完两条特点，并给出扩容的时间对比。

# 场景：负载平均 4 核、峰值 12 核，峰值时长约占 10%
peak, avg, ratio = 12, 4, 0.10
self_capacity = peak                      # 自建必须按峰值买
cloud_usage = avg * (1 - ratio) + peak * ratio   # 云按实际用量计费
print("自建容量 =", self_capacity, "核")
print("云上等效用量 =", cloud_usage, "核")
print("云上占自建的比例 = %.1f%%" % (cloud_usage / self_capacity * 100))

实跑输出：

==================================================================================================
D2 云服务的特点：按量收费与扩展性，都能算成数
==================================================================================================
  场景：某业务的负载【平均 4 核、峰值 12 核】，峰值时长约占 10%。

  【一】自建：机器必须按峰值买，平时就是浪费
  项目                              计算                              结果
  ------------------------------------------------------------------------------------------
  按峰值配置的机器                  12 核 × 100% 时间                 12.0 核·时/时
  实际平均要用                      4 核 × 100% 时间                  4.0 核·时/时
  浪费掉的比例                      (12 − 4) / 12                     66.7%

  【二】云：按实际用量付费，峰值那 10% 才按 12 核算
  计费核数                          4 × 90% ＋ 12 × 10%               4.8 核
  相比自建的容量                    4.8 / 12                          40.0%
  一年省下的算力成本                1 − 40.0%                         60.0%

  【三】要扩容时，两条路各自要多久
  做法                              步骤                              耗时
  ------------------------------------------------------------------------------------------
  自建扩容                          采购审批→下单→到货→上架           6 ~ 8 周
  云上扩容                          控制台点一下 / 调一次 API         1 ~ 3 分钟
  云上自动伸缩                      设好规则，负载到线就加            秒级

  ④ 按量收费买的是【用多少付多少】，扩展性买的是【要的时候马上就有】。
     这两条合起来才是教材说的【云服务最大的特点】——它们解决的是同一件事：
     把【为峰值买单】换成【为用量买单】。

读这个输出：最值得琢磨的是 66.7% 和 40.0% 这两个数。自建浪费掉的 66.7% 不是谁管理不善，它是峰值采购的数学结果——只要你的负载有波动，这个浪费就必然存在。而云上的 40.0% 也不是凭空便宜，是因为那 10% 的峰值时间你照样按 12 核付了钱。所以真正决定划算与否的，是你负载曲线的形状，而不是云或自建本身。

六、⚠️ 2026 现状

教材讲的两条特点没变，但今天有了更细的方式：

30 秒实验

打开手机计算器，做一道你自己的题：

  1. 写下你经手过的一个系统，估一个"全年最忙的那一天"的用量（并发也好、数据量也好，随便一个单位）。
  2. 再估一个"平时用量"。两者相除，得到峰均比。

峰均比如果是 1.2 这种接近平的，自建更容易划算；如果是 3 以上，光"不为峰值买单"这一条就足够说明问题。

常见误区

  1. 错误：云的单价更便宜，所以一定更省。——纠正：云省的从来不是单价，是闲置。按单位算力比，云通常比自建贵。云的价值在于你只为用到的那部分买单——所以负载波动越大越划算，平稳满载时反而可能不如自建。

  2. 错误：扩展性就是"随时能加机器"。——纠正：扩展性包含"缩"这一半，而且缩的那一半更难。加机器是花钱，谁都会；能做到自动缩容、及时停掉不用的资源，才真正拿到了弹性带来的成本优势。只扩不缩，账单会以另一种方式惩罚你。

  3. 错误：按量收费意味着成本可预测。——纠正：按量收费带来的是"可低"，不是"可预测"。用量涨了账单就涨，而且如果不做治理，闲置资源会悄悄累积。想在预算里说清成本，需要额外做两件事：给资源打标签分账、给实验环境设自动关机策略。

  4. 错误：等业务规模大了再上云，效果更好。——纠正：规模越大，迁移越难，而且前期省下的那笔浪费已经花掉了。云的优势恰好出现在方向不明、需求会变的阶段——这恰恰是业务早期。所以教材把"新系统导入"和"系统升级"列为上云的典型契机（1-3 展开），而不是等业务稳定之后。

自测三问（点开对答案） 1. 一个业务平时用 4 核、峰值 12 核，为什么说自建浪费了 66.7%？ —— 因为**采购是按峰值做的**：机器买 12 核的，而平均只用 4 核，差出来的 8 核在大部分时间空转。用 (12 − 4) ÷ 12 ＝ 66.7% 算出来的**是"闲置比例"，不是"成本浪费比例"**——两者接近但不完全相等（闲置的机器照样耗电、占机位）。这个数的作用是提醒你：**波动越大的业务，自建的隐性浪费越高。** 2. 云上算出来是自建的 40%，那是不是说明云一定便宜 60%？ —— **不是**。这里的 40% 只是"**等效算力用量**"之比（4.8 核 vs 12 核），它算的是**容量**，不是**钱**。要换成钱，还得乘上两边各自的单价——而云的单价通常更高。**正确的读法是**：云把"需要准备的容量"压到了 40%，但每单位容量的价格更贵，**最终谁便宜取决于这两个数谁的影响更大**。 3. 为什么"能缩容"比"能扩容"更能体现云的价值？ —— 因为**扩容解决的是"机会"，缩容解决的是"浪费"**。扩容让你不错过增长的生意，但如果只扩不缩，资源会永久留在高位——**等于把自建那种"买了就退不掉"的毛病又背回来了**。缩容才是把"按量收费"真正兑现的那一步：业务的规模跟着走，成本才跟着走。

相关笔记