云计算基础与架构体系

2025 年还在做软件的团队，依然要回答二十年前的同一道题：买服务器还是租服务器？只是答案彻底反转了。从前你把硬件塞进机柜；现在你用 YAML 描述硬件，全球厂商在几秒内变出来、按秒计费、随时拆掉。云计算不只是"别人家的电脑"，而是覆盖在算力、存储、网络之上的一套可编程、可计量、多租户抽象 – 它从根本上改变了企业的构建方式，也改变了工程师每天怎么过。

本系列的第 1 篇是概念地基，刻意慢一点。读完之后你应当能：看懂一张云架构图、在厂商售前会议上问出对的问题、用经济学和工程语言而不是口号谈成本、可靠性与厂商绑定。

你将学到

• 任何云决策都绕不开的 7 个维度 – 以及为什么"上云"从来不是一个决策
• 从 IaaS 到 PaaS、FaaS、SaaS 的服务模型，以及它们隐含的"管理边界"
• 公有云、私有云、混合云、多云等部署拓扑的成本与复杂度权衡
• 36 个月时间窗内 CapEx 与 OpEx 各自的曲线形状，以及拐点在哪里
• 责任共担模型，以及为什么大多数云上事故都是"客户端"的配置失误
• 地域、可用区背后的延迟与故障域设计哲学
• AWS / Azure / GCP / 阿里云的服务目录速查表
• 一套可在年终复盘时站得住脚的选型框架

前置知识

• 对"服务器、网络、操作系统"有基本概念
• 至少熟悉一门编程语言和命令行
• 不需要任何云计算经验

1. 云计算到底是什么

引用频率最高的定义来自美国国家标准与技术研究院（NIST），它列出了五条关键特征。这五条之所以有用，是因为它能把"看起来像云、但其实不是"的东西排除在外。

• 按需自助服务 – 开发者通过 API 或控制台直接拿资源，不需要工单、不需要打电话
• 广泛的网络访问 – 资源可以被各种客户端通过标准网络访问到
• 资源池化 – 物理基础设施是多租户共享的，用户看不到也不关心自己的工作负载具体跑在哪台机器
• 快速弹性 – 容量可以分钟级伸缩，常常是自动的，对消费者来说"几乎无限"
• 可计量服务 – 以非常细的粒度计量与计费（按秒、按请求、按 GB-月）

一个传统数据中心给你租机柜，至少漏掉三条；一款 SaaS 你打开浏览器登录，五条全中。这条定义清楚地划出了边界。

简史 – 让今天的设计决策变得可解释

2. 服务模型 – 管理边界划在哪里

把云服务想象成一座金字塔：层级越高，你管得越少、控制力也越小。工业上常见的层有 IaaS、PaaS、FaaS、SaaS 四层。

Infrastructure as a Service（IaaS）

你租到的是虚拟机、虚拟磁盘和虚拟网络。从操作系统往上 – 内核补丁、运行时、应用、数据 – 全是你的事。

• AWS EC2 – 700+ 实例规格，覆盖通用、内存、计算、存储、GPU 各种优化方向
• Google Compute Engine – 持续使用折扣、可抢占实例、自定义形状
• Azure Virtual Machines – 与 Active Directory、.NET、Windows 授权深度集成
• 阿里云 ECS – 国内市场主导，并有专门为通义推理优化的实例族

适用场景： 不改代码迁移既有应用、需要特定 OS 或内核模块、或是 HPC / GPU 训练 / 低延迟交易这类对 hypervisor 之上任何抽象层都敏感的极致性能负载。

参考成本： 4 vCPU、16 GB 实例按需价约 USD 0.20/小时（约 150 美元/月）；1 年预留约便宜 30-50%；可中断的 Spot 约便宜 60-80%。

Platform as a Service（PaaS）

你提交代码和配置，厂商负责操作系统、运行时、负载均衡、自动伸缩。你看到的是日志和指标，不是服务器。

• Heroku – 让 git push 一键发布成为标准动作的鼻祖
• Google App Engine – 从 0 自动扩到几千 QPS 不需要任何人为操作
• AWS Elastic Beanstalk – 上传代码，AWS 在背后帮你拉起 EC2、ELB、ASG、CloudWatch
• Vercel / Netlify – 偏前端的 PaaS，针对 Next.js 等框架优化

适用场景： 上线速度压倒一切、团队规模小、应用本身相对标准（Web、API、Worker），愿意为"不需要给操作系统打 oncall"接受运行时上的限制。

Function as a Service（FaaS）/ Serverless

你提交一个函数。它按需运行，按调用次数 + 毫秒级执行时间计费，请求之间没有需要保活的实例。

• AWS Lambda – 经典代表，单次最长 15 分钟
• Azure Functions、Google Cloud Functions / Cloud Run – 同等位置
• 阿里云函数计算（FC）

