云计算：你租的是故障边界

一个 region 是一个地理市场，里面有多个相互隔离的 availability zone。一个 zone 是一座或几座数据中心，电力、制冷和网络都各自独立。厂商用高速专线把 zone 连起来，但延迟和流量费依然存在。选 region 要看用户在哪、数据必须留在哪、服务有没有上线，以及恢复要求。选 zone 是为了扛住单个机房出事。

Region: eu-west
  Availability Zone A: web-1, database replica A
  Availability Zone B: web-2, database replica B
  Availability Zone C: spare capacity or third replica

Single-zone app  → zone outage can stop the service
Multi-zone app   → needs load balancing and replicated state
Multi-region app → needs explicit data and failover design

IaaS 给你 VM、磁盘和网络。平台服务替你管掉更多运行时、部署、伸缩或者数据库。SaaS 直接给你一个做好的应用。每往上一层，控制权和运维活是一起变少的。该问的不是“哪个更云原生”，而是“哪些没有差异化价值的活，我们可以安全地不再自己扛”。

On-premises: hardware + network + OS + runtime + app + data
IaaS:        network + OS + runtime + app + data
PaaS:                    app + data + configuration
SaaS:                            users + configuration

# Ownership never disappears completely
You still own: identity, data classification, access decisions,
configuration, monitoring, recovery tests, and your application code.

小团队的话，我的默认选择是托管数据库，加上能满足这个负载的最简单的托管计算。在一台手工搭的 VM 上跑数据库，不是什么工程严肃性的勋章。只有当某项需求确实值得你自己扛下打补丁、复制、备份、故障切换和恢复，才这么干。

一台 VM 用起来像一台电脑，有虚拟 CPU、内存、网卡和磁盘。它适合老系统、特殊操作系统要求、长期运行的进程，以及需要控制内核或宿主机的负载。它同时也让你的团队要负责镜像、补丁、进程守护、磁盘增长、证书和替换。

# VM bootstrap should be repeatable, not a shell history
1. Launch from a versioned image
2. Attach a machine role, never a copied user key
3. Fetch configuration and secrets at runtime
4. Start under a process supervisor
5. Emit logs and health signals centrally
6. Replace the VM to test reproducibility

# Useful Linux evidence
systemctl status my-app
journalctl -u my-app --since "15 minutes ago"
df -h
ss -lntp

容器镜像打包的是应用和它的用户态依赖。容器共享宿主机内核，启动快，还让部署产物保持一致。容器服务或者编排器负责调度、健康检查、替换失败实例，也能扩缩副本。它不会让状态、网络、安全和调试自动消失。

# Build once; identify the immutable artifact
docker build -t registry.example.com/orders:git-a1b2c3 .
docker push registry.example.com/orders:git-a1b2c3

# Runtime rules
listen on 0.0.0.0:$PORT
write logs to stdout/stderr
store durable data outside the writable container layer
handle SIGTERM and stop before the platform deadline
expose separate liveness and readiness signals

serverless 函数和托管运行时，会在请求或事件到达时把代码拉起来。机器分配由厂商负责，实例数在你配置的上限内自动伸缩。很多产品按请求数和执行时长计费。这套东西非常适合流量突发的 API、webhook、队列、定时任务和胶水代码。它不适合稳定负载、需要特殊宿主机、执行时间很长，或者任何时刻都要求低延迟的场景。

Design each invocation as disposable:
input event → validate → perform idempotent work → record result

Keep outside the instance:
- durable state
- job ownership
- secrets
- retry counters

Configure explicitly:
- timeout
- memory and CPU allocation
- maximum concurrency
- retry policy and dead-letter destination
- warm or provisioned capacity when latency demands it

冷启动只是问题之一。数据库连接风暴、重复投递、看不见的重试、失控的并发，制造的事故要疼得多。让处理函数幂等。在下游被压垮之前给并发设上限。每一次网络调用都要有超时。serverless 省掉的是宿主机维护，不是系统设计。

