2.1 计算服务：VM、容器与函数

2.1 计算服务：VM、容器与函数

本节摘要：计算服务是云上所有应用的发动机，核心形态有三种：虚拟机（VM）提供完整的操作系统环境，容器提供轻量可移植的应用包，函数计算（FaaS）提供按事件触发的即用即弃代码。本节对比三种形态在控制力、资源利用率、启动速度、计费方式上的差异，并给出"什么时候选哪种"的判断方法，让你在云厂商的"实例"与"函数"之间不再犹豫。

核心问题

阅读完本节，你应当能够：

1. 说出虚拟机、容器、函数计算三种计算服务各自的"交付单元"是什么。
2. 对比三种形态在隔离性、启动速度、计费方式上的差异。
3. 解释 Hypervisor、容器引擎、调度器、镜像仓库在计算服务中的角色。
4. 针对"跑数据库、跑 Web 服务、跑图片处理"三种负载，各给出合理的计算选型。

一、问题与直觉

任何一个云上应用，最终都要落到"算力"上——总得有台机器在跑你的代码。但"机器"这个词在云上已经被拆成了好几层：你可以租一台完整的虚拟机，可以交一个容器镜像，也可以干脆只交一段函数代码。

为什么会有这么多选择？因为"跑代码"这件事在不同场景下的最优解不同。一个要跑十年、负载稳定的财务系统，和一个每天被调用几万次、每次只跑几百毫秒的图片压缩任务，需要的资源形态完全不一样。前者适合一台稳定的虚拟机，后者用函数计算几乎零成本。

把三种形态理解成一个连续谱：虚拟机给你一间毛坯房，容器给你一套标准间，函数给你一个"随叫随到、用完即走"的工位。 控制力递减，省心程度递增。你的任务决定你该站在这条谱线的哪个位置。

二、核心原理

2.1 虚拟机：云上的"整机租赁"

虚拟机（Virtual Machine，VM）是最早也最直观的计算服务形态。你在云控制台上选一个实例类型（多少核、多大内存、什么磁盘），平台就给你一台带完整操作系统的虚拟电脑。你可以登录进去装任何软件、配任何服务，跟你自己买服务器几乎没有差别，只是它跑在别人的数据中心里。

虚拟机的核心组件是 Hypervisor（虚拟机监控器），它负责在物理机上切出隔离的虚拟资源，并在多个虚拟机之间调度。虚拟机的好处是隔离性强、兼容性好——你想跑什么系统、什么软件都行；坏处是资源占用高（每台都带一套完整操作系统）、启动慢（分钟级）。

2.2 容器：打包即标准件

容器（Container）解决的是虚拟机的"笨重"问题。它不装操作系统，只打包"应用 + 运行时依赖"，多个容器共享宿主机内核。因此容器镜像小、启动快（秒级）、资源利用率高，同一台物理机上能比虚拟机多跑几倍的应用。

容器的关键组件包括：容器引擎（负责创建和管理容器，提供运行时环境，如 Docker、containerd）、镜像仓库（存储和分发容器镜像）、调度器（决定容器该跑在哪台节点上）。容器最大的工程价值是"一次构建，到处运行"——开发环境、测试环境、生产环境跑同一个镜像，消除了"在我机器上好好的"这类经典问题。

2.3 函数计算：连机器都不露面

函数计算（FaaS，Function as a Service）把抽象推到极致：你只提交一段函数代码，平台负责在事件触发时把它跑起来，跑完即回收。你完全不用关心"跑在什么机器上"，甚至不必关心有没有机器。

函数计算的核心机制是事件驱动：API 请求来了、文件上传了、消息队列有消息了，都会触发函数执行。平台自动弹性伸缩，并发涨了自动多拉几个实例，空闲了自动回收，按实际执行时间和次数计费。省心是真的省心，但代价是：冷启动延迟（首次调用要初始化运行环境）、超时限制（单次执行通常有上限）、不适合长连接和有状态服务。

三、工程实践要点

3.1 三种形态对比

3.2 关键组件与选型对照

⚠️ 常见坑：把"虚拟机数量"当绩效指标——开了十台 2 核小虚拟机，不如一台 8 核大虚拟机省心。机器数量不等于算力，资源利用率才是该盯的指标。

💡 关键直觉：选型先问"这个服务有状态吗、执行时间有多长、流量规律吗"。有状态长驻选虚拟机或容器，无状态短任务选函数计算，三者常常并存于同一个项目。

3.3 混合使用的现实

真实项目很少只用一种计算形态。一个典型的云上应用可能是这样的：Web 服务跑在容器里（Kubernetes 编排，方便滚动更新），数据库跑在虚拟机上（需要稳定的 IO 与配置控制），图片缩略图生成用函数计算（突发负载、短任务）。计算选型是组合题不是单选题，关键是让每种负载都落在它最舒服的形态上。这既是架构师的功力，也是云弹性价值真正兑现的地方。