适用场景： 流量突发或事件驱动（图片上传触发缩略图、Webhook 触发流程）、流量模式不可预测、用作连接托管服务的胶水代码。不适合： 需要长连接、对冷启动要求 < 50 ms 又不想买 Provisioned Concurrency、长时间运行的算力 – 在某个稳态阈值之上单位经济学会反过来。

Software as a Service（SaaS）

你直接用应用本身，提供商管到芯片层。

• 代表产品： Gmail、Salesforce、Slack、Zoom、Microsoft 365、Notion、Figma、Datadog

适用场景： 这件事对你的业务是大宗商品（邮件、CRM、视频会议、可观测性）；不要选 SaaS 当它正是你的护城河 – 那本来就是你应该自己造的东西。

一张图：管理边界

最简洁的心法：沿着金字塔上行，管理边界整体上移；边界以下是厂商的事，边界以上是你的事。

3. 部署模型 – 工作负载住在哪里

服务模型告诉你"租什么"，部署模型告诉你"住在谁家的机房、网络怎么连"。

公有云

超大规模厂商运营数据中心，你与其他租户在加密 + hypervisor 隔离下共享底层硬件。适合长尾的大多数工作负载 – Web 应用、批处理、开发测试，以及创业公司可能做的几乎所有事情。

私有云

你（或一家托管伙伴）为单一租户运营专属基础设施。适合监管、延迟或数据驻留要求禁止共享硬件的场景 – 国防、特定医疗与银行业务，或对控制器毫秒级响应敏感的工厂场景。

混合云

公有 + 私有作为一个逻辑整体，通过 VPN 或专线（AWS Direct Connect、Azure ExpressRoute、GCP Interconnect、阿里云高速通道）连接。经典模式：敏感客户数据留在本地，批处理与突发流量溢出到公有云。坑 在于：你现在拥有两套工具链、两套安全态势、两套 oncall 排班。

多云

生产环境同时使用两家或以上的公有云。动机包括：避免厂商绑定、用各家最强服务（GCP 的 BigQuery、AWS 的 Bedrock）、客户合同强制要求。代价是真实的 – 身份、网络、可观测性、CI/CD 都得做成"云无关"。

经验法则： 默认单地域公有云。停机开始真正烧钱时再加第二地域。只有当战略性原因（监管、客户硬性要求、主云没有的关键服务）出现时，才加第二个云。

4. 市场为什么会高度集中

云是现代基础设施里最集中的市场之一。AWS、Microsoft Azure、Google Cloud 三家占了全球 IaaS+PaaS 大约三分之二的份额；阿里云在中国大陆领先；其余被一长串地域厂商和垂直厂商瓜分。

集中并非偶然。云基础设施是 CapEx 极重的生意，规模效应非常强：每多一个地域 / AZ 就能解锁更多客户，每多一个服务都会和已有服务复利（S3 让 EC2 更黏，IAM 让两者都更黏）。小厂商靠价格、垂直行业（游戏、科研）或地域优势竞争。

5. 经济学 – CapEx vs OpEx 的时间曲线

云的最大商业理由是成本曲线的形状。本地部署是按"块"提前买容量，云是按秒"按需买"。

两种效应同时叠加：

1. 浪费的容量。 按峰值采购的本地硬件在均值上长期闲置 – 企业数据中心的典型利用率在 15%-30% 区间徘徊。
2. 容量缺口。 当需求冲破预设上限（一次发布、一次营销活动、一次破圈传播），本地撑不住；云在分钟级吃下这部分。

对变动型工作负载（绝大多数都是变动型），无论你假设硬件多便宜，云在原始成本上几乎都赢。当工作负载是长期稳态、高利用率（视频转码 7×24 跑在 80%+，稳定的内部数据库集群），三年预留实例或私有云自建反而能比按需云便宜 30-50%。

必须建模的隐性成本

按需价格挂在网站上的那个数从来不是账单全部。请始终把这些算进去：

• 流量出云费（Egress） – 从云出去要钱；跨地域之间也要钱
• 跨可用区流量 – 大多数厂商都收费；如果微服务之间互调密集，能轻松吃掉账单大头
• 托管服务溢价 – RDS 大约比自己在 EC2 跑 PostgreSQL 贵约 30%
• 支持计划 – Business / Enterprise 通常占月度消费的 3-10%
• 人 – 平台工程师、FinOps 分析师、安全工程师；“云团队"不是免费的

一份能站得住脚的 TCO 模型至少看 3 年、要把硬件刷新周期与云的预留打折都纳入、并把人力成本同时摊到两边。

6. 架构构件

云不止是 VM。下面几个原语在任何认真的架构里都会反复出现。

