部署平台
基于工作负载形状和团队能力选代码跑哪——VM、容器、函数或 PaaS。
为什么
部署平台定运维模型：VM（你补一切）、容器（你补镜像）、函数（你补无）、PaaS（你补无+厂商管伸缩）。正确选择取决于工作负载：长跑有状态服务要 VM/容器、突发事件驱动要函数、简单 web 要 PaaS。错选择意味要么太多运维（函数跑长跑 DB）要么太多抽象（VM 跑 50 行 webhook）。平台也定规模成本：函数低量便宜高量贵、VM 反之。把平台配工作负载而非反之。
何时使用
服务创建时。半天。运维负担或成本对工作负载错时重访。
如何做
1. 刻画工作负载： - 长跑+有状态 → VM 或容器 - 长跑+无状态 → 容器（Fargate/ECS/GKE） - 突发+事件驱动+<100ms 冷启可 → 函数（Lambda） - 简单 web、无特殊需 → PaaS（Render/Railway/App Runner） 2. 评估团队能力：能运维 VM 吗？容器？或需全托管？ 3. 估预期规模成本（函数低胜、容器高胜） 4. 考多语：不同服务可能适不同平台 5. 偏处理工作负载的最简平台——PaaS > 容器 > VM 6. 每服务记平台+理由（工作负载形状+团队能力）
示例
服务及平台： 1. Postgres DB（有状态、长跑）→ RDS（托管 VM）——无他选 2. API 服务器（无状态、长跑、24/7）→ Fargate（容器）——24/7 成本效 3. 图片缩放（突发、事件驱动、100ms 冷启可）→ Lambda——伸缩到零 4. 内部管理（简单 web、低流量）→ App Runner（PaaS）——零运维 5. ML 批处理（长跑、GPU）→ EC2 竞价（VM）——GPU+成本 混是对的：每工作负载在适配平台。 全塞 Lambda：#2 贵 5 倍、#1/#5 不可能。 全塞 VM：#3/#4 带空转成本+运维负担。
常见问题
- ⚠长跑服务用函数——Lambda 按每 100ms 计价且 24/7 服务在 Lambda 贵容器 5-10 倍；把平台配占空比。
最佳实践
- ✓服务默认容器、事件处理默认函数——此分覆盖 90% 工作负载的正确成本/运维权衡。
- ✓工作负载成熟时重评平台——100 请求/天有意义的 Lambda 在 10 万请求/天可能贵 5 倍；规划迁移。