1.1 远古时代：计算资源的稀缺与共享#

要理解云计算的起源，得先回到计算资源极度稀缺的年代。

1960年代，一台 IBM System/360 大型主机造价高达数百万美元，只有大型企业和科研机构才能负担。为了最大化利用这些昂贵的机器，分时系统（Time-Sharing System） 应运而生。MIT 的 CTSS（Compatible Time-Sharing System，1961年）和 Multics（1969年）是早期代表。多个用户通过哑终端轮流使用同一台主机，每人”租用”一段计算时间。这其实已经有了云计算的影子：资源池化、按需分配、多租户共享。

计算机科学先驱 John McCarthy 在1961年麻省理工学院百周年庆典上预言：“计算将来某天可以像电话一样，成为一种公共设施（utility）。” 这句话，比云计算的真正到来早了整整四十年。

1.2 个人电脑时代：计算资源的分散与浪费#

1980—90年代，个人电脑（PC）的普及让计算资源”飞入寻常百姓家”。但随之而来的是新的问题：每个企业都要自建 IT 基础设施。IDC 时代物理服务器的平均利用率通常只有 5%~15%（数据来源：McKinsey & Company，2009年报告 Clearing the Air on Cloud Computing），大量计算资源在闲置状态中白白消耗电力。一旦业务高峰来临，提前三到六个月采购的服务器往往还没到货，业务已经扛不住了。这种成本高、效率低、响应慢的模式，是云计算要解决的根本矛盾。

1.3 虚拟化革命：云计算的技术基础#

进入 2000 年代，服务器虚拟化技术逐渐成熟，这成为现代云计算的重要技术基础。

虚拟化技术允许在一台物理服务器上运行多个虚拟机，每个虚拟机拥有独立的操作系统和资源，从而显著提高硬件利用率。以 VMware 为代表的企业推动了商用虚拟化技术的发展，而开源虚拟化项目 Xen 和 Kernel-based Virtual Machine（KVM）则在互联网公司中得到广泛应用。

通过虚拟化，数据中心可以将计算资源抽象为统一的资源池，并根据需求动态分配计算能力。这一能力成为后来 弹性计算（Elastic Computing） 的技术基础。

1.4 互联网浪潮：催生云计算的土壤#

1990年代末到2000年代初，互联网泡沫催生了大量互联网公司，这些公司有一个共同特点：流量波动极大，难以预测。一家电商网站，平日访问量可能只有高峰期的十分之一，但为了应对高峰，不得不按峰值配置服务器。泡沫破裂后，大量服务器被闲置，这反而成了云计算的起点。

Amazon 就是在这个背景下走向云计算的。2002年，Amazon 内部推行了著名的”API Mandate”（API 强制令），要求：

• 所有团队必须通过标准化 API 暴露能力；
• 不允许直接访问内部服务；
• 违反规定者，一律开除。

这一改革迫使 Amazon 将内部服务模块化、平台化，为后来的云平台奠定了架构基础。2006 年，Amazon 正式推出 Amazon Simple Storage Service（S3） 和 Amazon Elastic Compute Cloud（EC2），允许开发者通过互联网租用存储和计算资源。现代云计算由此正式进入商业化阶段。

1.5 云计算的爆发：2006—2016#

Amazon Web Services (AWS) 的成功很快引发了整个行业的跟进：

• 2008年：Google 推出 App Engine（PaaS 的早期形态）
• 2010年：Microsoft 推出 Azure
• 2010年：OpenStack Foundation 推动的 OpenStack 开源项目启动，使企业能够构建自己的私有云
• 2011年：美国国家标准与技术研究院（NIST）发布云计算定义标准 SP 800-145，明确了云计算的五个核心特征：
  • 按需自助服务
  • 广泛网络访问
  • 资源池化
  • 快速弹性扩展
  • 可计量服务
• 2013年：Docker 开源，容器技术进入主流视野
• 2014年：Google 开源 Kubernetes，容器编排格局从此确立
• 2015年：CNCF（云原生计算基金会）由 Linux 基金会成立，K8s 成为首个托管项目

这十年间，云计算从”新鲜事物”变成了”行业共识”，从技术创新逐渐演变为社会基础设施。

1.6 云原生时代：2016年至今#

