开源云真正解决的问题不是【便宜】,而是【不被锁死】——它把控制权还给你,代价是你得自己养一支队伍;省下的是许可费,加上去的是人的成本。
上一节(利用云服务的注意事项(看不太见的地方))讲的是用别人家的云时,那些看不见的约束。这一节接着往下问一句:如果不想受这些约束,还有别的路吗?
有,而且这条路从云一出现就存在——把云本身也开源。它的思路和第一章 控制大量服务器的机制 讲的自动化是同一个方向:把那些原本靠人做的事,变成一套能自己搭、自己改的系统。 区别只在于——这套系统是你自己的。
一、"云在开源化"是什么意思
通常说的开源,是指软件的源代码公开、可以自由使用和修改。放到云这件事上,它有两层含义:
- 云的构建技术本身开源了:用来把一堆服务器变成资源池、把虚拟机调度起来的那套软件,有开源的实现。
- 用法开源了:你可以下载这些软件,在自己的机房里搭一个私有云——功能上接近公有云,但完全归你管。
这解释了一件事:为什么"私有云"不只是"自己买几台服务器"。真正的私有云需要一整套调度和管理的软件,而 OpenStack 就是这类软件的代名词。
二、OpenStack:把云的能力各管一块
OpenStack 不是单一软件,是一组组件,每个负责一块能力:
| 组件 | 管什么 | 对应的云能力 |
|---|---|---|
| Nova | 计算(虚拟机的生命周期) | 弹性计算 |
| Neutron | 网络(虚拟网络与路由) | 虚拟私有网络 |
| Cinder | 块存储(云硬盘) | 云硬盘 |
| Swift | 对象存储 | 对象存储 |
| Glance | 镜像管理 | 虚拟机镜像 |
| Keystone | 身份与认证 | 账号与权限 |
这张表最值得注意的地方,是"对应"那一列。 它说明:你在公有云上习以为常的那些能力——开虚拟机、划虚拟网络、挂云硬盘、建对象存储——在开源世界里都有对应的实现。
换句话说,公有云和开源自建私有云,做的是同一件事,只是"谁来做、谁负责"不同。 这也是为什么两者会长期并存:功能上可以对齐,但责任归属完全不同。
三、开源省的是许可,不是总成本
| 项目 | 用开源自建 | 用商业云服务 |
|---|---|---|
| 软件许可费 | 0 | 含在服务费里 |
| 需要几个人 | 3~5 人运维团队 | 0.5 人(对接与治理) |
| 五年人力成本 | 约 300 万 | 约 50 万 |
| 五年服务费 | 0 | 约 200 万 |
| 五年合计 | 约 300 万 | 约 250 万 |
| 能改源代码吗 | 能(出问题自己扛) | 不能 |
| 上手时间 | 6~12 个月 | 几天 |
读这张表,两行的对比最说明问题:
第一行:许可费 0。 这是开源最明显的优点,也是它最容易被当成全部优点的原因。
第二行:3~5 人 vs 0.5 人。 这是开源最容易被低估的成本。开源软件不要钱,但它要人——装、调、升、排障、应急,都需要有经验的人。而这些人的稀缺程度,往往比软件本身贵得多。
最后两行则揭示了这条路真正的取舍: 你能改源代码(自由),但出问题时没有人替你兜底、也没有 SLA 可依;上手时间从几天变成几个月。
四、开源真正解决的是"不被锁死"
把上面两层合起来看,结论就清楚了:
开源的定位不是"更省钱的云",而是"更自主的云"。 它承担的功能有两类:
- 掌握控制权:数据在哪、代码怎么跑、什么时候升级,都由你决定。对合规要求极高、或者不愿把命门交出去的场景,这个价值无法用钱衡量。
- 避免依赖单一厂商:包括对特定行业的厂商(比如提供专业软件的公司),开源方案提供了一条替代路径。
而对多数小团队来说,更实际的用法是"混合":用公有云跑业务,只在个别地方用开源组件补上公有云不提供或价格过高的部分。这比"全开源"或"全商业"都更现实。
五、动手 Demo:把两边的账算一遍
# 开源自建 vs 商业云服务:五年总成本
open_source = {"许可费": 0, "人力(3 人 × 5 年)": 300, "服务费": 0}
commercial = {"许可费": 0, "人力(0.5 人 × 5 年)": 50, "服务费": 200}
for name, book in (("开源自建", open_source), ("商业云服务", commercial)):
print("%-8s 五年合计 = %d 万" % (name, sum(book.values())))
print("差额 = %d 万(而且不含上手期的 6~12 个月)"
% (sum(open_source.values()) - sum(commercial.values())))
实跑输出:
==================================================================================================
D12 云计算也在走向开源化:开源省的是许可,不是总成本
==================================================================================================
【一】OpenStack:一套开源组件,把云的核心能力各管一块
组件 管什么 对应的云能力
----------------------------------------------------------------------
Nova 计算(虚拟机的生命周期) 弹性计算
Neutron 网络(虚拟网络与路由) 虚拟私有网络
Cinder 块存储(云硬盘) 云硬盘
Swift 对象存储 对象存储
Glance 镜像管理 虚拟机镜像
Keystone 身份与认证 账号与权限
【二】开源云与商业云:钱从许可费挪到了人的身上
项目 用开源自建 用商业云服务
------------------------------------------------------------------------
软件许可费 0 含在服务费里
需要几个人 3~5 人运维团队 0.5 人(对接与治理)
五年人力成本 约 300 万 约 50 万
五年服务费 0 约 200 万
五年合计 约 300 万 约 250 万
能改源代码吗 能(出问题自己扛) 不能
上手时间 6~12 个月 几天
④ 开源云真正解决的问题不是【便宜】,而是【不被锁死】。
它把控制权还给你,代价是你得自己养一支队伍。
所以小团队的正确用法常常是:用公有云跑业务,
用开源组件补上那些公有云不提供的部分。
读这个输出:第二张表里"五年合计"那一行(300 万 vs 250 万)最容易让人误判——它看起来只差 50 万,好像开源还贵了。 但这 50 万买到的是最后两行写着的东西:能改代码、自己掌握升级节奏、数据不出自己的机房、不受某一家商业条款约束。这笔账的选择依据不是数字大小,而是"这几样东西对你值多少"。
(还有一项没进这张表:上手期的 6~12 个月。这半年到一年里,团队基本不产出别的东西——对急着上线的项目来说,这一项就足以决定取舍。)
六、⚠️ 2026 现状
- OpenStack 仍是主流的开源云基础设施之一,全球用它管理的计算核心规模已达数千万级(官方口径超过 5,500 万核),最新版本仍在按 2026.x 的节奏发布。它的主要用户集中在电信、大型企业、政府与科研——也就是"需要自主可控"色彩最浓的那些领域。
- 开源云的目标变了:从"替代公有云"变成"与公有云配合"。今天常见的架构是开源云管私有部分(需要自主可控的负载),公有云管弹性与溢出部分。这与 2-9 讲的多云策略是同一套思路——开源在这里的角色更像"自主的那一块"。
- "主权云"成了新的推动力。部分国家和地区在采购规范里把开源标准写成了硬要求(例如欧洲一些公共行政部门的虚拟化基础设施规范),这使得开源云在合规场景里的地位比几年前更明确。
- 人才成为主要瓶颈。多份行业观察都指出,熟练的开源云运维人员稀缺、成本高,很多企业最终选择购买"托管版开源云"服务——也就是说,软件开源、运维外包。这个形态很值得注意:它把"开源"的控制权优势和"托管"的省心优势结合了起来。
30 秒实验
问自己一个问题:你们公司的核心数据,如果必须放在自己的机房里,你们能搭出一套够用的私有云吗?
- 如果答案是"能,我们本来就有",那你们已经有这方面的能力积累,可以考虑 2-9 讲的多云/混合策略。
- 如果答案是"不行,没人懂",那么选择开源路的真正门槛不是软件,是人——这也是这张表里"需要几个人"那一行的实际含义。
- 如果答案是"可以买托管版",那你正好走在今天最普遍的那条路上:软件开源、运维外包。
常见误区
-
错误:开源软件免费,所以开源云一定更省钱。——纠正:免费的是许可,付费的是人。Demo 表里开源自建的五年人力约 300 万,商业云服务的服务费约 200 万——"免费"的那一栏是软件,账单的大头在别处。而且这个数字还建立在"你招得到合适的人"这个前提上,现实中往往会更贵。
-
错误:既然开源更自由,那就都自己搭。——纠正:自由是有维护成本的。自己搭意味着你要负责升级、补丁、容量、故障处理,而且没有 SLA 可以追究——出问题时只能自己扛。对多数业务量不大的团队,把这份自由换成稳定的服务,通常是更划算的交易。自由该用在"真的需要自主"的地方,而不是全面铺开。
-
错误:开源云就是公有云的山寨版,功能肯定差。——纠正:两者做的是同一件事,都有对应的能力(Demo 第一张表逐项对应)。差别不在功能的有无,而在"谁负责运行"以及生态的成熟度(可选的产品、服务商、人才)。把开源等同于低配,会让人错过它在合规和自主场景里的实际价值。
-
错误:用了开源就不会被锁定了。——纠正:锁定不只来自许可,也来自习惯和数据。如果你已经围绕某个开源组件的特有用法建立了整套流程和数据格式,换起来一样痛苦。真正降低锁定风险的是"保持可迁移性"——数据能导出、接口尽量标准化、不依赖没有替代品的专有特性。这和 2-9 里"准备能带走"是同一个道理。
自测三问(点开对答案)
1. OpenStack 的那张组件表,最能说明什么? —— 说明**公有云的那些基础能力,在开源世界里都有对应实现**——计算、网络、块存储、对象存储、镜像、认证,逐项对得上。**所以"私有云只是自己买几台服务器"是误解**:真正的私有云需要这一整套调度管理软件,而 OpenStack 就是这个角色的代表。**功能可以对齐,区别在于谁来负责运行。** 2. 为什么 Demo 里"软件许可费 = 0"这一行,不是选择开源的充分理由? —— 因为**许可费只是总成本里的一小块**,而自建会把成本转移到人力上——**3~5 人的运维团队、以及 6~12 个月的上手期**。看总额(300 万 vs 250 万)会发现开源自建并不便宜。**所以决定选开源的理由应该是"需要自主可控",而不是"软件不要钱"。** 3. "托管版开源云"这个形态,为什么值得特别留意? —— 因为它**同时拿到了两边的关键好处**:软件开源意味着**不被单一厂商的产品锁定**(这是开源最初的价值);运维外包意味着**不用自己养一支稀缺的运维团队**(这是自建最大的门槛)。**它实际上承认了两个事实:控制权和运维能力,可以分开获取。** 对多数中小组织来说,这是比"全自建"或"全商业"都更贴合现实的一条路。- ☐ 下一节(2-13 不同提供商使用术语的差异:Amazon EC2、Azure Files)
相关笔记
- 利用云服务的注意事项(看不太见的地方) —— 上一篇:用别人的云时,那些看不见的约束
- 控制大量服务器的机制 —— 把靠人做的事交给系统,开源云也是这个方向
- 云服务的区分使用 —— "准备能带走"与开源配合公有云的思路一致
- 一切尽在云中 —— 组件表里的"能力"就是家族表里的那些层
- 不同提供商使用术语的差异 —— 下一篇:最后讲一个最实际的问题
- ☁️ 云计算 · 索引 —— 全课路线图