四、计算服务的计费小账本

理解计费模型，选型才算入门。虚拟机通常是按"实例规格 × 运行时长"计费，无论 CPU 利用率多低，只要开着就按整台付费；容器在云上常以"集群节点（底层虚拟机）"计费，加上镜像存储费用；函数计算按"调用次数 + 执行时长（GB 秒/内存）"计费，闲置零成本。

所以"函数计算一定最便宜"是错的：对于一天 24 小时高频调用的服务，按调用计费可能比包一台虚拟机贵得多。计费结论必须建立在真实负载曲线上，不是拍脑袋选"听起来省钱"的形态。这也呼应了第 3 章会讲的成本管理——先有计量，才有优化。

五、常见问题（FAQ）

Q1：裸金属服务器算什么？

裸金属（Bare Metal）不经过虚拟化层，把物理机整台租给你，硬件直通、性能无损耗，适合高性能计算、高频交易这类对延迟和硬件控制极敏感的场景。它是计算服务谱系里"最左边"的形态，比虚拟机控制力更强、也更贵。

Q2：Auto Scaling 是什么？

自动伸缩（Auto Scaling）不是一种计算形态，而是云平台的一项能力：根据负载指标（如 CPU 利用率、请求数）自动增删计算实例。它让"弹性"从口号变成默认行为，是虚拟机/容器形态的标准配套，常与负载均衡配合使用。

Q3：容器和函数能一起用吗？

能，而且很常见。典型的"函数优先"架构是：核心业务逻辑拆成函数按事件执行，长驻的网关、监控、管理组件放容器里。第 5 章会讲到 Serverless 与 Kubernetes 的融合趋势，两者正在互相靠近。

Q4：怎么判断该用容器还是虚拟机？

一个经验法则：如果你需要"自己的操作系统、内核级配置、或要装非容器化的旧软件"，用虚拟机；如果应用已经是"镜像化、无状态、可横向扩展"的形态，用容器。数据库、老系统往虚拟机放，新开发的 Web 服务往容器放，是大多数团队的默认答案。

六、从实例规格看懂厂商产品页

打开任何一家云厂商的计算服务产品页，你都会看到一排排"实例规格"，比如 2 核 4GB、4 核 16GB、GPU 实例、高主频实例。规格背后其实是几个变量的组合，看懂它们，选型就不抓瞎。

第一是 CPU 与内存配比。通用型实例 CPU 与内存配比适中，适合常规 Web 服务；内存型实例内存占比高，适合缓存、大数据处理这类吃内存的负载；计算型实例 CPU 占比高，适合渲染、编码、科学计算。第二是存储类型，本地盘快但易失，云盘持久但性能依赖网络，生产环境通常选云盘并做快照备份。第三是 GPU，图像渲染、深度学习训练需要它，普通 Web 服务用不上，别为用不上的特性付费。

实例规格与计费强相关：按量付费灵活、包年包月便宜、竞价实例最便宜但可能被回收（适合可中断的批处理任务）。第 3 章成本管理会展开讲这几种计费方式。这里只需要记住一个原则：规格是需求的对齐，不是虚荣的对齐——先算清应用的真实资源画像，再选实例，能省下相当可观的账单。

另外，无论选哪种计算形态，都要留意平台的能力边界。虚拟机有单机规格上限，容器集群有节点配额，函数有并发与超时上限。架构设计时把这些"天花板"画出来，比遇到瓶颈再补方案要省心得多。这也是为什么资深工程师常说：看云文档先看"limits"（限制）章节，那才是真实契约。

还有一个新手常忽略的点：计算服务不是孤立的，它天然依赖网络与存储。 一台裸虚拟机配好操作系统，没有虚拟网卡和云盘就是"无法联网的孤岛"；反之，网络与存储的规格（带宽、IOPS）直接决定计算实例的实际表现。所以在真实部署里，计算、存储、网络三个货架往往是一起下的单——第 2.2、2.3 两节会补齐另外两块拼图。

本章回顾

• 虚拟机：交付完整操作系统，隔离强、兼容好、启动慢、占用高，适合数据库与遗留系统。
• 容器：交付应用镜像，共享内核、轻量快速，适合微服务与 Web 应用。
• 函数计算：交付函数代码，事件驱动、按用量计费，适合短小突发任务。
• 关键组件：Hypervisor 管虚拟机，容器引擎管容器，调度器管任务分配，镜像仓库管分发。
• 选型顺序：有状态长驻选 VM/容器，无状态短任务选函数，常三者混用。
• 计费真相：函数计算并非永远便宜，按负载曲线算账，闲置才划算。
• 裸金属：无虚拟化层的物理机直租，性能极致、价格也极致。

算力有了，数据往哪放？下一节讲存储服务——对象、块、文件三种仓库，各放各的货。