2016年后，云计算进入 云原生（Cloud Native） 时代。与此同时，新的开发模式也开始出现。例如 2014 年 Amazon 推出的 AWS Lambda，使开发者可以直接运行代码而无需管理服务器，这种模式被称为 Serverless。

在云原生架构中：

• 微服务取代单体应用
• 容器成为标准部署单元
• DevOps 和 GitOps 促进持续交付
• 基础设施逐渐完全自动化

云计算从一种基础设施选择，逐渐演变为现代软件系统的默认运行环境。

根据 Synergy Research Group 的数据统计，全球云基础设施服务市场规模已经从 2016 年的约 500 亿美元增长到 2024 年的约 3300 亿美元，成为数字经济最重要的基础设施之一。

2.1 虚拟化：云计算的地基#

虚拟化（Virtualization） 解决的核心问题是：如何让一台物理机同时运行多个相互隔离的操作系统，并将资源利用率从 5%~15% 提升到 65% 以上？

1
VXLAN 数据包结构：
2
┌──────────────────────────────────────────────────────────┐
3
│  Outer Ethernet Header（物理网络 MAC）                    │
4
│  Outer IP Header（物理服务器 IP，VTEP 地址）              │
5
│  UDP Header（目标端口 4789）                              │
6
│  VXLAN Header（含 24-bit VNI，支持 ~1,677 万个隔离网络）  │
7
│  Inner Ethernet Header（虚拟网络内 MAC）                  │
8
│  Inner IP/Payload（VM/容器的实际通信数据）                │
9
└──────────────────────────────────────────────────────────┘

2.2 软件定义：用代码管理一切#

基础设施即代码（IaC，Infrastructure as Code） 是云计算最深刻的工程变革之一：把原来由人工操作完成的基础设施配置，全部变成可版本化、可审计、可重复执行的代码。

1
# Terraform 声明一台 AWS 云服务器（示例）
2
resource "aws_instance" "web_server" {
3
  ami           = "ami-0c55b159cbfafe1f0"
4
  instance_type = "t3.medium"
5
  subnet_id     = aws_subnet.public.id
6

7
  tags = {
8
    Name        = "ProductionWebServer"
9
    Environment = "prod"
10
  }
11
}

这段代码可以在任何时候被执行，在全球任何 AWS Region 创建出完全一致的服务器。传统运维需要数天的工作，云上只需数十秒。

IaC 的核心价值：可重复性（消除”在我机器上能跑”）、版本管理（基础设施变更可被 Git 追踪回滚）、自动化（与 CI/CD 集成，无需人工介入）、审计性（每次变更有记录，满足合规要求）。

主流 IaC 工具：Terraform（HashiCorp，声明式，多云支持，事实标准）、Pulumi（支持 Python/TypeScript 等通用语言）、AWS CloudFormation / 阿里云 ROS（各厂商原生方案）。

2.3 弹性伸缩：云计算的灵魂#

弹性（Elasticity） 是云计算区别于传统 IDC 最本质的特征——资源可以随业务负载动态扩缩，用完即还，不再为”可能到来的高峰”常年维护一批闲置服务器。

3.1 虚拟机时代：硬件级强隔离#

虚拟机依赖 Intel VT-x/AMD-V 实现真正意义上的硬件级隔离：

• CPU 隔离：VM Exit 机制确保 Guest OS 的特权指令不能直接影响 Hypervisor 和其他 VM；CPU Pinning 可将 vCPU 绑定到特定 pCPU，消除调度抖动，适合延迟敏感型负载
• 内存隔离：EPT/NPT 为每个 VM 提供完全独立的物理地址空间，VM 无法访问其他 VM 的内存页；KSM（Kernel Samepage Merging）在宿主机层面合并相同内容的内存页，节省物理内存
• 设备隔离：所有 I/O 请求经 Hypervisor 仲裁；高性能场景下使用 SR-IOV（Single Root I/O Virtualization） 让 VM 直接访问物理网卡的虚拟功能（VF），绕过软件模拟层
• 安全边界：即使 Guest OS 内核被攻破，攻击者仍被 Hypervisor 的硬件边界阻挡（除非存在极罕见的 VM 逃逸漏洞）

vCPU 调度原理：vCPU 本质上是宿主机上的一个 POSIX 线程，由宿主机 Linux 的 CFS（Completely Fair Scheduler）调度到物理 CPU 核上执行。云厂商通常对 vCPU 进行超卖（Overcommit）——分配给所有 VM 的 vCPU 总数超过物理 pCPU 数量，依赖统计复用降低成本。同时，内存气球（Memory Ballooning） 技术允许宿主机在内存紧张时通知 VM 内的 Balloon Driver 归还闲置内存页。

