约 10 分钟5 张卡

云计算

云计算是一种通过网络按需获取共享计算资源的服务模式。使用者可以申请和释放计算、存储、网络或应用能力，不必为每次资源变化都采购设备、等待人工部署。

对后端开发者来说，重点是分清自己取得了什么能力、还需要维护什么。租一台虚拟机、部署应用到托管平台、直接使用在线软件，面对的接口和责任不同；使用云服务，也不会自动解决应用的数据一致性、权限和故障恢复问题。

1. 面试核心

先记住这几条，再读正文

云计算以按需自助、网络访问、资源池化、快速弹性和可计量服务组织资源。虚拟机和容器是实现资源隔离与运行应用的技术，单独部署它们不等于已经提供云服务。卡 · 按需资源服务
IaaS 提供基础资源，PaaS 提供应用部署和运行平台，SaaS 提供可直接使用的软件。区别在于使用者控制哪一层、服务方管理哪一层，不是产品名称里有没有“云”。卡 · 服务模型
公有云、私有云等部署形态说明云基础设施供谁使用、怎样组织；它们与 IaaS、PaaS、SaaS 是不同维度。公有云不意味着客户数据公开，私有云也不要求设备一定在自己的机房。卡 · 部署形态
共享责任需要落实到具体服务。托管基础设施不等于托管业务正确性，使用者仍要管理自己负责的数据、账号权限、应用代码和配置。卡 · 共享责任
公有云可以降低初期资源准备成本，利用弹性应对变化；选择时也要评估平台约束、故障恢复、持续费用和迁移成本。资源可扩容不等于应用能无限扩展。卡 · 后端应用的选择条件

2. 按需资源服务

卡 · 你怎样理解云计算？

云计算改变的是资源交付和使用方式。以一个需要运行后端应用的团队为例：团队可以通过控制台或 API 创建实例、配置网络、申请存储，再在不需要时释放资源。底层设备仍然存在，只是申请者不必直接管理每一台物理设备。

NIST SP 800-145 用五个特征描述这种模式：

特征	对使用者意味着什么
按需自助	使用者能自行申请计算或存储能力，不必每次都由服务方人员手动开通
广泛网络访问	通过网络和标准访问方式使用服务，支持不同类型的客户端；不要求资源向公共互联网开放
资源池化	服务方把资源组织成池，按需求分配给多个使用者；使用者通常选择区域等范围，不直接指定每个物理位置
快速弹性	根据需求较快地增加或释放资源，部分过程可以自动完成
可计量服务	记录、监测和报告相应资源的使用量，支持管理和费用核算

弹性是资源随需求扩大或缩小的能力，不是无限供给的承诺。可用容量、账号配额、实例启动时间以及应用自身的瓶颈，都会影响扩容结果。增加十个应用实例，如果请求仍争抢同一条数据库记录，吞吐量就不一定按实例数增长。

可计量也不等于只有一种收费方式。按使用量收费、周期订阅或容量承诺，都可能出现在具体服务中；是否便宜，要结合实际使用量和所包含的能力判断。

2.1 虚拟化和容器处在哪一层？

虚拟化把底层资源抽象为可分配、可隔离的运行环境；虚拟机是其中一种形式。容器则用操作系统提供的隔离和资源限制机制运行进程，Linux 容器共享所依赖的 Linux 内核。两者的隔离方式见容器原理。

这些技术可以支撑云服务，但还需要资源调度、网络与存储管理、身份权限、计量等能力，才能形成面向使用者的资源交付过程。自己在电脑上启动一个容器，只能说明运行了一个容器，不能据此判断已经建立云平台。

反过来，云服务也不要求向使用者暴露虚拟机。例如托管应用平台可以隐藏实例的创建过程，使用者只提交应用和运行配置；基础设施内部如何隔离，是另一个层面的问题。

3. 服务模型

卡 · PaaS 是什么？

服务模型描述云服务交付到哪一层。NIST 的三种基本模型是 IaaS、PaaS 和 SaaS：

模型	交付的主要能力	使用者主要控制什么	一个后端应用的例子
IaaS，基础设施即服务	计算、存储、网络等基础资源	操作系统、部署的软件、数据，以及允许配置的网络规则	创建虚拟机，自己安装运行时并维护应用进程
PaaS，平台即服务	平台支持的应用部署与运行环境	应用代码、业务数据，以及平台开放的运行配置	提交应用，由平台安排运行环境并提供相应管理接口
SaaS，软件即服务	服务方运行的完整应用	软件允许的用户设置、组织配置及自己的数据使用	直接使用在线协作软件，无需自己部署该软件

