# cloud 就是别人的电脑 关于 cloud 与 serverless 的速成课程。19 个概念——Cloud computing、CapEx → OpEx、On-demand、IaaS、PaaS、SaaS、Elasticity、Pay-as-you-go、Region、Availability zone、Managed service、Vendor lock-in、Serverless、Cold start 等——每个都配有英文名称、一幅图和一张卡片：是什么 → 例子 → 代价 → 关联。结尾附一页速查表。只讲精髓：cloud 不是个时髦词，而是 on-demand 地租用算力——是在便利、控制与成本之间一组清晰的取舍。 - **Author:** Fedor Chishchin - **Level:** intro - **Reading time:** ~30 分钟阅读 - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/zh/learn/cloud-express --- ## 1. 租来的电脑 剥去神秘的外衣，cloud 不过是个简单的生意点子：使用你并不拥有的电脑。其余的一切，都只是关于这台电脑的主人替你做了多少活的细节。 ### 地图：六组共 19 个概念 > 一张地铁线路图：先看到整套线路，再一站一站地坐过去。 这门课里的每个概念都属于六组之一。每一组回答各自的问题：cloud 到底是什么，供应商替你做了多少，容量和账单怎样增长，你的代码实际跑在哪里，哪些部件可以整个交给供应商，以及怎样运行代码而不必操心服务器。 _Diagram: 六组概念——第 1–6 章依次讲这六组。第 7 章讲怎样把它们一起用好。_ ### 怎么读这门课 > 一本护照：每个人的栏目都一样，所以容易比较。 每个概念都用同样的方式来讲：它的**英文名称**（记住它——它就是 AWS、Google Cloud 和 Azure 文档里用的术语）、一幅来自日常生活的画面、一张**图**，以及一张带有这些栏目的**卡片**：_是什么_、_例子_、_代价_，和*关联*概念。这门课的核心想法：每个 cloud 时髦词，都是「别人替你做了多少」这条刻度上的一个点——以及你为此付出的代价。 ### Cloud Computing——cloud 就是别人的电脑 > 打车，而不是买车：车是真的，行程也是真的，但你不去拥有它、停放它、给它上保险、保养它——你只在需要的时候用它。 **cloud computing** 就是放在别人数据中心里的电脑，你通过互联网租用它，而不是自己掏钱买来、自己运维。当你的应用「在 cloud 里」运行时，它跑在真实的、实实在在的机器上——只不过这些机器属于像 Amazon、Google 或 Microsoft 这样的供应商，由他们来操心机房、供电和硬件。你把计算力当作一种服务来获取，就像你用电那样，而无需拥有发电厂。 _Diagram: 你的应用跑在供应商的机器上：服务器、磁盘、网络和机房都是他们的事。_ #### Cloud Computing (云，the cloud) - **是什么:** 通过互联网租用别人的电脑，而不是自己买。 - **例子:** 一个网站跑在 AWS 的服务器上：Amazon 负责机房、供电和硬件；你负责自己的代码。 - **代价:** 服务器并没有消失——只是归别人所有。你用所有权换来了对供应商的依赖。 - **关联:** 整门课的基础；供应商替你做多少，由 **IaaS / PaaS / SaaS** 决定。 ### CapEx → OpEx——租，而不是买 > 你不会为了给家里供电而自建一座发电站——你接入电网，按用量付费。把整座电厂都买下来，只有在规模极其庞大时才说得通。 自己拥有服务器，意味着要预先购置昂贵的硬件、猜测自己将来会需要多少、并且不管用不用都得养着一屋子机器。这就是**资本支出（CapEx）**。租用把这一切反了过来：没有巨额的前期开销、没有闲置的硬件，而且有别人替你操心硬件那一面——这就是**运营支出（OpEx）**。对几乎所有人来说，正是这笔交易——把一大笔前期采购换成一份 pay-as-you-go 的账单——让 cloud 赢了下来。你是在使用资源的同时才花钱，而不是在用到它之前好几年就花钱。 _Diagram: 左：先买硬件，再去猜容量。右：租用，用多少付多少。_ #### CapEx → OpEx (租而不买) - **是什么:** 把一大笔前期硬件采购（CapEx）换成按用量持续支付的账单（OpEx）。 - **例子:** 创业公司不会为了以防万一而买下一整个机架的服务器——客户少的时候，只付几台 cloud 机器的钱。 - **代价:** 在规模极大且稳定的情况下，自己的硬件可能反而更便宜——就像自己的发电厂。 - **关联:** 由 **On-demand** 和 **Pay-as-you-go** 实现。 ### On-demand——几秒钟拿到资源 > 拧开水龙头，水立刻就流出来——不用等几周的送货，也不用搞一场水管工程。你一开口，供应就在那里。 它的决定性特征是资源是 **on-demand**（按需）的：你只需点几下鼠标或写一行代码，就能在几秒钟内启动一台新服务器、一个数据库，甚至一整套环境，关掉的时候同样迅速。对比一下下单、等待、再安装实体硬件的过程。这种即时的**自助**获取，让 cloud 不像是在买机器，而更像是在拧水龙头——你要多少容量，随时就有。 _Diagram: 自有硬件：从下单到跑起来要几周。cloud：一次 API 调用，几秒钟就绪。_ #### On-demand (自助，self-service) - **是什么:** 自己在几秒钟内启动或停止一项资源——不用提工单，也不用等送货。 - **例子:** 需要一个只用一天的测试环境——早上用一行代码把它拉起来，晚上删掉。 - **代价:** 拉起来容易，忘掉也同样容易——于是账单上就会出现惊喜（**Bill shock**）。 - **关联:** **Elasticity** 和 **Serverless** 的基础。 > **那个根本性的问题:** 「我是想拥有并运维实体机器——承担成本、靠猜测、做维护——还是 on-demand 地租用算力，只为我实际用到的部分付费？」 > cloud 就是 on-demand 地租用别人的电脑，而不是自己买。你把一大笔前期采购变成了 pay-as-you-go，并在几秒钟内拿到容量。 ## 2. IaaS、PaaS、SaaS cloud 服务是分层的，区别只在一件事：供应商管多少，你自己做多少。三个缩写，就是这条刻度上的三个主要节点。 ### Cloud Service Models——「别人替你运维多少」的刻度 > 吃一顿饭：租一间厨房，从头到尾自己做；或者拿到备好料的厨房；或者干脆点一份做好的菜送上门。同一顿晚饭，费的力气天差地别。 **cloud 服务模型**位于一条刻度上，一头是「几乎所有东西都要你管」，另一头是「几乎什么都不用你管」。一端你租的是裸机，其余的自己来；另一端你只是使用成品软件。最有名的记法是 **「pizza as a service」**——从头自己做、买回家自己烤、或者让人送上门。这三个有名字的层——**IaaS、PaaS、SaaS**——就是这条线上的几个点。 _Diagram: 从左到右，供应商承担的层越来越多。你自己的数据和设置，在哪里都还是你的。_ #### Cloud Service Models (pizza as a service) - **是什么:** 一条刻度：从硬件到应用，供应商运行多少层，你自己运行多少层。 - **例子:** 自己的机房 → IaaS → PaaS → SaaS：每走一步，你要负责的部分就少一些。 - **代价:** 他们替你做得越多，你的控制就越少——便利从来都不是免费的。 - **关联:** 刻度上的点：**IaaS**、**PaaS**、**SaaS**；最远的一端——**Serverless**。 ### IaaS 与 PaaS——裸机，还是现成的平台 > 租一间空车间，所有工具都得自己装（IaaS）；或者租一间设备齐全的车间，你只管带着项目进去开工（PaaS）。 **IaaS（Infrastructure as a Service）**租给你的是原始的积木——虚拟机、存储、网络——上面的一切都由你自己安装和管理：控制最大，活也最多。**PaaS（Platform as a Service）**则给你一个现成的环境，你只需部署代码，下面的服务器、扩缩容和打补丁都由供应商负责：控制少一些，活也少得多。你的选择，在于你想自己掌管多少「水管」。 _Diagram: IaaS：供应商只给你虚拟机。PaaS：除了你的代码，供应商全包。_ #### IaaS (Infrastructure as a Service) - **是什么:** 租用虚拟机、磁盘和网络；操作系统、运行时和应用都是你的。 - **例子:** AWS EC2 上的一台虚拟机：软件由你安装，系统由你配置，更新也由你自己负责。 - **代价:** 控制最大 = 活最多：打补丁和扩缩容都落在你身上。 - **何时使用:** 当你需要完全掌控一切的搭建方式时。 - **关联:** **Cloud Service Models** 的底部；它之上是 **PaaS**。 #### PaaS (Platform as a Service) - **是什么:** 一个现成的平台：你带来代码，供应商运行服务器、扩缩容和打补丁。 - **例子:** 推送到 Heroku 或类似平台——应用就跑起来了，不用配置任何服务器。 - **代价:** 控制更少：你得按平台的规则办事，并依赖它所支持的东西。 - **何时使用:** 当你只想部署代码、不想去想机器的时候。 - **关联:** 位于 **IaaS** 与 **SaaS** 之间；与 **Managed Service** 是近亲。 ### SaaS——开箱即用的成品软件 > 在咖啡馆吃一份三明治，你不用自己种小麦、烤面包——点单、吃就行。在它送到你面前之前，每一步都有别人做好了。 **SaaS（Software as a Service）**是最远的一端：你通过互联网直接使用的成品软件，供应商运行一切——Gmail、Slack、你的 CRM。除了你自己的数据和设置，你什么都不用管。你日常用的大多数软件都是 SaaS。作为开发者，那些你不想自己造的部分，你就*使用* SaaS；那些属于你自己产品的部分，你就在 IaaS 或 PaaS 上*构建*。知道自己处在哪一层，就知道谁负责什么。 _Diagram: 邮件、聊天和 CRM 直接拿现成的（SaaS）；你自己的产品则建在 IaaS 或 PaaS 上。_ #### SaaS (Software as a Service) - **是什么:** 通过互联网提供的成品应用；你只管自己的数据和设置。 - **例子:** Gmail、Slack、CRM——无需安装，也无需维护。 - **代价:** 几乎没有控制权：软件怎么运作，由供应商说了算。 - **何时使用:** 用于一切不属于你产品的部分。 - **关联:** **Cloud Service Models** 的顶部；与 **IaaS** 正相反。 > **那个模型问题:** 「对每一个部件，我想自己管多少——裸机（IaaS）、现成平台（PaaS），还是只管我的数据（SaaS）——相对于我真正需要多少控制？」 > cloud 的各层，区别在于供应商替你运行多少：IaaS 是你自己管理的裸机，PaaS 是为你的代码准备好的平台，SaaS 是直接使用的成品软件。 ## 3. elasticity 与 pay-as-you-go cloud 的超能力在于容量不是固定的。它随你的需要增长和收缩，你只为用到的部分付费——这是一份礼物，但如果粗心，也是一个陷阱。 ### Elasticity——高峰时往上，过后往下 > 一座音乐厅，能在重头戏那天晚上加一千个座位，第二天早上再撤掉——容量与人群相匹配，绝不浪费在空荡荡的大厅里。 **Elasticity**（弹性）是 cloud 在需求飙升时增加资源、需求回落时撤掉资源的能力。一场促销、一次爆红、一个繁忙的钟点——cloud 会拉起更多服务器来应付，之后再缩回去，这样你就不用为不需要的容量付钱。用自有硬件的话，你得按最忙的那一刻去买，其余时间让它闲着。Elasticity 让你运行的东西与你真正需要的东西一分钟一分钟地匹配起来。自动完成这件事的机制叫做 **autoscaling**（自动扩缩容）。 _Diagram: 容量随需求上下起伏。红线是自有硬件：按峰值购买，其余时间闲置。_ #### Elasticity (autoscaling) - **是什么:** 需求飙升时容量增长，需求过去后容量收缩。 - **例子:** 促销期间商店用十台服务器，夜里只用两台。 - **代价:** 没有上限的扩容，自己就可能把账单撑爆（**Bill shock**）。 - **关联:** 需要 **On-demand**；通过 **Pay-as-you-go** 付费；它的极端形态是 **Scale to Zero**。 ### Pay-as-you-go——是计量表，不是一次购买 > 一张水电账单：你付的是这个月实际用掉的电，而不是拥有电网的固定费用。用得多，付得多；不用，就不付。 cloud 像公用事业一样计费：**pay-as-you-go**，按你实际消耗的计算、存储和流量收费。没有前期采购，不为闲置的容量付钱——计量表只在你使用资源的时候才转。这正是 cloud 平易近人的原因：你可以从很小、很便宜的规模起步，成本随着用量一起增长，而不是在你还没有任何客户之前就押下的一笔巨额赌注。账单与现实同步。 _Diagram: 计算、存储和流量都要过一遍计量表；月底，账单就等于你的用量。_ #### Pay-as-you-go (按用量计费，usage-based billing) - **是什么:** 为你实际消耗的计算、存储和流量付费。 - **例子:** 一个小项目在用户少的时候只花几分钱；流量涨了，账单也涨。 - **代价:** 「只为用到的付费」＝「用到的每一样都要付费」。 - **关联:** **CapEx → OpEx** 和 **Elasticity** 在金钱上的那一面。 ### Bill Shock——计量表是双刃剑 > 出租车计价器在短途上很公平，但如果你忘了它已经跑了好几个小时，就很吓人——同样的按次计价，既能帮你省钱，也能悄悄积出一笔巨款。 Pay-as-you-go 是把双刃剑。同样的计量方式，在用量低时帮你省钱，但一旦有什么东西失控——一个一直开着的进程、一次失控的扩容、一个陷入循环的错误——就可能产生一张吓人的账单。这种意外就叫 **bill shock**（账单休克）。它之所以常见，正是因为拉起东西太容易，忘掉它们也太容易。于是有了这条规矩：你得盯着计量表——比如设置一个 **budget alert**（预算告警），在花费越过某个上限时触发。 _Diagram: 平常的日子，花费平稳。然后有东西失控，成本攀升；预算告警及早把它抓住。_ #### Bill Shock (意外账单，surprise bill) - **是什么:** 因为有东西失控，cloud 账单意外地高得离谱。 - **例子:** 一台测试服务器开了一个月忘了关；代码里的一个循环不停地调用某个收费服务。 - **如何避免:** 像监控性能一样监控花费；设置预算告警和扩容上限。 - **关联:** **Pay-as-you-go**、**On-demand** 和 **Elasticity** 的另一面。 > **那个成本问题:** 「我的容量是否随真实需求扩展、需求回落时又收缩——而且我是否在盯着计量表，让 pay-as-you-go 帮我省钱，而不是悄悄积出一张意外账单？」 > Elasticity 在高峰时扩容、过后缩容；pay-as-you-go 只对你用到的部分收费。同一块计量表，既能省钱，也能攒出一张吓人的账单——所以要盯着它。 ## 4. region 与 availability cloud 不是一个地方——它是分布在世界各地的数据中心。你的东西跑在哪里，既影响它用起来有多快，也影响它在故障面前能撑多好。 ### Region——让算力靠近用户 > 一家在每个大洲都有仓库的快递公司，从最近的仓库给每位客户发货——比从单一枢纽寄出所有包裹，对每个人都更快。 供应商在全球各地的 **region**（区域）里运营数据中心。应用跑在哪里由你来选，而把它放在离用户近的 region，就能降低 **latency**（延迟）——数据要走的路更短，应用就显得更快。一个欧洲的应用，从欧洲 region 提供服务，要比从大洋彼岸提供服务好得多。选择 region 就是地理这根杠杆：把你的算力和数据放在离使用者近的地方。 _Diagram: 欧洲的用户访问欧洲 region——路程很短。region 太远，就意味着要跨越大洋走很长的路。_ #### Region (延迟，latency) - **是什么:** 供应商位于世界某一区域的一组数据中心，由你为自己的代码挑选。 - **例子:** 面向欧洲人的应用，部署在欧洲的 region。 - **代价:** 一个 region 就是一个地方：地球另一端的用户会觉得更慢。 - **关联:** 一个 region 内含多个 **Availability Zone**；它们合起来提供 **High Availability**。 ### Availability Zone——扛得住一栋楼出故障 > 一家银行把记录的副本存放在几栋彼此分开的楼里——一栋被水淹了，其他的照常运转，什么也不会丢。 一个 region 内有多个 **availability zone**（可用区）——在物理上相互分离的数据中心。你同时在多个 zone 里运行系统的副本。如果某个 zone 断电或出故障，其他 zone 继续提供服务，你的应用仍然在线。 _Diagram: 三个 zone，三座独立的数据中心。zone B 断电了，但 A 和 C 里的副本仍在响应。_ #### Availability Zone (AZ) - **是什么:** 一个 region 内部、在物理上相互分离的数据中心。 - **例子:** 应用的副本放在三个 zone：一个断电了——另外两个继续工作。 - **代价:** 只有当你真的在多个 zone 里运行副本，它才能保护你免于一栋楼出故障。 - **关联:** **Region** 的一部分；**Redundancy / High Availability** 的构件。 ### Redundancy 与 High Availability——靠近用户，又扛得住故障 > 一家在每座城市都有分店的商店，而且每家分店都有附近的另一家做后备——既贴近顾客，又不怕任何一个地点熄火。 **Redundancy**（冗余）意味着没有哪一栋楼、哪一台机器、哪一个 zone 会成为致命的**单点故障**。由此换来的是 **high availability**（高可用）——在足以让单一地点瘫痪的故障面前依然在线。这两个想法合在一起，构成 cloud 架构的核心：为了速度，把算力放在靠近用户的 **region** 里；为了韧性，把它分散到多个 **zone** 里。一个全球服务在每个地方都像本地的一样快，又扛得住某处必然会发生的硬件故障。你不再把整个产品押在某栋楼里的某台机器上——你是按设计分散开的，而这就是「cloud 很可靠」绝大部分的真正含义。 _Diagram: 两个 region，分别靠近两群用户；每个 region 里，副本分布在两个 zone。没有单点故障。_ #### High Availability (冗余，redundancy) - **是什么:** 系统在故障面前依然在线，因为每个部分在别处都有一份副本。 - **例子:** 一个全球服务：欧洲一个 region、美国一个 region，每个 region 里的副本分布在两个 zone。 - **代价:** 副本要花钱，还会增加复杂度——每一份副本都记在账单上。 - **关联:** 由 **Region**（速度）和 **Availability Zone**（韧性）构成。 > **那个放置问题:** 「我的算力是否放在靠近用户的 region 里以获得低延迟，并分散在多个 availability zone 里，这样一座数据中心出故障时，不会把整个系统拖垮？」 > region 把你的算力放在靠近用户的地方以降低延迟；availability zone 把它分散到相互独立的数据中心以获得冗余——既贴近用户，又扛得住任何一处故障。 ## 5. managed service 除了租机器，cloud 还会替你运行整块整块的基础设施——数据库、队列、缓存——让你直接使用而不必运维。这份便利是一笔真实的取舍。 ### Managed Service——让供应商去做那些难的部分 > 一间配套服务的公寓，水管、供暖和维修都有别人负责——你只管住进去，而不用自己去当楼管。 **managed service**（托管服务）是 cloud 供应商替你运行的基础设施——托管数据库、消息队列或缓存——由他们负责搭建、扩缩容、备份、打补丁和 **failover**（故障切换）。你通过一个接口来使用它，永远不用碰下面的机器。你不必成为在大规模下可靠地运维数据库的专家，而是把这份专业能力租了过来。 _Diagram: 自己运维的数据库：一切都落在你身上。托管数据库：只有你的应用和查询是你的；其余都归供应商。_ #### Managed Service (托管数据库、队列、缓存) - **是什么:** 由供应商替你搭建、扩缩容、备份和打补丁的数据库、队列或缓存。 - **例子:** 使用托管的 Postgres（例如 AWS RDS），而不是在虚拟机上自己搭一个数据库。 - **代价:** 控制更少，并且被绑定在供应商上（**Vendor Lock-in**）。 - **关联:** 消除 **Undifferentiated Heavy Lifting**；再往下一步是 **Serverless**。 ### Undifferentiated Heavy Lifting——少一点运维，多一点产品 > 一位餐车老板向面包店买面包，而不是自己磨面粉——他专注于真正属于自己生意的餐食，而不是再去兼做面包师。 managed service 的要义是**专注**。可靠地运维基础设施——备份、扩缩容、安全补丁、凌晨三点的故障——是艰难而专门的工作，对大多数团队来说，那并不是他们的价值所在。这类工作被称为 **undifferentiated heavy lifting**（无差别的繁重工作）——那些繁重、却不能让你与竞争对手拉开差距的活儿。每一个不用来维持数据库存活的小时，都是花在真正属于你的产品上的一小时。把它卸出去，能让一个小团队发挥出远超自身规模的战斗力，去做功能，而不是去照看服务器。这正是现代产品能以小团队快速上线的一大原因。 #### Undifferentiated Heavy Lifting (无法让你与众不同的运维) - **是什么:** 人人都需要，但不会让你的产品变得特别的艰难运维工作。 - **例子:** 备份、安全补丁和凌晨三点的数据库故障——占去了本该做功能的时间。 - **代价:** 如果运维本身就是你的价值，把它交出去就是个错误。 - **关联:** 选择 **Managed Service** 和 **Serverless** 的理由。 ### Vendor Lock-in——便利与控制之间的取舍 > 一份配好的食材包方便得很——直到你想换掉其中一样食材，才发现食谱是由这个包说了算。便利，是用控制来买的。 这笔取舍是真实的：managed service 让出了一部分控制，并把你绑在那家供应商做事的方式上。你越深地采用他们特有的服务，离开就越难、越贵。这就是 **vendor lock-in**（供应商锁定）。你是在拿眼前的便利和速度，去换日后的灵活与独立。很多时候这是正确的选择——但要做得明明白白，把真正关键的部分保持可替换。这和在托管 API 与自己部署之间做选择，是同样的判断。 _Diagram: 应用依赖于某一家供应商的数据库、队列和独有的 API——想换到另一家就变得很贵。_ #### Vendor Lock-in (供应商锁定，provider lock-in) - **是什么:** 你陷进一家供应商的服务越深，离开就越贵。 - **例子:** 应用与供应商独有的 API 绑在一起——迁移就意味着重写。 - **如何与之共处:** 明明白白地接受锁定；让真正关键的部分保持可移植。 - **关联:** **Managed Service** 和 **Serverless** 所付的代价。 > **那个托管问题:** 「自己运维这个部件，是我价值的一部分吗——还是该交给 managed service，把这份精力花在我的产品上，为了专注而接受一些锁定？」 > managed service 让供应商去运行数据库、队列或缓存，这样你就能专注于产品而不是运维。代价是控制更少，并带有一定程度的 vendor lock-in。 ## 6. Serverless 「不用管机器」走到最远的一步就是 serverless：你只提供自己的代码，cloud 按需运行它，按请求扩缩容和计费。对于合适形态的工作，它很强大。 ### Serverless——只有你的代码，没有服务器要操心 > 一间按半小时预订的会议室：你不拥有它，不用给它供暖，也不用打扫——你只管来、用，离开的那一刻它就从你脑子里消失了。 **Serverless** 让你运行代码，而完全不用管理任何服务器。你把一个**函数**——一小段代码——交给供应商，每当有事件触发它时，它就运行这个函数：一个请求、一次文件上传、一个定时计划。所有的机器、扩缩容和容量，都在你看不见的地方处理好了。这种形态也叫做 **FaaS（Function as a Service）**。当然，服务器依然存在；只是你从不去想它们。这是 cloud 之旅在逻辑上的终点：从拥有机器，到租用机器，再到根本意识不到机器的存在。 _Diagram: 一个事件（请求、文件、定时计划）触发你的函数；服务器和扩缩容都藏在供应商那一侧。_ #### Serverless (FaaS，Function as a Service) - **是什么:** 你交出一个函数；供应商在每次事件发生时运行它，并管理所有机器。 - **例子:** 用户每上传一张图片，一个 AWS Lambda 函数就压缩一次。 - **代价:** **Cold Start**、不适合长时间的稳定工作，以及被绑定在供应商上。 - **何时使用:** 短小的事件驱动任务、突发性的负载。 - **关联:** **Cloud Service Models** 的最远一端；它会缩容到零（**Scale to Zero**）。 ### Scale to Zero——零请求，零成本 > 一盏人体感应灯：房间没人时熄着，不花一分钱；有人一进门就立刻亮起。你只在它真正亮着的时候才为这盏灯付钱。 Serverless 会**缩容到零**：没人用你的函数时，什么都不运行，你一分钱不付；请求涌进来时，它会自动拉起需要的任意多个副本。你是**按请求**、按计算的每一小段秒数计费，而不是为一台闲等着的服务器付钱。这对于忽高忽低、偶尔才用到或难以预测的工作来说是理想的——你轻松获得扩缩容，在清闲时一分钱不花，这是一台一直开着的服务器比不了的。 _Diagram: 上：请求；下：函数副本。没有请求——零个副本，账单上也是零；请求涌来——需要多少副本就有多少。_ #### Scale to Zero (按请求计费，per-request billing) - **是什么:** 没有请求时什么都不运行，账单为零；请求涌来时，副本自己启动。 - **例子:** 一份每天只被调用几次的内部报表，几乎不花钱。 - **代价:** 清闲一阵之后，第一个请求要等待启动（**Cold Start**）。 - **关联:** **Elasticity** 和 **Pay-as-you-go** 的极端形态。 ### Cold Start——什么都不运行所要付的代价 > 那盏人体感应灯在亮起时有一丝微小的延迟——走廊里无所谓，但如果你需要的是即时、恒定的亮度，就会很烦人。 Serverless 也并非没有取舍。一个闲置过的函数会有 **cold start**（冷启动）——供应商把它拉起来时的短暂延迟——这会伤害对延迟敏感的工作。它更适合短小的事件驱动任务，而不是长时间运行或流量大且稳定的任务，后者用一台一直开着的服务器可能更简单、更便宜。而且它依赖供应商特有的服务，所以锁定问题同样存在。Serverless 是针对合适工作的一把利器——突发性的、事件驱动的、缩容到零的工作——而不是一个万能的默认选项。 _Diagram: 冷的函数先要启动，之后才响应；热的函数立刻就响应。_ #### Cold Start (启动延迟，startup delay) - **是什么:** 供应商唤醒一个闲置函数时，第一个请求所遭遇的延迟。 - **例子:** 一个很少被用到的函数，响应第一个请求时，明显比响应后面的慢。 - **如何与之共处:** 对延迟敏感的工作或稳定的流量，使用一台一直开着的服务器。 - **关联:** **Serverless** 中 **Scale to Zero** 所付的代价。 > **那个 serverless 问题:** 「这项工作是突发性的、事件驱动的，缩容到零和按请求计费正好大显身手——还是稳定且对延迟敏感的，用一台一直运行的服务器才能避开冷启动？」 > serverless 只运行你的代码，缩容到零并按请求计费——非常适合突发性的、事件驱动的工作。留意冷启动和锁定；它是一把利器，而不是默认选项。 ## 7. 用好它 cloud 是一个装满取舍的工具箱，而不是唯一的正确答案。用好它，就是让每个部件匹配上适合它的模型，并留意两件会咬人的事：账单和锁定。 ### 让模型匹配需求 > 你不会用送货卡车去接送孩子上学，也不会用自行车去搬家——你挑的是适合这趟行程的车，而不是一个包打天下的默认选项。 不存在唯一正确的层。对不属于你产品的能力用 **SaaS**，用 **managed service** 卸掉 undifferentiated heavy lifting，对突发性的事件驱动工作用 **serverless**，需要完全控制时用**裸机（IaaS）**。真正的功夫，是让系统的每个部分匹配上适合其需要的模型——重要的地方要控制，不重要的地方要便利。一个好的 cloud 架构通常是有意为之的组合，而不是把同一个模型用在所有地方。 _Diagram: 每一种工作各有各的模型：SaaS、managed service、serverless，或裸机。_ ### 盯紧账单，提防锁定 > 租房很自在——直到你不再看账单；而最舒服的出租屋，往往是被设计成让你永远搬不出去的那一间。 有两件事总是在咬 cloud 的用户。第一是**账单**：按需就能拿到资源这么容易，意味着成本可能在不知不觉中悄悄爬升或骤然飙升（**bill shock**），所以你要像监控性能一样监控花费。第二是**锁定**：你与某一家供应商独有的服务绑得越深，离开就越难、越贵。这两件事都不是叫你避开 cloud——而是叫你睁大眼睛去用它：盯着计量表，别让你真正关键、本该可移植的部分，永久地焊死在某一家供应商身上。 ### 这一切是怎样连起来的 > 一幅拼图：每一块单独看意义不大；拼在一起，才成了一幅画。 这门课里的概念是一个整体。**cloud computing** 就是租，而不是拥有。从它长出三条分支。第一条是钱：**on-demand** 使 **elasticity** 成为可能，elasticity 通过 **pay-as-you-go** 来付费，而计量表有它黑暗的一面——**bill shock**。第二条是替你做了多少：**IaaS → PaaS → SaaS**、**managed service**，以及 **serverless**——它会**缩容到零**，代价是**冷启动**和 **vendor lock-in**。第三条是东西跑在哪里：**region**、**availability zone**，以及它们合起来的——**high availability**。 _Diagram: cloud 分成三条分支：钱、供应商做多少，以及部署位置。红色标出每条分支各自的陷阱。_ #### 在 cloud 上动手搭建之前 - **租还是买**——on-demand、pay-as-you-go 是否比买硬件更合适？ - **每个部件用哪种模型**——IaaS、PaaS、SaaS、serverless——取决于你需要的控制程度。 - **能否扩缩**——随需求弹性伸缩，高峰时向上、过后向下？ - **region 与 zone**——算力靠近用户，并分散部署以获得韧性？ - **托管还是自己运维**——运维这一部分真的是你的价值所在吗？ - **账单与锁定**——我是否在监控花费，并让关键部分保持可移植？ #### 你用好了 cloud 的迹象 - 你 **on-demand 地租用**，按用量付费，而不是按最忙的那一小时去买。 - 每个部件都用**合适的模型**——从裸机到 serverless。 - 你的系统**弹性伸缩**，跑在**靠近用户的 region** 里，并分散在多个 **zone** 上。 - 你把无差别的工作卸给 **managed service**，把精力集中在自己的产品上。 - 你**盯着账单**，并让关键部分保持可移植，以防**锁定**。 ## 速查表：全部 19 个概念 ### 租来的电脑 - **Cloud Computing** (云，the cloud): 通过互联网租用别人的电脑，而不是自己买。 - **CapEx → OpEx** (租而不买): 一大笔前期硬件采购，变成一份 pay-as-you-go 的账单。 - **On-demand** (自助，self-service): 自己在几秒钟内启动或停止一项资源。 ### 服务模型 - **Cloud Service Models** (pizza as a service): 一条刻度：供应商运行多少层，你自己运行多少层。 - **IaaS** (Infrastructure as a Service): 原始的虚拟机、磁盘和网络；上面的一切都是你的。 - **PaaS** (Platform as a Service): 一个现成的平台：你带来代码，供应商运行服务器。 - **SaaS** (Software as a Service): 成品软件；你只管自己的数据和设置。 ### Elasticity 与金钱 - **Elasticity** (autoscaling): 容量在高峰时增长，过后收缩。 - **Pay-as-you-go** (按用量计费，usage-based billing): 你为实际消耗的计算、存储和流量付费。 - **Bill Shock** (意外账单，surprise bill): 有东西失控时，账单意外地高得离谱。靠监控花费来化解。 ### 跑在哪里 - **Region** (延迟，latency): 位于世界某一区域的数据中心；离用户越近，延迟越低。 - **Availability Zone** (AZ): 一个 region 内独立的数据中心；跨 zone 的副本能扛住故障。 - **High Availability** (冗余，redundancy): 没有单点故障：系统在故障面前依然在线。 ### 托管服务 - **Managed Service** (托管数据库、队列、缓存): 由供应商替你运行的数据库、队列或缓存。 - **Undifferentiated Heavy Lifting** (无法让你与众不同的运维): 不会让你的产品变得特别的艰难运维——值得交出去。 - **Vendor Lock-in** (供应商锁定，provider lock-in): 你陷进一家供应商的服务越深，离开就越贵。 ### Serverless - **Serverless** (FaaS): 只有你的代码；供应商在每次事件发生时运行它。 - **Scale to Zero** (按请求计费，per-request billing): 没有请求——什么都不运行，也不计费。 - **Cold Start** (启动延迟，startup delay): 函数闲置后启动时，第一个请求所遭遇的延迟。 > cloud 就是 on-demand 地租用算力，分层从裸机一直到 serverless。用好它的办法，是让每个部件匹配上合适的模型——并盯紧账单和锁定。 速成课结束 · 7 章 · 19 个概念 接下来是实践：拿一个小应用，把它部署到一个 cloud 平台上——挑一个 PaaS 或 serverless 选项，这样你只管推代码，再看着它按用量扩缩容、按用量计费。然后加上一项 managed service，比如一个数据库，而不是自己运维一个。当你感受到自己几乎不必去运维多少、又注意到计量表在嘀嗒作响的那一刻，这些取舍就变得具体起来。但有一个想法要高高举在其余之上：cloud 不过是别人的电脑，on-demand 地租来。每一个时髦词，都是「别人替你运维多少」这条刻度上的一个落点——而用好它，就是一个部件一个部件地去选，拿多少便利去换多少控制。