3.2 容器时代：内核级软隔离#

容器不是虚拟机，它与宿主机共享同一个 Linux 内核。隔离和资源限制依赖两个 Linux 内核特性：Namespace 和 cgroups。

1
# ── cgroups v1 示例（/sys/fs/cgroup/ 下）──────────────────────
2

3
# CPU 限制：每 100ms 调度周期内最多使用 50ms（相当于 0.5 核）
4
echo 100000 > /sys/fs/cgroup/cpu/mycontainer/cpu.cfs_period_us
5
echo  50000 > /sys/fs/cgroup/cpu/mycontainer/cpu.cfs_quota_us
6

7
# 内存限制：最多使用 512MB（超出触发 OOM Kill）
8
echo 536870912 > /sys/fs/cgroup/memory/mycontainer/memory.limit_in_bytes
9

10
# 磁盘 I/O 限制：对 sda（8:0）写入速度限制为 10MB/s
11
echo "8:0 10485760" > /sys/fs/cgroup/blkio/mycontainer/blkio.throttle.write_bps_device

4.1 本质差异全景对比#

4.2 Docker 带来的范式转变#

Docker（2013年） 的最大贡献不是技术本身（Namespace 和 cgroups 早已存在），而是把这些技术整合成了工程师友好的工作流：

1. 分层镜像（Layered Image）：基于 OverlayFS，每一层只存储变更内容，多个镜像共享相同基础层，节省磁盘和传输带宽
2. Dockerfile：声明式代码描述镜像构建，镜像可版本化、可复现
3. Registry：Docker Hub 等镜像仓库让分发像 Git push/pull 一样简单
4. OCI 标准：Docker 推动 OCI（Open Container Initiative）规范统一容器镜像格式（Image Spec）和运行时接口（Runtime Spec），使 containerd、CRI-O 等运行时百花齐放

容器 ≠ 银弹：容器不擅长有状态服务（数据库的 Persistent Volume 性能弱于裸 VM），也不适合强安全隔离。这催生了 gVisor（Google，用户态内核沙箱）和 Kata Containers（轻量级 VM 封装容器）等”安全容器”方案，兼顾容器的轻量和 VM 的隔离性。

4.3 Kubernetes：容器时代的操作系统#

Kubernetes（K8s）解决的是：如何在集群中编排成千上万个容器？

kube-scheduler 两阶段调度（来源：Kubernetes 官方文档 Scheduling Framework）：

• 阶段一：过滤（Filtering）：找出所有能运行该 Pod 的 Node，排除不满足 resource requests、Taint/Toleration、亲和性规则等约束的节点
• 阶段二：打分（Scoring）：对候选节点打分，默认策略包括：LeastAllocated（优先资源使用率低的节点，均衡负载）、MostAllocated（优先资源使用率高的节点，Bin Packing 提升装箱密度）、NodeAffinity、InterPodAffinity

资源 Requests/Limits 与 cgroups 的映射：

1
resources:
2
  requests:
3
    cpu: "500m" # 调度依据：Node 上已分配 requests 之和不超过节点容量
4
    memory: "256Mi"
5
  limits:
6
    cpu: "1000m" # → cgroups cpu.cfs_quota_us（运行时 CPU 上限）
7
    memory: "512Mi" # → cgroups memory.limit_in_bytes（超出触发 OOM Kill）

由此衍生出三种 Pod QoS 等级（决定内存压力时 OOM Kill 的优先顺序）：

5.1 NIST 标准定义#

2011年，美国国家标准与技术研究院（NIST）发布 Special Publication 800-145《The NIST Definition of Cloud Computing》，给出了迄今最权威的定义：

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.

——NIST SP 800-145, P. Mell & T. Grance, September 2011

NIST 定义了五个基本特征（Essential Characteristics）：

1. 按需自助服务（On-demand Self-service）：用户无需人工介入，可自助开通/关闭资源
2. 广泛的网络访问（Broad Network Access）：通过标准网络协议，可从电脑、手机等多种终端访问
3. 资源池化（Resource Pooling）：多租户共享动态分配的资源池，用户通常不关心资源的物理位置
4. 快速弹性（Rapid Elasticity）：资源可快速弹性扩缩，对用户来说资源似乎”无限可用”
5. 可度量的服务（Measured Service）：资源使用可监控、控制和报告，支持按量计费