对象存储把带名字的数据块放在一个 API 后面。上传文件、备份、日志、静态资源和数据湖，默认用它。块存储给机器挂一块盘，适合操作系统和数据库。文件存储提供共享目录和你熟悉的那套文件操作。按访问模式、一致性、延迟、共享方式、持久性和恢复要求来选，别按你正好记得哪个产品名来选。

Object: bucket/key → GET, PUT, LIST
  use for: photos, archives, artifacts, backups

Block: volume → filesystem → one or limited hosts
  use for: VM boot disk, database data volume

File: share/path → concurrent filesystem clients
  use for: shared content, legacy file workflows

# A backup policy needs all four
frequency + retention + separate failure boundary + restore test

一个虚拟网络里有地址段和子网。路由表决定包往哪走。互联网网关或者公网负载均衡器接收公网流量。NAT 网关让私有负载能出网，同时不接受主动进来的连接。安全组和防火墙规则决定哪些流量被放行。DNS 给不断变化的地址提供稳定的名字。

internet
   ↓ HTTPS :443
public load balancer  [public subnets, zones A and B]
   ↓ app port
application replicas [private subnets, zones A and B]
   ↓ database port only
database              [private subnets, no public address]

Outbound from private subnet:
private route → NAT gateway → internet gateway → destination

身份与访问管理由主体、动作、资源和条件四样组合而成。人应该用联合身份加强认证。工作负载应该用平台挂上去的短期机器身份。策略只给最小的有用权限。把长期有效的访问密钥抄进源码文件或 VM 的环境变量文件，是完全可以避免的风险。

Decision = principal + action + resource + conditions

Example intent:
principal: orders-production workload
allow:     object:Get
resource:  receipts-production/*
condition: request comes through approved network endpoint

Do not grant:
principal: every workload
allow:     *
resource:  *

云账单由预留容量、执行时长、存储、操作次数、支持费、公网地址、托管控制面和数据传输拼起来。每小时那点小钱，会变成实打实的月度支出。数据在 zone 之间、region 之间，或者出到公网流动，可能主导一个在计算器上看着很便宜的设计。

Before launch, estimate:
compute hours or request volume
+ database instances, replicas, storage, and backups
+ object operations and retained versions
+ inter-zone, inter-region, and internet transfer
+ load balancers, NAT processing, logs, metrics, support

During operation:
owner tag + service tag + environment tag
budget alerts at useful thresholds
weekly anomaly review
actionable rightsizing, not automatic blind downsizing

高可用意味着服务能在预期内的故障中继续工作。灾难恢复意味着更大的损失之后你还能把它还原回来。先定恢复时间目标，也就是允许花多久才恢复；再定恢复点目标，也就是允许丢掉多少最近的数据。这两个数字应该驱动架构，也驱动演练。

Workload
[ ] Region chosen for users, law, latency, and service support
[ ] Capacity runs across zones; health checks test real readiness
[ ] Compute is replaceable from versioned artifacts
[ ] Timeouts, retries with jitter, and concurrency are bounded

Data
[ ] Replication matches the failure boundary
[ ] Backups are versioned or immutable where needed
[ ] Restore is tested; measured RTO and RPO meet the target

Access and network
[ ] Workloads use short-lived identities and least privilege
[ ] Databases have no unnecessary public path
[ ] Routes, firewall intent, DNS, and certificates are documented

Operations and cost
[ ] Logs, metrics, traces, alerts, owners, and runbooks exist
[ ] Budgets and anomaly alerts reach someone who will act
[ ] Zone loss, bad deploy, expired credential, and restore are drilled

不要因为一张架构图看着成熟，就一上来做多 region 双活。先做到计算能从版本化产物里重建、容量跨 zone、用托管数据服务、备份真的测过、身份收窄、故障可观测。等某个量过的恢复要求付得起一致性、路由、运维和成本上的复杂度，再加第二个 region。