1. Serverless架构核心概念与Google Cloud技术全景
Serverless（无服务器）并不是“没有服务器”，而是“开发者不再直接管理服务器”。计算资源依然运行在数据中心的物理机上，但容量规划、补丁升级、扩缩容、故障迁移这些工作被平台接管。开发者交付的单元从“一台虚拟机”变成“一段函数”“一个容器镜像”或“一份应用描述”，计费也从“按小时租机器”变成“按请求次数与执行时长付费”，空闲时通常为零成本。
理解 Serverless 的关键在于抓住三个特征：免运维（无需管理操作系统与运行时补丁）、自动弹性（从零扩展到高并发，再缩回零）、按用量计费（精确到请求与毫秒级执行时间）。这三者共同带来快速上线、低闲置成本的优势，也带来相应局限：冷启动会引入额外延迟；单次执行通常有超时上限；运行环境多为无状态，本地磁盘与内存不保证跨请求保留；长连接、后台常驻进程、需要固定公网 IP 或特殊内核参数的场景往往不适合。
从 IaaS 到 CaaS：责任边界如何移动
把 IaaS、PaaS、CaaS、FaaS 放在同一条“责任转移”轴上更容易看清差异。IaaS 中用户要管操作系统、运行时、中间件和应用；PaaS 中平台接管运行时与中间件，用户只交付代码和配置；CaaS（容器即服务）中用户交付容器镜像，平台负责编排与调度，但仍需自行定义副本数、扩缩容策略；FaaS 中连扩缩容和实例生命周期都由平台决定，用户只写函数。责任越往上转移，控制力越弱，但运维负担和闲置成本也越低。
| 模型 | 用户交付物 | 用户仍需负责 | 典型服务 |
|---|---|---|---|
| IaaS | 虚拟机镜像 | OS、运行时、扩缩容、补丁 | Compute Engine |
| CaaS | 容器镜像 | 副本数、扩缩容策略、镜像 | GKE、Cloud Run |
| PaaS | 源码 + 配置 | 应用逻辑、版本管理 | App Engine |
| FaaS | 函数代码 | 仅函数逻辑与依赖 | Cloud Functions |
Google Cloud 的 Serverless 服务全景
Google Cloud 的 Serverless 能力不是单一产品，而是一组按“计算形态 + 编排 + 事件”分工的服务组合。计算层有四个主力：Cloud Functions 适合单职责、事件驱动的小段逻辑，例如图片上传后生成缩略图、Pub/Sub 消息处理；Cloud Run 适合已经容器化的 HTTP 服务或任意容器任务，支持任意语言与依赖，可请求驱动自动扩缩到零，也支持 GPU 与并行实例；App Engine 适合传统 Web 应用，提供标准环境与灵活环境，标准环境缩容到零、按实例小时计费；Cloud Run functions 是 Cloud Functions 的新一代形态，构建在 Cloud Run 之上，统一了事件与 HTTP 触发模型。
编排层由 Workflows 承担，它用 YAML/JSON 定义一串步骤，按顺序或并行调用 Cloud Functions、Cloud Run、API 等，天然适合“下单 → 扣库存 → 发通知 → 失败补偿”这类有状态、多步骤、需要重试与错误分支的业务流程。事件层由 Eventarc 承担，它把来自 Cloud Storage、Pub/Sub、Firestore、Audit Logs 等 100 多个事件源的事件，以标准化格式路由到 Cloud Run、Cloud Functions、Workflows 等目标，让“事件产生”和“事件消费”解耦。
如何为具体场景选型
选型时先问三个问题：交付物是函数还是容器？是否需要长时间运行或常驻连接？是否需要多步骤编排？如果只是“某事件发生就执行一段逻辑”，优先 Cloud Functions；如果已有容器镜像或需要任意运行时、需要处理 HTTP 长请求，选 Cloud Run；如果是传统 Web 应用且希望平台托管路由与版本，选 App Engine；如果业务由多个服务按顺序组合、需要重试和失败补偿，用 Workflows 把它们串起来；如果事件源很多、需要统一过滤与路由，用 Eventarc 做事件总线。
局限与规避思路
Serverless 的局限需要在架构设计阶段就考虑。冷启动方面，可以为 Cloud Run 设置最小实例数（min-instances）保持热实例，或选择启动更快的运行时；超时方面，Cloud Run 请求最长可达 60 分钟，Cloud Functions 通常为 9 分钟以内，超长任务应改用 Cloud Run jobs 或 Batch；无状态方面，会话与临时文件应放入 Firestore、Cloud Storage 或 Memorystore，而不是本地磁盘；固定出口 IP 方面，可通过 Serverless VPC Access 加 Cloud NAT 获得稳定出口地址。把这些约束提前映射到服务能力上，才能既享受免运维红利，又不被运行时限制反噬。