NIST 同时定义了 3 种服务模型（SaaS/PaaS/IaaS）和 4 种部署模型（公有云/私有云/混合云/社区云），这是第六章和第七章完整展开的依据。

5.2 云计算的计费体系：按用付费的多种形态#

理解云的商业逻辑，必须理解其计费体系。以 AWS EC2 为例（来源：AWS EC2 Pricing 官方文档）：

5.3 云计算的规模经济：为什么云厂商有成本优势？#

云厂商的成本优势来自三个叠加因素：

1. 规模采购：AWS 每年采购数百万台服务器，单台硬件成本远低于普通企业
2. 资源复用：虚拟化超卖让物理资源利用率从企业自建的 5%~15% 提升到 60%~80%
3. 运维自动化：数据中心自动化程度极高，数千台服务器只需少量工程师管理

这三点叠加，让云厂商能以低于企业自建 TCO 的成本提供更高质量的基础设施，这是云计算商业模式成立的根本原因。

6.1 责任边界总览#

1
                   自建 IDC    IaaS      PaaS      SaaS
2
──────────────────────────────────────────────────────
3
应用代码            用户 ←─────────────────────→ 云管
4
运行时/框架          用户 ────── 用户 ──────────→ 云管
5
数据库/中间件         用户 ────── 用户 ──── 用户 → 云管
6
操作系统             用户 ────── 用户 ──────────→ 云管
7
虚拟化/容器           用户 ──────────────────────→ 云管
8
物理网络/服务器        用户 ──────────────────────→ 云管
9
数据中心/机房         用户 ──────────────────────→ 云管
10
──────────────────────────────────────────────────────
11
用户管理的层次           7       3~4       1~2        0

6.2 IaaS（Infrastructure as a Service，基础设施即服务）#

IaaS 是”租用虚拟化硬件”——云厂商提供计算、存储、网络的虚拟化资源，用户自管 OS 以上的一切。

6.3 PaaS（Platform as a Service，平台即服务）#

PaaS 是”租用完整的应用运行平台”——用户只需关注应用代码和业务数据，其余一切由云厂商托管。

6.4 SaaS（Software as a Service，软件即服务）#

SaaS 是”租用完整软件应用”——用户直接使用，无需关心任何基础设施，通常按用户数/功能模块订阅。

6.5 新兴 XaaS：服务模型的持续演化#

Serverless（FaaS）详解：Serverless 是”按需付费”理念的极致——代码只在被调用时运行，按执行次数和时长计费（精确到 1ms），无流量时零费用。

1
# AWS Lambda 函数示例：S3 上传事件触发自动生成缩略图
2
def lambda_handler(event, context):
3
    bucket = event['Records'][0]['s3']['bucket']['name']
4
    key    = event['Records'][0]['s3']['object']['key']
5
    # 处理图片...
6
    return {'statusCode': 200}
7
# 计费：仅在被触发时产生费用（通常 < 1 美分/千次调用）
8
# 无流量时：零费用

Serverless 的主要挑战是冷启动延迟（容器初始化通常需要数百毫秒到数秒）。AWS Firecracker（KVM-based 轻量级 microVM，启动时间 < 125ms，内存开销约 5MB）和 SnapStart（2022年，基于 Firecracker 内存快照恢复）是针对性解决方案。

7.1 公有云（Public Cloud）#

NIST 定义：云基础设施由云服务提供商拥有和运营，通过互联网向公众或特定行业开放，资源在多个租户之间共享。

7.2 私有云（Private Cloud）#

NIST 定义：云基础设施专属于单一组织（可能由该组织或第三方管理），可部署在组织内部或外部数据中心。

7.3 混合云（Hybrid Cloud）#

NIST 定义：两种或多种云部署模型（私有、社区或公有云）的组合，各部分保持独立实体，通过标准化技术连接，实现数据和应用的可移植性。

7.4 多云（Multi-Cloud）#

多云指同时使用两家或以上公有云厂商的服务（区别于”混合云”的公有+私有组合）。

7.5 社区云（Community Cloud）#

NIST 定义：云基础设施由有共同利益（如使命、安全要求、政策或合规考虑）的特定组织社区共享，由这些组织或第三方管理，可部署在本地或远程。