这里的“控制”不等于获得底层设备的所有权。IaaS 使用者可以管理虚拟机里的操作系统，但物理服务器、机房和基础设施仍由服务方管理。

3.1 PaaS 省掉了哪些工作？

PaaS 把应用下方的一部分平台维护工作交给服务方。开发者可以围绕应用部署、配置和运行状态工作，不必自行安装与维护服务契约覆盖的底层操作系统和平台组件。

相应地，应用必须适应平台提供的能力。例如平台可能限制可用运行时、进程生命周期、本地文件保存方式或单次任务执行时间。需要长期运行的后台任务，就要确认平台是否支持相应执行方式，不能仅因为代码在自己的电脑上能运行，就判断它在平台上也有同样的行为。

平台提供弹性能力时，应用仍需要处理状态和并发。比如多个实例共同接收附件上传，应把需要共享和持久保存的内容放到适合的存储服务中；对象接口及其一致性边界见对象存储。

3.2 一个系统可以同时使用多种模型吗？

可以。应用可能运行在 IaaS 虚拟机上，使用托管数据库，并接入 SaaS 身份或协作服务。分析责任时，要逐项看服务提供了什么，不能因为其中一个组件属于 PaaS，就认为整个系统的运维都由服务方负责。

实际产品也不总能仅凭名字准确归类。例如“托管 Kubernetes”可能只托管控制平面，也可能进一步管理工作节点；应用配置、镜像和访问权限的责任又要单独确认。判断时查看具体管理范围，比给产品强行贴一个分类标签更有用。

4. 部署形态

卡 · 公有云、私有云与混合云怎样区分？

部署形态描述云基础设施的使用范围与组织方式。它回答“供谁使用”，服务模型则回答“提供什么能力”。

形态	含义	需要避免的误解
公有云	云基础设施面向公众提供使用	不意味着任何人都能读取其他客户的数据；访问仍受权限和隔离约束
私有云	云基础设施供一个组织专用，可服务该组织内多个部门	可以由第三方管理，也可以部署在组织外；不等于普通自有机房的别名
社区云	供具有共同需求的一组组织专用	不是单纯因为几个客户购买了同一家公有云，就成为社区云
混合云	两个或更多独立云基础设施通过技术连接，使数据或应用能在它们之间迁移、协作	不是只要同时买了两个账号，就自动具备混合云能力

一个组织可以在私有云里提供 IaaS，也可以在公有云基础设施上构建 PaaS。两个维度可以组合，不能把“公有云还是 PaaS”当成一组选项。

如果应用一部分留在私有云，一部分使用公有云，连接本身不会消除分布式问题。网络延迟、身份映射、数据同步和故障时的访问路径，仍然需要设计；不能默认跨环境操作会自动成为同一个事务。

5. 共享责任

卡 · 应用部署到托管平台后，还需要负责哪些事情？

共享责任是服务方与使用者分别承担自己控制范围内的工作。服务方负责了底层基础设施，不代表使用者可以忽略应用漏洞、账号泄露或错误的访问策略。

以 AWS 的公开责任说明为例，EC2 这类 IaaS 服务中，客户负责来宾操作系统及其更新、应用软件和安全组配置；服务方负责运行云服务的基础设施。Azure 的责任说明同样把客户数据、身份和配置作为需要明确客户责任的内容。这些例子说明如何拆分责任，不能替代具体服务的管理约定。

对于一个后端应用，可以按实际操作逐项判断：

问题	需要确认的责任
谁更新操作系统和运行时？	是自己维护虚拟机，还是平台托管了相应层次；自己打包的依赖是否仍需更新
谁能读取业务数据？	谁配置账号、角色、对象权限与应用授权，凭据如何管理
数据误删后怎么恢复？	是否提供备份或版本功能，是否启用，保留多久，谁发起和验证恢复
服务故障后应用还能工作吗？	服务的可用性范围、应用依赖、冗余部署和故障恢复路径分别是什么

例如，云数据库提供副本，并不能推出它能恢复任意时间点的误删除。需要历史备份还是时间点恢复、可以接受丢失多少数据，要回到实际目标判断，见高可用与容灾。

同样，基础设施可用性承诺不等于整条业务链路的可用性。应用配置错误、第三方依赖故障或发布失败，都可能使用户无法完成请求。