虚拟化 – 底层基质

Hypervisor 让多台虚拟机共享一台物理机。两类要点都要知道：

• Type 1（裸金属） – VMware ESXi、KVM、Hyper-V、Xen。直接跑在硬件上；公有云全部用这类
• Type 2（宿主型） – VirtualBox、VMware Workstation。跑在宿主 OS 之上；适合开发与测试

容器不是底层基质上对 VM 的替换，它坐在 VM 之上，与宿主 VM 共享内核。一个典型的 EKS / AKS Pod 是：容器 -> 跑在 Linux VM 里 -> 运行在 hypervisor 上 -> 跑在物理服务器上。Part 2（虚拟化）和 Part 7（云原生）会展开。

存储 – 按访问模式选，而不是按名字选

S3 风格的存储分级让你用取回延迟换成本。常见做法：热数据放 Standard，30 天后转到 Standard-IA，180 天后转到 Glacier，1 年后转到深度归档 – 全部用生命周期策略驱动，不靠人工。

网络 – 最容易出事的部分

• VPC（虚拟私有云） – 你在云里的隔离网络，每个 AZ 一个子网，配路由表、安全组、NACL
• 负载均衡器 – L4（NLB，TCP）追求吞吐，L7（ALB，HTTP）按路径 / Header 路由
• CDN – 把静态（以及越来越多动态）内容缓存到离用户近的边缘 POP；CloudFront、Cloud CDN、Azure CDN、Cloudflare
• VPN / 专线 – IPSec 隧道走廉价路径，专线走可预测路径（典型 < 2 ms，不走公网）

自动伸缩 – 弹性的发动机

指标超阈（CPU > 70% 持续 3 分钟）
    -> 伸缩组添加 N 个实例（横向扩容）
    -> 负载均衡健康检查通过后开始转发流量
指标恢复（CPU < 30% 持续 10 分钟）
    -> 伸缩组移除实例（横向缩容），先排空连接

两个轴：

• 横向（扩 / 缩） – 加减实例数；云原生的默认动作
• 纵向（升 / 降配） – 改实例规格；通常需要停机重启，因此一般只用在数据库这类有状态负载

地域与可用区 – 故障域设计

地域（Region） 是地理范围（us-east-1、eu-west-1、ap-southeast-1、cn-hangzhou），地域间相互隔离 – 一个地域出事不会传染到别处。每个地域包含多个可用区（AZ），是数公里间隔的物理独立机房，独立电源、冷却与网络，但有亚毫秒级光纤互联。

设计哲学：

• 同地域多 AZ 又便宜又简单：副本在不同 AZ、负载均衡器自动切换、应用代码几乎不用改
• 跨地域 要难得多：数据需要跨长距离链路复制，最终一致性问题浮现，DNS / 全球负载均衡需要在故障时重定向流量
• 边缘 / POP 用于内容分发与抗 DDoS，不用于有状态的应用逻辑

务实默认：第一天起就做多 AZ（几乎没有额外成本）；只在"宕机一分钟的损失大于一个月复制带宽"时再做多地域。

7. 责任共担模型

过去十年几乎每一起公有云事故都是客户侧的错配 – 公开的 S3 桶、泄露的 IAM Key、过宽的安全组。责任共担模型把背后的"为什么"形式化。

厂商始终负责"基质” – 物理访问、hypervisor、数据中心间的网络。会随服务模型变化的是边界划在哪里：

• IaaS – 客户负责 OS、中间件、应用、身份与数据；厂商负责 VM 之下的一切
• PaaS – OS 与中间件移交给厂商；客户保留应用代码、身份与数据
• SaaS – 几乎一切都归厂商；客户保留身份（谁能登录）与数据（他们能做什么）

两点很实用的推论：

1. 身份永远是你的事。 多因素、最小权限、密钥轮换、JIT 访问 – 没有一项是自动开启的。
2. 数据永远是你的事。 静态加密通常默认开；传输加密要你强制；备份、保留、合规取证完全由你设计。

这块在 Part 5（安全与隐私）会深入。

8. 服务目录 – 怎么读这本菜单

每家大厂都有数百个服务，但都聚成几个家族。下面这张图足以让你在任何一家厂商的目录里找到方向。

游走目录时的几条务实经验：

• 名字会变，家族不变。 厂商频繁改名重组；底层原语（算力、对象存储、托管 SQL）保持稳定
• 三个同心圆。 “核心” – 算力、存储、网络、IAM、监控 – 跨厂商成熟且基本等价；“托管” – 数据库、队列、容器编排 – 在易用性与价格上有差异；“前沿” – AI、数据仓库、自研芯片 – 厂商在这里争夺心智，绑定也最强
• 配额先于架构。 每个账号都有软配额与硬配额（vCPU 数、S3 桶数、API QPS）。在为伸缩做设计前先读懂它