社区云是最容易被遗忘的 NIST 部署模型，但在特定行业中极为重要：

• 政务云：供政府机关共享，数据主权和安全标准统一。典型案例：AWS GovCloud（隔离的 AWS 基础设施，符合 FedRAMP High 认证，仅向美国政府及合规承包商开放）、中国各省市的”政务云”
• 金融行业云：满足 PCI-DSS、Basel III 等金融监管合规要求的专属平台
• 医疗行业云：满足 HIPAA（美国医疗隐私法）或 GDPR 医疗数据要求，如 AWS Healthcare Competency 合作伙伴提供的托管平台
• 学术/科研云：如美国的 XSEDE（国家超算网络）、中国科技云（CSTCloud）

社区云与私有云的区别在于：私有云服务单一组织，社区云服务有共同利益的一组组织，在他们之间共享基础设施和运维成本。

7.6 主权云（Sovereign Cloud）：新兴的第五种形态#

地缘政治的复杂化使”数据主权”成为各国政府的核心诉求，推动了介于社区云和公有云之间的主权云的兴起：

• 欧盟 GAIA-X：欧盟主导的数据与云基础设施联盟，旨在减少对美国云厂商的依赖
• 法国 Bleu 项目：Microsoft 与 Orange/Capgemini 合资，在法国本土运营 Azure 的主权版本，代码和数据不离开法国
• 中国合规要求：AWS（光环新网）、Azure（世纪互联）须以合资公司形式运营，数据须在境内存储

主权云将重构以美国大厂主导的全球云市场格局，催生大量本地云厂商。

7.7 部署形态选型决策框架#

典型演进路径：起步期全量公有云（快速迭代）→ 规模化后引入私有云处理敏感数据和大规模稳定负载（成本优化）→ 构建混合云实现协同 → 视需求引入第二家公有云（避免锁定或能力互补）。

8.1 全球市场格局#

根据 Synergy Research Group 2024年第四季度数据（来源：Q4 2024 Cloud Infrastructure Services Market Report）：

中国市场（来源：IDC 中国公有云服务市场2024年数据）：阿里云约 33%（国际化布局积极）、华为云（自研昇腾 AI 芯片，政企优势明显）、腾讯云（游戏/音视频/金融）、字节跳动火山引擎（推荐算法和视频处理技术对外输出）。

8.2 云计算产业链全景#

1
硬件层     CPU/GPU（Intel、AMD、NVIDIA、ARM）
2
           云厂商自研芯片（AWS Graviton/Trainium、阿里倚天 710/含光 800）
3
           服务器（Dell、HPE、浪潮、超微）
4
           网络设备（思科、Arista、华为）
5
           存储硬件（希捷、西数、三星 NVMe SSD）
6

7
IaaS 层    计算（EC2、ECS）
8
           分布式存储（S3、OSS、Ceph）
9
           网络（VPC、CDN、专线、SD-WAN）
10

11
PaaS 层    容器编排（K8s、EKS、ACK）
12
           数据库（Aurora、PolarDB、Spanner）
13
           消息队列（Kafka、SQS、RocketMQ）
14
           AI/ML 平台（SageMaker、PAI、Vertex AI）
15
           函数计算（Lambda、FC、Cloud Functions）
16

17
SaaS 层    业务应用（Salesforce、M365、钉钉、飞书）
18
           行业云（金融云、医疗云、政务云、工业云）
19
           AI 应用（GitHub Copilot、Azure OpenAI Service）
20

21
工具链     IaC（Terraform、Pulumi、CDK）
22
           DevOps（GitHub Actions、ArgoCD、Tekton）
23
           可观测性（Prometheus、Grafana、Datadog、OpenTelemetry）
24
           安全（WAF、CSPM、SIEM、零信任 ZTA）
25
           FinOps（Cost Explorer、Infracost、CloudHealth）

9.1 降低了创业门槛，加速了互联网创新#

云计算出现之前，初创公司上线互联网产品的前期硬件投入可能高达数十万元。云计算让这一切变成”注册账号，5 分钟上线”。Dropbox、Airbnb、Netflix、Spotify、Uber 等独角兽在早期都是 AWS 的重度用户，云计算是过去十年全球互联网创新加速的最重要基础设施之一。

9.2 重塑了 IT 部门的角色#

