波仔
☁️ 第二章 构建系统优先考虑云服务的时代
📄 一句话概括

术语差异不是小事——它决定了你查文档、找案例、跟人沟通时能不能对上话；办法只有一个：先记住【能力】，再记名字——能力是通的，名字是各家的。

📝 本节和前面几节的关系

这是第二章的最后一节。前面十二节讲的是概念、层次、账目、注意事项——都是"该怎么想"。这一节讲一个非常实际的问题：该怎么把这套知识用出去。

教材把它放在最后一步是有道理的。因为前面讲的所有判断（这一层该包多少、什么该放私有云、灾备做到几级），最终都要落到某个具体服务上——而落到具体服务的第一步，就是在它的界面和文档里找到对应的那个东西。找不到名字，前面想得再清楚也执行不下去。

一、同一个东西，三个名字

先看一组对照，就明白问题在哪了：

能力 AWS Azure Google Cloud
虚拟机 Amazon EC2 Virtual Machines Compute Engine
对象存储 Amazon S3 Blob Storage Cloud Storage
块存储 Amazon EBS Managed Disks Persistent Disk
文件存储 Amazon EFS Azure Files Filestore
托管数据库 Amazon RDS Azure SQL Database Cloud SQL
容器编排 Amazon EKS AKS GKE
无服务器 AWS Lambda Azure Functions Cloud Functions

这张表要看的是"能力"那一列——它才是稳定的那一列。

右边三列的名字都是各家的品牌名，而且命名风格完全不同：AWS 偏爱缩写（EC2、EBS、EFS、EKS 只差一个字母），Azure 偏爱描述性名称（Virtual Machines、Managed Disks），Google 偏爱通用词组（Compute Engine、Cloud Storage）。记名字的性价比很低，因为它们会变、也不通用；记能力的性价比很高，因为它是稳定的。

二、几个最容易想当然的词

还有一个更容易踩的坑：同一个词在不同语境下含义不一样。

术语 可能指 注意
实例 一台虚拟机 不是【例子】
区域 Region 一整个地域 不等于【可用区】
可用区 AZ 区域内互相独立的机房群 不等于【区域】
快照 某一时刻的磁盘状态 不等于备份，快照与磁盘同处一份存储
桶 Bucket 对象存储的顶层容器 各家叫法不同，概念一样

排序从易到难：前两行是"词义误解"（把技术词当日常词理解），后两行是"概念混淆"——它们更危险，因为混淆的两个东西听起来都很对。

"快照不等于备份"这一条特别值得记。 快照记录的是某个时刻的状态，但它通常和原磁盘存在同一份存储里——如果那份存储坏了，快照跟着一起没。所以快照是"后悔药"（误删能找回），不是"救命药"（灾难能恢复）。 要能救命的，得是异地、独立的一份。（这和 2-10 讲灾备等级时说的"备份≠灾备"是同一个道理的另一个侧面。）

三、怎么办：先记能力，再记名字

既然名字会变、也不通用，那就该按下面的顺序来：

第一步：用能力提问，不用名字提问。

不要问"EC2 怎么配自动伸缩"，要问 "这台云上的虚拟机怎么配自动伸缩"。前一个问题只在 AWS 的文档里有答案，后一个问题在任何一家都能找到。

第二步：记住每家的"命名风格"，而不是逐个背名字。

记住风格能让你在看到一个陌生名字时猜对它大概是什么——这比背名字实用得多。

第三步：对照着读文档。

学一家的某项服务时，顺手找出它在你熟悉的另一家里叫什么。比对方更能加深印象，也能让你在换环境时不至于重新学一遍概念。

四、动手 Demo：把三家的名字对齐

# 用"能力"作行标，用"厂商"作列标
caps = ["虚拟机", "对象存储", "块存储", "文件存储", "托管数据库"]
aws  = ["EC2",    "S3",       "EBS",    "EFS",       "RDS"]
az   = ["Virtual Machines", "Blob Storage", "Managed Disks",
        "Azure Files", "Azure SQL Database"]
# 换个厂商时，只有名字那一列要重学，能力那一列始终不变
print("能力项 %d 个：%s" % (len(caps), "、".join(caps)))
print("要重学的只有名字，共 %d 个" % len(aws))

实跑输出：