9. 真实案例 – 架构在炮火下的样子

Netflix – 行星级流媒体

Netflix 在 2016 年关闭了最后一个数据中心，整体跑在 AWS 上，并自建 Open Connect CDN 部署到 ISP 内部承担实际视频字节。数百个微服务，自研的混沌工程工具链（Chaos Monkey、Simian Army），积极的多 AZ + 多地域容灾。结果： 2 亿+ 订阅用户，99.99% 量级可用性，能在一部爆款剧上线的周末吸收两倍的峰值流量。

Airbnb – 创业公司到全球平台

2009 年是 AWS 单地域的单体应用。到 2018 年发展为多地域上的数百服务，数据层用 Aurora 和 Vitess，东西向流量走 Service Mesh，读路径上有 ElastiCache（Redis）和 CloudFront。迁移是渐进的 – 一次拆一个有界上下文 – 历时数年而非一次性大爆改。结果： 数百万房源，挺过不可预测的季节峰值。

Capital One – 受监管企业的上云

美国第一批"全面"押注公有云的银行（AWS，2015 年宣布、2020 年完成）。难的不是技术而是治理 – 向 SOC、PCI-DSS 与银行专属监管证明：代码化的控制（Terraform、Cloud Custodian、CloudFormation 卫兵）的可审计性不亚于物理控制。结果： 2020 年前关闭全部 8 个遗留数据中心，基础设施成本下降 30-40%，软件交付周期由"季度"缩短到"天"。（2019 年那次配置错误的 WAF 引发 SSRF 的事故，正是责任共担里"客户侧"为何重要的教科书案例。）

Spotify – 主动选择多云

Spotify 流媒体业务以 GCP 为主，数据与 ML 平台围绕 BigQuery、Dataflow、Pub/Sub。AWS 在存储与部分算力上扮演角色。结果： 每天处理 PB 级收听数据来支撑 Discover Weekly 与 Wrapped，厂商集中度被有意识地管理。

10. 一套能在年终复盘站住脚的决策框架

云最难的不是技术选型 – 是一年后还能解释清楚为什么当初这么选。下面这套 7 维框架，是我反复回到的那一份。

经得住时间的最佳实践

• 从小到大，慢慢扩。 一个非关键服务、一个地域、一个账号，是个不错的起点
• 为故障设计。 假设任何组件，包括托管服务，都可能在任意时刻挂掉；第一天起就做多 AZ
• 能用托管就用托管。 不是非要不可，别自己跑 PostgreSQL
• right-size 并定期复盘。 多数集群超配 20-40%；每周一次审视很便宜，回报很快
• 全面加密。 静态加密默认开已成必选；传输加密 TLS 1.2+ 是底线
• 基础设施即代码。 Terraform、Pulumi、CloudFormation – 永远不要在生产环境点鼠标
• 第一天起就可观测。 流量到来之前就把日志、指标、追踪、告警接好

11. 常见问题

云一定比本地便宜吗？ 不一定。对于变动型工作负载和大多数企业，云胜出。对于非常稳态、高利用率（70%+）的大体量负载 – Dropbox 把存储层从 AWS 搬出节省了几亿美元就是经典案例 – 自建会赢。永远要做 3 年 TCO，把硬件刷新周期、出云费、人力都算进去。

云安全吗？ 基质比几乎任何企业自己能搭的都更安全。它之上的应用与配置 – 你做到多安全就有多安全。责任共担那条线就是分水岭，事故大多发生在线之上。

厂商宕机怎么办？ 会发生，要为它设计。多 AZ 用极低成本覆盖常见情况（地域内某机房失败）。多地域用相当代价覆盖罕见情况（整地域失败）。多云用很大代价覆盖极罕见情况（厂商级宕机）。把投入与你真实的风险偏好匹配，不是与新闻头条匹配。

该先学哪些技能？ 某一家厂商的入门级认证（AWS Cloud Practitioner / Solutions Architect Associate、Azure Fundamentals、GCP ACE）是快速入门的方式。然后是 Linux 基础、网络基础、基础设施即代码（Terraform）、容器（Docker、Kubernetes）。厂商专属知识的迁移性比大家想象得更强。

学 AWS、Azure 还是 GCP？ 学你雇主或目标雇主用的那一家。它们在概念上互通，切换是几周的事而不是几年。AWS 招聘市场最大；Azure 在企业 IT 里更主导；GCP 在数据 / ML 上有超额权重。

总结

本系列后续每一篇都会展开其中一层。下一篇深入虚拟化 – 让整座大厦得以存在的 hypervisor 魔法，从 KVM 内部机制到驱动 Lambda 的轻量化 VM Firecracker。

系列导航