传统 IT 部门的核心工作是”买服务器、维护服务器”。上云后，IT 部门价值转向：

• 架构设计：如何用云服务构建高可用、可扩展的系统
• 成本优化（FinOps）：云账单治理，FinOps Foundation（2019年成立）提供了系统化的实践框架
• 安全合规：在**责任共担模型（Shared Responsibility Model）**下管理好企业侧的安全边界——云厂商负责”云的安全”（物理基础设施），企业负责”云上的安全”（数据、访问控制、应用安全）
• 平台工程（Platform Engineering）：为内部开发团队构建标准化的 Internal Developer Platform（IDP）

9.3 推动了软件工程的深层演进#

• 微服务：云的弹性让细粒度服务拆分成为可能，每个服务独立扩缩容
• 容器化与 CI/CD：Docker + K8s + GitHub Actions，持续交付成为标配
• DevOps 文化：“You build it, you run it” 成为现代工程团队的准则
• 云原生数据库：Aurora 的计算存储分离、Spanner 的全球一致性事务，突破了传统单机数据库的边界
• 可观测性（Observability）：OpenTelemetry 标准化了 Metrics/Logs/Traces 三大信号的采集，是云原生时代分布式系统调试的基础

9.4 带来的新挑战#

成本失控：按需计费在缺乏治理时容易出现”云账单爆炸”，FinOps 因此成为独立学科。

安全合规复杂化：GDPR（2018年）、中国《数据安全法》《个人信息保护法》（2021年）的落地，使跨境数据流动合规成为全球企业的重大挑战。

厂商锁定：深度依赖专有服务后迁移成本极高，选择基于开放标准（标准 SQL、K8s、OpenTelemetry）是主要应对策略。

系统复杂度上升：数百个微服务的分布式系统，链路追踪和故障定位难度远超单体应用。Service Mesh（Istio/Linkerd）用于标准化微服务间的流量治理、安全和可观测性。

网络延迟瓶颈：工业控制、自动驾驶、实时游戏对延迟的要求（< 1ms）超出了公有云数据中心能力上限，边缘计算（MEC） 是补充方案。

10.1 AI 驱动云计算的下一轮增长#

2023年 ChatGPT 的爆发，彻底改变了云计算的增长逻辑。AI 大模型的训练和推理需要消耗海量 GPU/TPU 算力，据 Synergy Research Group 估算，2024年全球 AI 相关云基础设施支出同比增长超过 60%。

云厂商自研 AI 芯片以降低对 NVIDIA 的依赖：AWS Trainium（训练）/ Inferentia（推理）、Google TPU v5p、阿里云含光 800。AI 也在反向改造云本身：AIOps 自动诊断故障、智能 FinOps 预测成本并推荐最优计费方案、GitHub Copilot 等 AI 编码辅助工具大幅提升云上开发效率。

10.2 Serverless 的普及：向”零基础设施感知”演进#

Serverless 是”按需付费”理念的终极形式。AWS SnapStart（基于 Firecracker 内存快照）和 WASM（WebAssembly 运行时，冷启动时间在微秒级）正在系统性解决冷启动问题，使 Serverless 的适用场景从事件驱动扩展到更通用的 Web 服务。

10.3 边缘计算与云边端协同#

MEC（Multi-access Edge Computing，ETSI 标准） 将计算下沉到运营商基站侧，端到端延迟可压缩到 110ms（相比公有云数据中心的 20100ms）。“云-边-端”三层协同架构将成为主流：云端负责模型训练与全局决策，边缘节点负责实时推理与本地数据处理，端侧设备（Apple Neural Engine / 高通 AI Engine）承担轻量级推理任务。

10.4 可持续云计算（Green Cloud）#

根据 IEA 2024年《Electricity 2024》报告，全球数据中心2023年电力消耗约 400TWh（约占全球用电量的 1.5%），随 AI 算力需求激增，预计2026年翻倍。

各厂商绿色承诺：Google 目标2030年实现7×24 无碳电力（PUE 已降至 1.10，远优于行业平均 1.58）；Microsoft 承诺2030年碳负排放；AWS 已于2023年宣布运营100%可再生能源。液冷（浸没式/喷淋式）和 AI 动态调优 PUE 是数据中心节能的主要技术路线。

10.5 主权云：地缘政治重塑云市场格局#