==================================================================================================
D13 不同提供商使用术语的差异：同一件事，三个名字
==================================================================================================
  【一】七种能力，在三家的叫法

  能力            AWS                   Azure                 Google Cloud
  ----------------------------------------------------------------------------------
  虚拟机          Amazon EC2            Virtual Machines      Compute Engine
  对象存储        Amazon S3             Blob Storage          Cloud Storage
  块存储          Amazon EBS            Managed Disks         Persistent Disk
  文件存储        Amazon EFS            Azure Files           Filestore
  托管数据库      Amazon RDS            Azure SQL Database    Cloud SQL
  容器编排        Amazon EKS            AKS                   GKE
  无服务器        AWS Lambda            Azure Functions       Cloud Functions

  【二】几个最容易想当然的词，实际含义不等于字面

  术语              可能指                          注意
  ------------------------------------------------------------------------------------------
  实例              一台虚拟机                      不是【例子】
  区域 Region       一整个地域                      不等于【可用区】
  可用区 AZ         区域内互相独立的机房群          不等于【区域】
  快照              某一时刻的磁盘状态              不等于备份，快照与磁盘同处一份存储
  桶 Bucket         对象存储的顶层容器              各家叫法不同，概念一样

读这个输出：第二张表的最后两行最值得留意。"快照不等于备份"和"桶在各家的叫法不同"这两条，恰好说明了术语问题的两种类型——前者是同一个词被赋予了技术含义，容易按日常理解错（以为快照=备份）；后者是同一个东西有很多名字，容易找不到（不知道对象存储的容器叫什么）。这两类问题的应对方法也不同：前者靠抠定义，后者靠按能力检索。

五、⚠️ 2026 现状

六、本章到此

第二章从"为什么默认要用云"，一路走到了"用的时候要注意什么"。

回头看，这十三节其实在回答四个层面的问题：

一句话收束这一章：第一章讲的是"云是什么"，这一章讲的是"用云的时候，判断力该花在哪几个地方"——层次、位置、合同、名字，这四件事想清楚了，剩下的都是操作。

30 秒实验

打开任意一家云服务商的官网，点进"产品"列表页，然后做两件事：

  1. 不看名字，只看图标和一句话描述——试着把每个产品归到你熟悉的那几类能力里（计算、存储、网络、数据库、AI）。你会发现大部分都能归进去。
  2. 再找三个你不认识的产品名——然后去搜索"这个相当于别家的什么"。你会发现大部分都能找到对应物。

做完这两步，你会得到一个结论：云产品看着成百上千，实际上的能力种类是有限的。 记住那少数几种能力，比记住上千个名字划算得多。

常见误区

  1. 错误：术语只是叫法不同，不影响实际使用。——纠正：它直接影响搜索和沟通的效率。用错词会导致查不到文档、问不对问题、甚至按错误的心智模型去配置。"快照当备份用"就是一个典型后果——名字上的混淆会导致实际操作上的漏洞。

  2. 错误：那就把三家的名字都背下来。——纠正：性价比太低。产品名字会变（改名、合并、下线都很常见），而且每家的产品数量都在几百以上。正确做法是记住"能力"和"每家的命名风格"——风格能让陌生名字变得可猜；能力能让你在任何一家找到等价物。

  3. 错误：快照和备份差不多，有快照就不用额外备份了。——纠正：这是本节里最值得记牢的一条。快照通常与磁盘存在同一份存储中，它能防的是误删、误改这类"操作失误"，防不了存储本身出问题。真正的备份需要满足两个条件：异地存放、独立于源数据。如果你的容灾方案里只有快照，那么你防住的只是最轻的那一类事故。

  4. 错误：学一家会了，换一家就要从头学。——纠正：概念层的东西是通用的，要重学的只是名字和各家特有产品的用法。换环境时更该做的是先做一次对照（这个能力在新家叫什么、有哪些等价服务和限制），而不是从文档第一页开始读。这份对照工作做一次，后面每次换都省一遍。

自测三问（点开对答案） 1. 为什么"先记能力，再记名字"这个方法，比直接背产品名更耐用？ —— 因为**能力是稳定的，名字是会变的**。同一个能力各家名字不同，同一家也可能改名；而"虚拟机、对象存储、块存储、数据库"这些能力种类，十年下来基本没变。**记住能力，你就能在任何一家的产品列表里找到对应物；记住名字，你只是记住了某个时点的某家叫法。** 2. "快照不等于备份"这条，为什么比"实例不是例子"更值得重视？ —— 因为后者只是**词义误解**，弄清楚了就没影响；前者会**直接导致容灾方案的漏洞**——你以为自己有备份，实际上快照和原始数据在同一份存储里，那场灾难来的时候两个一起没。**前者是知道不知道的问题，后者是做了但没用的问题**，后者的代价大得多。 3. 换一家云服务商时，最省时间的第一步是什么？ —— 是**先做一次术语对照**：把你现在用到的能力逐项列出来，再查每一项在新家叫什么、有没有等价服务、有哪些不一样的限制。**这一步做完，你就有了自己的迁移地图**；不做这一步，就得在文档里一遍遍碰到不认识的词、再挨个去查。**这也是这一节把它放在章末的原因——前面十二节想清楚的事，最终都要靠这一步落到具体操作上。**

相关笔记