波仔
☁️ 第四章 构建云服务的技术
📄 一句话概括

云里的技术能跨厂商搬来搬去，靠的是一批公开标准——它们分两种：法定标准（先定规范大家照做，如 TCP/IP、802.1Q）和事实标准（先有实现、用得多了成为标准，如 Kubernetes、S3 接口）；对使用者来说，实用价值只有一条：事实标准也是标准——只要有多家实现，你就留住了退路。

📝 本节和前面几节的关系

前面十几节讲的全是【具体技术】（虚拟化、容器、编排、网络、存储、IaaS、PaaS）。这一节把它们收束到一条主线上：这些技术为什么能拼在一起、又为什么能在厂商之间搬？——因为它们背后有共同的标准与社区。

这也是整章的方法论：本章标题是【构建云服务的技术】，而这一节说的是这些技术不是一家公司的发明，而是很多组织共同协商出来的结果。理解了这一点，才能理解 2-12 讲【开源化】时那句【不被锁死】的底气从哪来。

一、为什么需要标准

先看没有标准会怎样：

场景 没有标准 有标准
换云服务商 应用要重写 换配置就能跑
团队招人 会某家产品的人才能用 会标准的人都能用
引入新工具 每家一套对接方式 按同一套接口对接
备份与迁移 导出格式只有原厂认 通用格式，谁都能读

最后一行最能说明问题：数据能不能【带得走】，取决于它是不是用了通用格式。这也是选型时最该问的一个问题——我的数据能以什么形式离开这里？

二、法定标准与事实标准

教材这一节的关键词是【通用化】，落地形式就是标准。标准分两类：

类型 怎么来的 例子
法定标准（de jure） 先定规范，大家照做 TCP/IP、HTTP、802.1Q（VLAN 标签）
事实标准（de facto） 先有实现，用得多了成为标准 Kubernetes、Docker 镜像格式、S3 接口

两者的差别不在效力，在【谁先动】：

所以【事实标准也是标准】这句话有前提：当它背后有一个中立的基金会、有多家实现时，它才具备标准的效果；如果只是一家公司的产品接口，那它仍然是那家公司的规则。

三、动手 Demo：谁在定这些规则

看到什么算成功：

==================================================================================================
【Demo 19】通用化与标准化：谁在定这些规则
==================================================================================================
  云里的技术能跨厂商搬来搬去，靠的是一批公开标准。
  教材在 4-19 说的是【通用化】，落地形式就是这些组织和规范：

  标准 / 组织         是什么                    管住的东西
  --------------------------------------------------------------------------------------------
  OCI                 开放容器倡议              容器镜像格式与运行时接口
  CNCF                云原生计算基金会          Kubernetes、Prometheus 等项目
  OpenInfra           开放基础设施基金会        OpenStack、Kata Containers 等
  IETF / W3C          互联网标准组织            TCP/IP、HTTP、HTML
  Open Service Broker 服务代理接口              应用怎么挂数据库、消息队列
  --------------------------------------------------------------------------------------------
  标准分两种，作用不一样：

    法定标准（de jure）＝先定规范，大家照做
      例：TCP/IP、HTTP、802.1Q（4-11 的 VLAN 标签）
    事实标准（de facto）＝先有实现，用得多了成为标准
      例：Kubernetes、Docker 镜像格式、S3 接口

  实用价值在于：事实标准也是标准。
  只要有一个接口被所有厂商实现了，你在 A 家写的代码就能搬到 B 家——
  这就是 4-7 说的【多云计算的容器】能成立的底层原因。
  选技术时，优先选有公开接口、有多家实现的，就是给自己留退路。

读结果：

30 秒实验

打开任意一个常见的配置文件（比如一个 Docker Compose 文件、一个 Kubernetes YAML，或者随便找一个 API 文档），做一件事：

看它里面有多少【英文缩写定义】（比如 image:、apiVersion:、kind: —— 这些都是某一套标准的字段名）。

做完这个你会明白：你每天都在用各种标准，只是不觉得。而且这些字段名之所以长得一样、在不同工具里都能用，正是因为有一群人把它们写进了规范里。所谓【通用化】，就是这种【到处都一样】的感觉的来源。

常见误区

  1. 错误：事实标准就是【用的人多的产品】，跟标准是两回事。——纠正：关键看有没有【多家独立实现】。Kubernetes 用得多，而且每一家云都有自己的实现版本，任何一家退出都不影响规范继续存在——它具备标准的效果。而一个只有原厂能提供的接口，用的人再多也仍然是那家公司的规则。所以判断依据是实现者的数量与独立性，不是使用者的数量。

  2. 错误：标准会限制创新，所以技术公司都不喜欢标准。——纠正：标准划的是【接口】，不是【实现】。它规定【你对外要长这样】，但里面怎么做完全自由——所以各家仍可以在性能、可靠性、成本上竞争。真正被标准限制的是【另起一套不兼容的接口】这种既不利于用户、也不产生技术价值的做法。 而且从商业上看，参与标准制定的公司往往获得更大话语权，所以主流厂商都在积极投入。

  3. 错误：既然有标准，那换云服务商应该很容易。——纠正：能搬的是【标准化程度高的那一层】，搬不动的还有很多。数据放在哪（各家托管数据库的导出方式不同）、网络怎么连（私有连接是厂商特有的）、用了哪些托管服务（消息队列、AI 接口）——这些都会让迁移变贵。所以标准的作用是把迁移成本从【重写】降到【改写】，而不是降到零。多云的现实做法仍然是【把可搬的放上层】，这一点在 4-7 里已经说过。

  4. 错误：这些社区和基金会跟我一个使用者没关系。——纠正：你的技术选型风险，取决于它们的健康程度。一个项目背后的治理是否中立、贡献者是否多样、有没有商业公司在持续投入——这些决定了它三年后还在不在。所以看一个开源项目时，除了看功能，还要看它的治理结构。这也是 2-12 讲开源选型时那笔账的一部分。

自测三问（点开对答案） 1. 【事实标准也是标准】这句话的前提是什么？ —— 前提是**它有多家独立的实现，并且有一份公开的规范**。满足这两条，它就具备标准的效果（你可以依赖它、可以换实现、可以预判它不会随意改变）。**不满足时，它只是【一个流行的产品】**——你可能仍然想用它（因为好），但**不能因为【它是行业标准】而认为风险低**。所以这句判断句的准确用法是：**先看实现者，再说它是不是标准。** 2. 为什么说【标准限制创新】是误解？ —— 因为**标准限制的是【接口】，而接口之外全是自由**。举个具体例子：容器的镜像格式被标准化了，但**镜像怎么构建得更快、怎么存得更省、怎么跑得更安全**——这些全都是开放竞争的空间。所以标准实际上是**把竞争从【互相不兼容】推向了【性能和体验】**，对用户是好事。真正被限制的是**想通过不兼容来锁住用户的策略**。 3. 选一个开源项目时，为什么【治理结构】要算进评估项？ —— 因为**它决定了项目的长期风险**。一个由单一公司完全控制的项目，**可能在某天改变许可、改变方向、甚至停止投入**（这在开源历史上发生过多次）；而有中立基金会、多家公司共同投入的项目，**即使某一家退出，项目也能继续**。**对使用者来说，这意味着你的技术栈不会因为别人的商业决定而被迫重来**——这笔风险不写在功能表上，但它真实存在。

相关笔记