欧盟 GAIA-X、法国 Bleu 项目、中国合规要求（AWS/Azure 须以合资公司形式运营，数据境内存储）代表了主权云的三种模式——联盟自建、本地合资运营、强制本地化。这一趋势将重构以美国大厂主导的全球云市场，催生大量本地云厂商和新的合规工程需求。

标准与权威定义#

1. NIST SP 800-145 — The NIST Definition of Cloud Computing P. Mell & T. Grance (2011). 云计算的权威定义，IaaS/PaaS/SaaS 和四种部署模型的原始来源。 https://csrc.nist.gov/publications/detail/sp/800-145/final

2. OCI（Open Container Initiative）规范 容器镜像格式（Image Spec）和运行时接口（Runtime Spec）的开放标准，容器生态互操作性的基础。 https://opencontainers.org/

3. CNCF Cloud Native Definition 云原生计算基金会对”云原生”的官方定义。 https://github.com/cncf/toc/blob/main/DEFINITION.md

4. ETSI MEC — Multi-access Edge Computing 边缘计算的 ETSI 标准规范。 https://www.etsi.org/technologies/multi-access-edge-computing

技术底层#

5. Linux Kernel Documentation — Control Groups v2 cgroups v2 官方文档，含 cpu/memory/io/pid 等子系统参数详解。 https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html

6. Linux man-pages — namespaces(7) Linux Namespace 全部类型及 API 的权威手册。 https://man7.org/linux/man-pages/man7/namespaces.7.html

7. Intel® 64 and IA-32 Architectures SDM, Volume 3C — VMX Instructions Intel VT-x 硬件规范，包含 VM Entry/Exit 机制的底层细节。 https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html

8. RFC 7348 — Virtual eXtensible Local Area Network (VXLAN) VXLAN 协议的 IETF 标准文档，含封包格式和 VNI 机制。 https://datatracker.ietf.org/doc/html/rfc7348

9. Firecracker: Lightweight Virtualization for Serverless Applications（USENIX NSDI 2020） AWS Firecracker 设计论文，microVM 轻量化虚拟化的技术细节。 https://www.usenix.org/conference/nsdi20/presentation/agache

10. Borg, Omega, and Kubernetes（ACM Queue, 2016） Google 工程师回顾三代容器管理系统演进，K8s 设计哲学的必读文章。 https://queue.acm.org/detail.cfm?id=2898444

调度与资源管理#

11. Kubernetes 官方文档 — Scheduling, Preemption and Eviction kube-scheduler 的过滤/打分流程、QoS 等级、Pod 优先级官方说明。 https://kubernetes.io/docs/concepts/scheduling-eviction/

12. Kubernetes 官方文档 — Resource Management for Pods and Containers requests/limits 语义及与 cgroups 的映射关系。 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

13. Large-scale cluster management at Google with Borg（EuroSys 2015） Google Borg 调度系统论文，Bin Packing 等策略的来源。 https://research.google/pubs/pub43438/

架构与工程实践#

14. AWS Well-Architected Framework AWS 官方云架构最佳实践，涵盖可靠性、安全、性能效率、成本优化、卓越运营和可持续性六大支柱。 https://aws.amazon.com/architecture/well-architected/

15. AWS Disaster Recovery Whitepaper 四种 DR 策略（Backup/Pilot Light/Warm Standby/Active-Active）的官方说明，RTO/RPO 数据来源。 https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html

16. AWS Aurora Technical Overview 计算存储分离架构详细设计与性能数据来源（Aurora vs MySQL 5x 性能提升数据）。 https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.html

17. AWS EC2 Pricing 官方文档 On-Demand/Reserved/Spot/Savings Plans 计费模型数据来源。 https://aws.amazon.com/ec2/pricing/

市场数据#

18. Synergy Research Group — Cloud Infrastructure Services Market 全球云基础设施市场份额季报，AWS/Azure/GCP 占比数据来源。 https://www.srgresearch.com/articles/category/cloud-market-share

19. Flexera 2024 State of the Cloud Report 87% 企业采用混合云策略等数据的来源。 https://www.flexera.com/blog/cloud/cloud-computing-trends-flexera-2024-state-of-the-cloud-report/

20. IEA — Electricity 2024 数据中心电力消耗报告，Green Cloud 相关数据来源（400TWh、1.5%全球用电量）。 https://www.iea.org/reports/electricity-2024