📚 课程目录第4章 App Engine标准环境与柔性环境应用部署

4. App Engine标准环境与柔性环境应用部署

App Engine 是 Google Cloud 上最早出现的全托管应用平台，它把“部署一个可对外服务的应用”这件事压缩到一条命令：gcloud app deploy。但真正决定应用运行形态的，并不是这条命令，而是你选择的运行环境——标准环境（Standard）与柔性环境（Flexible）。两者共用同一套 App Engine 服务模型（应用、服务、版本、实例、流量分配），却在底层运行时、伸缩方式、网络能力和计费模型上差异明显。理解这些差异，才能写出正确的 app.yaml，并选对伸缩策略。

一、两种环境的本质差异

标准环境运行在 Google 高度沙箱化的运行时中，实例启动通常在秒级，甚至可缩容到 0 个实例，按实例小时计费，适合无状态、突发流量、对冷启动不敏感的 Web 应用与 API。柔性环境则把应用打包进 Docker 容器，运行在 Compute Engine 虚拟机之上，实例启动通常需要数十秒到数分钟，最少保留 1 个实例，按 vCPU、内存和磁盘资源计费，适合需要自定义运行时、本地磁盘、WebSocket、长连接或第三方系统库的场景。

关键差异可以归纳为：标准环境“快、省、受限”，柔性环境“慢、贵、自由”。标准环境支持的语言运行时是固定的（如 Python、Java、Node.js、Go、PHP、Ruby），柔性环境则通过 runtime: custom 加 Dockerfile 支持任意语言。标准环境默认无法直接访问外部非 HTTP 端口，柔性环境可以自由发起 TCP 连接。标准环境支持自动伸缩到 0，柔性环境最小实例数为 1。

二、app.yaml 的核心配置

app.yaml 是 App Engine 的部署描述文件，它决定了运行时、伸缩策略、环境变量、路由和资源规格。标准环境与柔性环境的 app.yaml 结构相似，但字段含义不同。下面是一个标准环境的示例：

runtime: python312
instance_class: F2
automatic_scaling:
  min_instances: 0
  max_instances: 10
  target_cpu_utilization: 0.65
  min_pending_latency: 30ms
  max_pending_latency: automatic
env_variables:
  APP_ENV: "production"
handlers:
- url: /static
  static_dir: static
- url: /.*
  script: auto

柔性环境的 app.yaml 则需要指定 env: flex，并通常配合 runtime_config 与 resources：

runtime: custom
env: flex
resources:
  cpu: 2
  memory_gb: 4
  disk_size_gb: 20
automatic_scaling:
  min_num_instances: 1
  max_num_instances: 8
  cpu_utilization:
    target_utilization: 0.6
network:
  forwarded_ports:
  - 8080

注意标准环境用 min_instances/max_instances，柔性环境用 min_num_instances/max_num_instances，这是最容易写错的地方。柔性环境还支持 network.forwarded_ports 暴露额外端口，标准环境则不支持。

三、版本管理与流量分配

每次 gcloud app deploy 都会创建一个新版本，版本号默认是时间戳，也可以用 --version=v2 指定。版本是 App Engine 流量治理的基本单位：你可以把 100% 流量指向稳定版本，把 10% 流量切到新版本做金丝雀发布，验证无误后再全量切换。

流量分配通过 gcloud app services set-traffic 完成。例如把 default 服务的 90% 流量给 v1、10% 给 v2：

gcloud app services set-traffic default \
  --splits=v1=0.9,v2=0.1 \
  --split-by=random

--split-by 支持 random（按请求随机）、cookie（同一用户固定版本）和 ip（按来源 IP）。做 A/B 测试时用 cookie 能保证用户体验一致；做灰度验证时用 random 更简单。流量切换是秒级生效的，不需要重新部署。

四、实例伸缩策略

标准环境提供三种伸缩类型：自动伸缩（automatic_scaling）、基本伸缩（basic_scaling）和手动伸缩（manual_scaling）。自动伸缩根据 CPU 利用率、请求延迟和并发请求数动态调整实例数，是最常用的方式。基本伸缩适合长时任务，实例不会自动缩容到 0，但可以设置 max_instances 和 idle_timeout。手动伸缩则固定实例数量，适合可预测的稳定负载。

柔性环境只支持自动伸缩和手动伸缩，且最小实例数必须 ≥ 1。自动伸缩的核心参数是 target_cpu_utilization（标准）或 cpu_utilization.target_utilization（柔性），默认 0.6～0.65。设置过低会导致实例频繁扩缩，设置过高则可能响应变慢。建议先用默认值观察一周，再根据实际 CPU 曲线微调。

标准环境冷启动优化技巧：设置 min_instances: 1 可以消除冷启动，但会增加成本；使用 min_idle_instances 保留空闲实例，比 min_instances 更灵活。柔性环境由于最少 1 实例，天然没有冷启动问题，但常驻成本更高。

五、部署流程与验证

一次完整的部署流程包括：本地编写 app.yaml 与代码 → 执行 gcloud app deploy → 等待构建与版本创建 → 用 gcloud app versions list 查看版本状态 → 用 gcloud app browse 打开默认版本 → 通过流量分配逐步切换。部署后应重点验证：新版本是否正常响应、日志中是否有错误、实例数是否符合预期、CPU 利用率是否在目标区间。

如果部署失败，常见原因包括：app.yaml 字段拼写错误、运行时版本不支持、柔性环境 Dockerfile 构建失败、配额不足。此时应先用 gcloud app describe 确认应用状态，再查看 Cloud Build 日志定位构建问题。

柔性环境部署时，如果 Dockerfile 中暴露的端口与 app.yaml 中 forwarded_ports 不一致，会导致健康检查失败、实例反复重启。务必保证容器监听端口与配置一致，通常使用 8080。

总结来说，标准环境适合“快、省、无状态”的场景，柔性环境适合“自由、长连接、自定义运行时”的场景。掌握 app.yaml 的字段差异、版本流量分配和伸缩参数，就能在两种环境之间做出合理选择，并让应用在生产环境中稳定运行。